Support

Akeeba Backup for Joomla!

#39688 CLI Cron Job Backup deleted Backend backups?

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
4.3.4
PHP version
8.1
Akeeba Backup version
9.8.1

Latest post by nicholas on Tuesday, 24 October 2023 06:14 CDT

Malalana

I'm setting up automatic CLI Cron Jobs for Akeeba Backup. I've just ran my first CLI Cron Job with a command line like this:

/usr/local/bin/php /[my-site-path]/cli/joomla.php akeeba:backup:take --profile=2 --description="Automated Backup on [YEAR]-[MONTH]-[DAY] - [TIME]"

The CLI Backup run correctly, but after running this, all my previous Backend backups in "Manage Backups" were marked as "Obsolete" and deleted from the server.

All my "Quota Management" settings are disabled. No backups were ever automatically deleted when I simply ran a manual backup from the Backend.

How is it possible that this happened?

System Task
system
The ticket information has been edited by Andrea (Malalana).

nicholas
Akeeba Staff
Manager

I am not clear on what you mean with "deleted". Are we talking about the archive files stored on disk, or the backup records stored in the database?

Akeeba Backup will remove backup archive files (but not backup archive records) when the quota settings kick in.

Akeeba Backup will remove backup records which do not have valid archive record (obsolete records) based on the Obsolete Records Quotas setting.

In no other case will Akeeba Backup remove backup archive files or records.

If you have set up your backup profile to use the same name for every backup (there are no per-backup naming components, such as [DATE]) then Akeeba Backup will of course overwrite your previous backup with the new backup archive file. This, however, is a problem if used together with quota settings as it may end up deleting the (only) backup archive set on your site. Together with obsolete record quotas it will also end up deleting backup records which previously appeared as OK (since all of them were pointing to the one and only backup archive which was present on your disk, but now got deleted by the quota settings, therefore they immediately became obsolete).

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Malalana

Are we talking about the archive files stored on disk, or the backup records stored in the database?

The archive files stored on disk. The entries are still there in the "Manage Backups" section, but all became with a trashcan icon and marked as "Obsolete", and the archive files on disk are no longer there :/

Akeeba Backup will remove backup archive files (but not backup archive records) when the quota settings kick in.

All my quota settings are disabled. See: https://i.imgur.com/QAVxUUX.png

And no backups archive was ever deleted when simply manually doing backups from the backend. But after I triggered the first cron job with the command above, they all got deleted and marked as obsolete. No idea why that would happen. Maybe a bug in the cron job code checking for quota settings?

In no other case will Akeeba Backup remove backup archive files or records.

Well. It happened. Here's a screenshot of my situation currently: https://i.imgur.com/gX2VRvN.png

When backup 42 was taken (the first via Cron Job) all backups from 40 and oldest were deleted from the disk and marked as Obsolete (but 41 was kept).

 

nicholas
Akeeba Staff
Manager

All right. Let's forget the fact that it's always the same code running regardless of how you take a backup. Let's forget the fact that quota settings only run at the end of the backup based on the records kept in the database, the configuration of the backup profile you are backing up with, and only operate on backup archives created by the same backup profile. Let's also forget the fact that the quota code has not changed at all since August 30th, 2022 — over a year ago — and nobody has reported anything similar, which would be unheard of if there's a bug of the magnitude you allege given the fact that we have thousands of clients using the software on hundreds of thousands of servers and we never had a major issue which went unreported by anyone for longer than 3 hours after making a release that included said bug (this is a fact, unfortunately, and it definitely keeps us on our toes, but that's another story for another time).

Let's follow the scientific method. We will make a hypothesis and test it.

We shall hypothesize there is an as yet unidentified bug. For this assumption to hold, the bug will be reproducible following your instructions.

So, I start by creating a brand new Joomla! 4.3.4 site on PHP 8.1.24 and install Akeeba Backup Professional 9.8.1 on it. To keep it fair, I downloaded both Joomla! and Akeeba Backup Professional from their respective official download sites instead of using my local copies.

I am going through Akeeba Backup's Configuration Wizard.

At this point, there are quotas set up: count quotas, set to 3. I am taking 7 backups from the backend of the site.

As expected, the latest 3 backups (IDs 7, 6, and 5) are OK and the other 4 (IDs 4, 3, 2, and 1) show as Obsolete. This proves that the quota settings were respected. But that is not what you want me to test.

So, as per your reproduction instructions, I am completely turning off all quota settings.I do keep the "Obsolete records to keep" to its default value, 50. I am not making any other changes to the configuration.

I am taking another 6 backups.

As expected, I see that records from 13 down to 5 are shown as OK and the original four (1, 2, 3, and 4) are still shown as Obsolete. This proves that disabling quotas had the intended effect in the backend.

Now, let's take the CLI backup.

php /var/www/client/cli/joomla.php akeeba:backup:take --description="Automated Backup on [YEAR]-[MONTH]-[DAY] - [TIME]"

And yes, before you ask, I did run it with a CRON job set to run a minute after I edited my crontab with crontab -e:

29 22 * * * php /var/www/client/cli/joomla.php akeeba:backup:take --description="Automated Backup on [YEAR]-[MONTH]-[DAY] - [TIME]"

As expected, I see that records from 14 down to 4 are shown OK and the original four are obsolete:

$ php /var/www/client/cli/joomla.php akeeba:backup:list

List of Akeeba Backup records matching your criteria
====================================================

---- --------------------------------------------------- --------- --------------------- --------------------- ---------- --------- ------ ------------ --------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- ----------- --------- --------------------------- ------------ ----------------- ------------ -------- -------- ---------- ---------------- ----------
id description comment backupstart backupend status origin type profile_id archivename absolute_path multipart tag backupid filesexist remote_filename total_size frozen instep meta hasRemoteFiles size
---- --------------------------------------------------- --------- --------------------- --------------------- ---------- --------- ------ ------------ --------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- ----------- --------- --------------------------- ------------ ----------------- ------------ -------- -------- ---------- ---------------- ----------
14 Automated Backup on 2023-10-23 - 192920 2023-10-23 19:29:00 2023-10-23 19:29:04 complete cli full 1 site-client.local.web-20231023-192900utc-TK69tt1_wWB6hcET.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192900utc-TK69tt1_wWB6hcET.jpa 1 cli id-20231023-192920-810041 1 34114864 0 1 ok 34114864
13 Backup taken on Monday, 23 October 2023 19:26 UTC 2023-10-23 19:26:15 2023-10-23 19:26:19 complete backend full 1 site-client.local.web-20231023-192615utc-Jov6sIYiJ3dtDoBP.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192615utc-Jov6sIYiJ3dtDoBP.jpa 1 backend id-20231023-192615-629368 1 34114779 0 1 ok 34114779
12 Backup taken on Monday, 23 October 2023 19:26 UTC 2023-10-23 19:26:10 2023-10-23 19:26:14 complete backend full 1 site-client.local.web-20231023-192610utc-EzrYsRa2vaRwXpmS.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192610utc-EzrYsRa2vaRwXpmS.jpa 1 backend id-20231023-192610-642392 1 34114727 0 1 ok 34114727
11 Backup taken on Monday, 23 October 2023 19:26 UTC 2023-10-23 19:26:05 2023-10-23 19:26:09 complete backend full 1 site-client.local.web-20231023-192605utc-BpaMmPIy8PGCZDas.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192605utc-BpaMmPIy8PGCZDas.jpa 1 backend id-20231023-192605-708449 1 34114667 0 1 ok 34114667
10 Backup taken on Monday, 23 October 2023 19:25 UTC 2023-10-23 19:25:58 2023-10-23 19:26:04 complete backend full 1 site-client.local.web-20231023-192558utc-CnYIwJgUc0udxnDM.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192558utc-CnYIwJgUc0udxnDM.jpa 1 backend id-20231023-192558-321869 1 34114607 0 1 ok 34114607
9 Backup taken on Monday, 23 October 2023 19:25 UTC 2023-10-23 19:25:53 2023-10-23 19:25:57 complete backend full 1 site-client.local.web-20231023-192553utc-WGTLcdR2ki0CBWWJ.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192553utc-WGTLcdR2ki0CBWWJ.jpa 1 backend id-20231023-192553-75651 1 34114556 0 1 ok 34114556
8 Backup taken on Monday, 23 October 2023 19:25 UTC 2023-10-23 19:25:42 2023-10-23 19:25:46 complete backend full 1 site-client.local.web-20231023-192542utc-un_gwSXR2HZKzmdq.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192542utc-un_gwSXR2HZKzmdq.jpa 1 backend id-20231023-192542-107403 1 34114501 0 1 ok 34114501
7 Backup taken on Monday, 23 October 2023 19:23 UTC 2023-10-23 19:23:11 2023-10-23 19:23:15 complete backend full 1 site-client.local.web-20231023-192311utc-ZeG4TixHxYga55w_.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192311utc-ZeG4TixHxYga55w_.jpa 1 backend id-20231023-192311-391422 1 34114425 0 1 ok 34114425
6 Backup taken on Monday, 23 October 2023 19:23 UTC 2023-10-23 19:23:06 2023-10-23 19:23:10 complete backend full 1 site-client.local.web-20231023-192306utc-YJZ0BOQI1S8Qklwc.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192306utc-YJZ0BOQI1S8Qklwc.jpa 1 backend id-20231023-192306-235857 1 34114372 0 1 ok 34114372
5 Backup taken on Monday, 23 October 2023 19:23 UTC 2023-10-23 19:23:00 2023-10-23 19:23:05 complete backend full 1 site-client.local.web-20231023-192300utc-L7hAqrplLxcqstzY.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192300utc-L7hAqrplLxcqstzY.jpa 1 backend id-20231023-192300-806141 1 34114322 0 1 ok 34114322
4 Backup taken on Monday, 23 October 2023 19:22 UTC 2023-10-23 19:22:55 2023-10-23 19:22:59 complete backend full 1 site-client.local.web-20231023-192255utc-9oKWreecA0Etlh2_.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192255utc-9oKWreecA0Etlh2_.jpa 1 backend id-20231023-192255-674521 0 34114257 0 1 obsolete
3 Backup taken on Monday, 23 October 2023 19:22 UTC 2023-10-23 19:22:50 2023-10-23 19:22:54 complete backend full 1 site-client.local.web-20231023-192250utc-fiqTLHbG-G-zyZMN.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192250utc-fiqTLHbG-G-zyZMN.jpa 1 backend id-20231023-192250-475081 0 34114209 0 1 obsolete
2 Backup taken on Monday, 23 October 2023 19:22 UTC 2023-10-23 19:22:45 2023-10-23 19:22:49 complete backend full 1 site-client.local.web-20231023-192245utc-Y7nP5z6KNvGrdaHA.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192245utc-Y7nP5z6KNvGrdaHA.jpa 1 backend id-20231023-192245-139249 0 34114155 0 1 obsolete
1 Backup taken on Monday, 23 October 2023 19:22 UTC 2023-10-23 19:22:22 2023-10-23 19:22:30 complete backend full 1 site-client.local.web-20231023-192222utc-ZXZTIi26vJbbOlBA.jpa /var/www/client/administrator/components/com_akeebabackup/backup/site-client.local.web-20231023-192222utc-ZXZTIi26vJbbOlBA.jpa 1 backend id-20231023-192222-377503 0 34114069 0 1 obsolete
---- --------------------------------------------------- --------- --------------------- --------------------- ---------- --------- ------ ------------ --------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- ----------- --------- --------------------------- ------------ ----------------- ------------ -------- -------- ---------- ---------------- ----------

$ls /var/www/client/administrator/components/com_akeebabackup/backup
akeeba.backend.id-20231023-192300-806141.log.php akeeba.backend.id-20231023-192306-235857.log.php akeeba.backend.id-20231023-192311-391422.log.php akeeba.backend.id-20231023-192542-107403.log.php akeeba.backend.id-20231023-192553-75651.log.php akeeba.backend.id-20231023-192558-321869.log.php akeeba.backend.id-20231023-192605-708449.log.php akeeba.backend.id-20231023-192610-642392.log.php akeeba.backend.id-20231023-192615-629368.log.php akeeba.cli.id-20231023-192900-810041.log.php akeeba.log.php index.htm index.html index.php site-client.local.web-20231023-192300utc-L7hAqrplLxcqstzY.jpa site-client.local.web-20231023-192306utc-YJZ0BOQI1S8Qklwc.jpa site-client.local.web-20231023-192311utc-ZeG4TixHxYga55w_.jpa site-client.local.web-20231023-192542utc-un_gwSXR2HZKzmdq.jpa site-client.local.web-20231023-192553utc-WGTLcdR2ki0CBWWJ.jpa site-client.local.web-20231023-192558utc-CnYIwJgUc0udxnDM.jpa site-client.local.web-20231023-192605utc-BpaMmPIy8PGCZDas.jpa site-client.local.web-20231023-192610utc-EzrYsRa2vaRwXpmS.jpa site-client.local.web-20231023-192615utc-Jov6sIYiJ3dtDoBP.jpa site-client.local.web-20231023-192900utc-TK69tt1_wWB6hcET.jpa web.config

Since taking a backup from the CLI with all quota settings disabled did not result in any backup archives being deleted we conclude, as the result of using the scientific method, that the hypothesised bug does not exist.

I consider it far more likely that the host deleted the backup archives. They are big files and they look “suspicious” because they have a non-standard extension, they are big, they have compressed data, and it would not be the first time we see a host deleting files without asking because they mistook them for something sinister. I strongly recommend that you store your backup archives off-site to avoid issues like that in the future.

Also note that I am replying to this ticket assuming that you know what you are talking about. I am not making this statement to insult you. I just know that most of the times someone comes here to ask help for a “bug” in quota management we invariably see that they misunderstood how quotas work. It's very important to understand that the quota settings are per profile, apply only to the backups taken with that profile, and that they are calculated based on the information in the database (the database records you see in the Manage Backups page). If you only edited the quota settings in profile #1, these changes will not apply to profile #2 (the one you are using).

Moreover, I am not even considering far more mundane issues all of us have inflicted upon ourselves at one time or another, such as using the same folder as the backup output and Joomla! temporary directory, accidentally deleting all files in the wrong folder, or creating an automation which does what we told it to do and not what we intended it to do.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Malalana

Hey there,

Yes - I'm aware that Quota settings operate per backup profile. And if you say that it's the same code that runs regardless of how you take a backup, then I'm really not sure how this could have possibly happened. Like you said, it would be a huge bug that would have surely been reported by dozens of users.

Thanks for testing - I've just tried to replicate it on another website following your exact instructions as well, and I couldn't replicate it.

So I'm really as confused as you on how it could have possibly happened.

With that being said, I guess we can conclude this as a freak accident, a weird glitch, or no idea what else - but I guess not a bug in your software. So we can close this ticket.

nicholas
Akeeba Staff
Manager

Yeah, it really is weird. I was thinking about this this morning.

Are you sure nobody else has access to your site over FTP / SFTP? I would definitely prefer going the paranoid route and change all passwords. I recommend using a password manager to generate 64 character passwords consisting of lowercase and uppercase letters, numbers, and punctuation (basically, everything you can type on your keyboard).

I would also start dumping the list of files of the backup folder to a file at the end of the backup, e.g. changing the CRON command line to

/usr/local/bin/php /[my-site-path]/cli/joomla.php akeeba:backup:take --profile=2 --description="Automated Backup on [YEAR]-[MONTH]-[DAY] - [TIME]"; ls /wherever/your/backup/folder/is > /[my-site-path]/../list-of-backups.txt

You get the idea. If you see backups disappearing again you can look at the list of files. If the files were not missing from the list, they were not removed by Akeeba Backup. So, that gives you some ammo to go to your host and say hey, why are you guys removing my backups.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Malalana

Thanks again for all your insight.

Are you sure nobody else has access to your site over FTP / SFTP?

Yes, plus the way the folder is set up (I have backups of all my 3 sites in one folder, I should probably change that for tidiness), I know for sure it's not someone else manually deleting the archives via FTP, because only the ones from that one site were deleted, and not the others, and it would have been impossible to only pick and choose and delete the ones from that site but not the others.

I would also start dumping the list of files of the backup folder to a file at the end of the backup

But I will do something like that just in case. Thanks :)

Unrelated question before we close the ticket: 

Your documentation about CLI Cron Job says:

The command will return a different exit code, depending on the backup status. When the backup is successful and without warnings, the exit code will be 0. When the backup completed but with warnings, the exit code will be 1. Finally, if the backup fails, the exit code will be 2.

I'm wondering, where can this be seen? In The Cron Email that I receive, I see no exit code at the end of it. Although it does says "[OK] The backup process is now complete"

Thanks :)

System Task
system
The ticket information has been edited by Andrea (Malalana).

nicholas
Akeeba Staff
Manager

The exit code is really a standard thing. Please read an introduction for their use in Linux and the Bash shell at https://www.baeldung.com/linux/status-codes

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!