Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I'm using an aegir instance installed by the latest v. BOA-2.2.5. Not quite sure what version of the GC module is included in that, but should be the latest I suppose.
And I'm using the "Hosting backup garbage collection" settings described in the example:
https://drupal.org/node/1895538
I get 8 automatic daily backups. Each day a new backup is made and oldest daily is deleted. But there's no weekly or monthly (4 weeks) backups retained. Just those 8 dailies.
I've tried various diddling with the settings, but the example (link above) seems clear enough.
I see three possibilities:
1) I'm doing something goofy in my setup
2) the design behavior changed since that example configuration (Created by muschpusch on January 22, 2013)
3) A logic bug creeped in.
Does anyone have GC working as expected? Any suggestions appreciated.
-- Cronin
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | only_daily_backups-2270539.patch | 713 bytes | northstowe |
| #10 | Capture.PNG | 12.56 KB | northstowe |
| #10 | Capture.PNG | 28.04 KB | northstowe |
Comments
Comment #1
helmo CreditAttribution: helmo commentedThe code for this module has moved to hosting_site_backup_manager.
Comment #2
fuzzy76 CreditAttribution: fuzzy76 commentedI know it's deprecated, but FWIW I'm seeing this with Hosting Site Backup Manager 6.x-2.0 as well.
Comment #3
fuzzy76 CreditAttribution: fuzzy76 commentedThis is probably also the same as #2159535: The backup schedule isn't followed
Comment #4
colanCan someone confirm that this is still happening in Aegir 3 (7.x-3.x)?
If so, we need to fix there first (and then it can be backported). Otherwise, someone can directly fix this in Aegir 2 (6.x-2.x).
Comment #5
Jon PughDefinitely NOT seeing backups happening!
Marking Major... even though I want to mark it critical.
Comment #6
Jon PughSorry, I misread.
I'm not getting any backups on schedule at all...
Comment #7
Jon PughOk, it's too early for issue reporting!
My queue was off, sorry about that.
Still think this is a major problem, though ;)
Comment #8
colanSo still waiting for confirmation in 3. When testing, please make sure you've got a version of the module from June 30th or later to account for #2756411: Backup tasks are not being generated.
Let's leave as Major. Critical would mean that none of the schedules are working.
Comment #9
Neograph734Cross-posting from #2756411: Backup tasks are not being generated:
Comment #10
northstowe CreditAttribution: northstowe commented"So still waiting for confirmation in 3."
I can confirm that we are seeing this in 7.x-3.9 on a test site upgraded from 6.x-2.1 - where we also see the issue.
Using settings:
We have 8 daily backups only, task log confirms deletion of backups that are expected to be retained.
Andy
Comment #11
colanThanks! Patches welcome.
Comment #12
northstowe CreditAttribution: northstowe at University of Cambridge commentedI have discovered that there is a small difference between the function that chooses backups to remove and the function to generate the example backup schedule on the Hosting->Backup Manager page and that appears to be the cause of this issue.
In hosting_backup_gc_compute_backups_to_remove() it uses the difference between current time and the backup timestamp to decide which backups are in the same pocket of time, in _hosting_backup_gc_example() it uses the backup timestamp.
By using the difference it introduces less variance between the values for the pocket resulting in backups intended to be retained as weeklies being 'pocketed' with more recent backups and thus deleted. In my debugging I found that the actual results of dividing the difference by the period were 2.0002 and 2.278 for two backups - so both 'floor'ed to '2' whereas dividing the timestamp by the period yielded 'floor'ed values of 2459 and 2460 so the weekly gets retained.
Simple patch attached
Comment #14
helmo CreditAttribution: helmo at Initfour websolutions commentedThanks, committed.