On 6/10/22 1:46 PM, I asked:
In the current (11.0.6 / March 2022) bacula manual, in section 10.5.7, it states:We added two new Pool directives, FileRetention and JobRetention, that take precedence over Client directives of the same name. It allows you to control the Catalog pruning algorithm Pool by Pool. [...] Currently, there is a bug in the implementation that causes any Pool retention periods specified to apply to all Pools for that particular Client. Thus we suggest that you avoid using these two directives until this implementation problem is corrected.Since this is in the section titled "New Features in 5.0.0", does this caveat still apply [to version 11.x]?
Anyone? I'd really like to use that feature, but only if it doesn't have the
bug and apply to all Pools for a given client.
Alternatively or additionally, I'd love to get feedback on this approach:
Currently, I have a schedule like this:
Schedule {
Name = "CompleteCycle"
# Full backups on first Saturday of each quarter
Run = Level=Full jan 1st sat at 00:05
Run = Level=Full apr 1st sat at 00:05
Run = Level=Full jul 1st sat at 00:05
Run = Level=Full oct 1st sat at 00:05
# Differentials every first Saturday of months where no Fulls are scheduled
Run = Level=Differential feb-mar 1st sat at 00:05
Run = Level=Differential may-jun 1st sat at 00:05
Run = Level=Differential aug-sep 1st sat at 00:05
Run = Level=Differential nov-dec 1st sat at 00:05
# Incremental all other days
Run = Level=Incremental 2nd-5th sat at 00:05
Run = Level=Incremental sun-fri at 00:05
}
and with the retention periods set in pools like this:
# Full == Complete backup of every file.
Pool {
Name = Full
Pool Type = Backup
Label Format = "Full-"
Recycle = yes # Allow recycling of purged volumes,
Recycle Oldest Volume = yes # ... and pick the oldest one, if needed.
Action On Purge = Truncate # Allow purged volumes to be truncated on
disk.
AutoPrune = no # Pruning handled as part of catalog
backup.
# This is where pool definition necessarily interacts with the schedule:
Volume Retention = 1 year # Go way back, 4 quarters / full backups,
Volume Use Duration = 1 month # ... but cycle in new volumes more
frequently.
# Together, these two together place an upper cap on the space consumed:
Maximum Volumes = 100
Maximum Volume Bytes = 100GB
}
# Differential == since last Full, irrespective of previous Differentials.
# (thus, differentials are "complete" and do not need other differentials)
Pool {
Name = Differential
Pool Type = Backup
Label Format = "Differential-"
Recycle = yes # Allow recycling of purged volumes,
Recycle Oldest Volume = yes # ... and pick the oldest one, if needed.
Action On Purge = Truncate # Allow purged volumes to be truncated on
disk.
AutoPrune = no # Pruning handled as part of catalog
backup.
# This is where pool definition necessarily interacts with the schedule:
Volume Retention = 1 quarter # Keep only as long as the Full it is
atop,
Volume Use Duration = 1 week # ... but cycle in new volumes each
backup.
# Together, these two together place an upper cap on the space consumed:
Maximum Volumes = 50
Maximum Volume Bytes = 50GB
}
# Incremental == since last backup of any kind (Full, Diff., or Incr.)
# (thus, incrementals build on all previous backups, including incrementals)
Pool {
Name = Incremental
Pool Type = Backup
Label Format = "Incremental-"
Recycle = yes # Allow recycling of purged volumes,
Recycle Oldest Volume = yes # ... and pick the oldest one, if needed.
Action On Purge = Truncate # Allow purged volumes to be truncated on
disk.
AutoPrune = no # Pruning handled as part of catalog
backup.
# This is where pool definition necessarily interacts with the schedule:
Volume Retention = 1 month # Keep only as long as the previous
Differential.
Volume Use Duration = 1 day # ... but cycle in new volumes each
backup.
# Together, these two together place an upper cap on the space consumed:
Maximum Volumes = 50
Maximum Volume Bytes = 25GB
}
Given the Schedule and the Pools, I now define clients like this:
Client {
Name = {{ token_data.client }}:FD
Address = {{ token_data.client }}.{{ ansible_domain }}
Catalog = PrimaryCatalog
# File and Job Retention, per Client, but Job and Schedule figure in too.
# Decision rationale:
# - File = If someone wants a specific file, it's probably user-error
recover,
# and therefore we need to at least retain file information in
the catalog
# to cover the period for each *Full* backup.
# - Job = Make this a bit longer, but if we recover a job, it's the
__whole__ job.
# Therefore, this is about disaster (asteroid) recovery.
File Retention = 1 quarter
Job Retention = 1 year
}
I think that mostly does what I want, as indicated in the comments.
However, I'm sort of breaking the recommended rule of retention periods:
File Retention ≤ Job Retention ≤ Volume Retention
I think what I'm doing is "safe", but I'm having to write my own prune script
to obey the volume retention periods over those defined for files and jobs so that I can
reclaim space more quickly.
In my mind, it would be better if I could specify File- and Job- retention periods
in the Pools to override the clients such that I could clean out file and job refs
in the DB faster for volumes which are no longer needed (e.g. every incremental
>= 30 days, after the next successful differential or full).
Anyone see a hole in my thinking, or a better way to do things?
Thanks
Eric
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
