In backup and migrate module, schedule tab is there in which we can schedule a backup with the number to keep which is use to store latest backups with entered numbers and delete oldest backups, which is used to save system memory
at number to keep field I added the value 5 which means once the 5 backups are reached then it should delete oldest backup on 6th backup. But it doesn't work after completing 5 backups process being stop and not adding 6th backup and not deleting oldest backup.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 3221856-3.patch | 447 bytes | larisse |
Comments
Comment #2
damienmckennaComment #3
larisse commentedHi!
The problem was because the files have been delete in descending order, so the last backup created has been deleted.
I created a patch to solve this.
Comment #4
damienmckennaLet's make that a critical bug... *gulp*
Comment #5
damienmckennaIt turns out this is a duplicate of #3221636: Most recent backups in saved backups tab , so I'm going to close this one and I'll give focus credit in the other issue.
Comment #6
larisse commentedI don't think that is a duplicated issue, because the problem here is because in schedule backup, the backup is not saved. In another issue, I don't think that is really a issue, cause the "issue" was the order that backups is been showing, and not that backups is not been saveds.
Applying the patch in #3221636, the problem here still occurs.
Comment #7
damienmckennaApologies, you are correct.
Comment #8
paulocsI'll review it.
Comment #9
paulocsIndeed the bug exists and it is fixed with patch #3.
When the
Number to keepis set, the backup process stop to work, it is not added the next scheduled backup and it is not deleted the oldest backup.We should add tests for this feature so we can prevent regression in the future as this is a key feature... For now I think this can be committed and we can open a follow-up issue to write the tests.
Comment #11
damienmckennaI created a separate issue for test coverage: #3223040
Committed. Thank you.
Comment #12
paulocsThanks @DamienMcKenna
Comment #14
vzimmer commentedThe applied fix let me doubtful.
By design, getting the N files to delete should be resolved by using the "SORT_DESC" filter combined with "start at N" parameter (aka "keep N files").
Doing an ascendent sorting will do the opposite (keep the N oldest files and remove the "total - N" newest ones => including the one we just have generated).
Looking closer, the bug is an historical one, implemented in Drupal\backup_migrate\Core\Destination::queryFiles().
If you take a look at the uasort() method, you will see that the comparison are made "upside down".
Actually, Drupal\backup_migrate\Core\Destination::queryFiles() returns ascendant sorted results when called with "SORT_DESC" and descendant when called with "SORT_ASC" !