Support

Akeeba Backup for Joomla!

#8576 wrong delete of backups in "administer backup files"

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
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Friday, 24 September 2010 06:38 CDT

user191
Hi, when I select some backups to be deleted in the "Administer backup files", Akeeba deletes other ones!
I have not understood a pattern for that (since I should have a lot of backups) but it is happening every time so I don't think it's some user error.
Can I supply more info?
thanks

Giuse

nicholas
Akeeba Staff
Manager
Which version of Akeeba Backup and which version of Joomla! are you using? Have you tried upgrading both to their latest releases?

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!

user191
Unfortunately I am using latest versions of everything: Joomla 1.5.20 and Akeeba 3.1b1 (and the same with beta1).
The typical behavior: I have 10 backups, the first is the latest one and is good, the other are obsolete. I select from the second to the nine (to keep the oldest one) and... I get deleted also the first one (the only good...).
very strange, also happening with 3.0.1, probably not before.
what else to look at?
cheers

Giuse

nicholas
Akeeba Staff
Manager
3.0.1 and 3.0 are identical except for one file, restore.php, used in restoration. You were either having this problem all along or not at all :) The only reason that this would happen is if all backups (or at least the "OK" and one of the "Obsolete" backup records) have the same file name. For instance, if two records internally point to a file called site-example.com-20100822 then both records will be automatically deleted. The best approach to avoid it is to use the default naming scheme which includes the hostname, date and time in the backup file name.

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!

user191
You got it! :D
It was a problem of file naming (I changed the profiles with 3.0.1).
The point was that I'd like to create a daily backup where only the last one is kept. Now, I can do locally setting the limit in Akeeba but the copy moved with ftp or DropBox not. The only way was to have the same name so that it is overwritten on the remote location.
Could a new feature like "apply retention policy also to remote location" be implemented? So that old backups are deleted from remote location, mirroring the local set.
Cheers and thanks!

Giuse

nicholas
Akeeba Staff
Manager
The solution is much easier: do not delete the backup entries from the Administer Backup Files page. If there are 10 backup records all pointing to the same archive file (due to its name) they will all display as "OK", but - in fact - there is only ONE backup archive on your server (the last one, of course!), so you they do not take up extra space. Just ignore the extraneous "OK" records and do not delete them.

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!

user191
Well, yes, but I should not delete the entries indefinitely... (ending up in hundreds of entries in the Admin backups).
Probably a "Delete entries (only)" (in addition to "Delete" and "Delete files") would do?
Cheers and thanks for your support

Giuse

nicholas
Akeeba Staff
Manager
I will look into that. I hadn't implemented this feature because some people might end up deleting the records without deleting the files, causing problems. I think I should better make Akeeba Backup check if multiple records reference the same backup when trying to delete the record.

BTW, the new version (3.1.b1 and later) does not "clog" when you have hundreds of backup records, unlike its predecessor.

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!

user191
I think I should better make Akeeba Backup check if multiple records reference the same backup when trying to delete the record.

Even better! That is the cleanest one, I think.
cheers

Giuse

user191
Hi Nicholas, do you have any plan to implement this feature (check when multiple backups share the same file) in one of the next updates?
Another question: why when I make two backups, the first one is automatically marked as obsolete and the file deleted? If I want to restore not the last but a previous version?
thanks a lot

Giuse

nicholas
Akeeba Staff
Manager
This feature is scheduled for 3.2.

If all your files have the same name, the only present on the server is the last backup, despite what the UI shows. It can not be otherwise, as you can not have two different files with the same file name - of course! If you want to have access to your older backups you have no other option than to use the date/time variables in your archive's name template.

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!