D6, On 2.5 and 2.6 i have the following settings:
- max backup rotation 15
- daily backup

When i 15 backups have been created and the "newest" file is called file_15, the rotation seems to delete the wrong file on the next backup. When a new backup is be created, bam deletes file_15 instead of file_1 and creates a new file_15. My file names are the one used by default, basically i did not change anything beside the schedule, so date_suffixed. This, oddly, happens from time to time, lets say arround every 5 days for 3-4 f days, then some random file gets deleted, lets say file_3 and so forth. E.g. currently i have backups for 1-3 march, 7 april an, 20-27 apris, some in mai and 10th mai.

AFAIK there are people on D7 having the same issue.

Marking as critical, as this potentially leaves you with ages-old backups, only having the last avail.

CommentFileSizeAuthor
#1 bam_filetime_patch.patch1.03 KBeugenmayer

Comments

eugenmayer’s picture

eugenmayer commented
StatusFileSize
new bam_filetime_patch.patch1.03 KB

As files are sorted by their filetime when searching for expired, that information is very sensible.

Currently http://php.net/manual/de/function.filectime.php is used to determine the backup age, which is doomed to fail anyway, as even a group/owner/fileperm change does change the age to "the time changed". Every copy/move and so forth.

Beside the backup-time should be saved in the filename or AFAICS in a meta-file in the backup ( 3.x branch ) we should use http://www.php.net/manual/de/function.filemtime.php which is at least more robust and only reacts on changes of the archive, which most probably should be what we need.

We could determine the age from the filename, but that is not bullet proof, as i guess people can set their filename manually. Therefore filemtime is our best bet until 3.x

eugenmayer’s picture

eugenmayer commented
Status: Active » Needs review

Well, somebody able to confirm / test?

for easier testing: https://github.com/EugenMayer/backup_migrate

eugenmayer’s picture

eugenmayer commented
Status: Needs review » Reviewed & tested by the community

Well, running this patch for more then one week, every single backup succeded, no backups missing on all installations

izmeez’s picture

izmeez commented

Accidentally stumbled on this issue. We are using 6.x-2.7 and have no problems, also don't recall problems in earlier version. Also the scheduled backup configuration includes field "Number of backup files to keep" which seems to work fine.

Is this really an issue or should it be closed?

eugenmayer’s picture

eugenmayer commented

if that is no issue, you rather could delete this module completly. You are not creating any backups.

ronan’s picture

ronan commented
Status: Reviewed & tested by the community » Postponed

This is a simple enough change, but I'm a little wary of what he side effects could be. None of the unix timestamps is particularly stable which is why I've moved to storing metadata separately in v3. I totally get that this is a huge problem for some people but given the lack of action on this ticket, it seems like you may be in the minority.

This version is nearing the end of it's life-cycle and the problem is moot in v3, so I think I'm going to shelve this issue. Anybody who experiences this issue should probably run a patched version of the 2.x branch until the 3.x branch is ready, or better yet, help get the 3.x branch stable by testing it.

Thanks
R

ronan’s picture

ronan commented
Issue summary: View changes

typos

ronan’s picture

ronan commented
Issue summary: View changes
Status: Postponed » Fixed

Hmm. weird. I didn't fix any typos. Must be some weirdness in the d7 upgrade.

Anyway, I changed my mind and applied #1357402: File dates displayed in destinations so this should be fixed now.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.