On 9/6/21 2:19 PM, neumei...@mail.de wrote: > With what I have learned from you so far I am going to implement the > following scheme(one job, one client): > Three pools: one incremental(dailyPool), one differential(monthlyPool) and a > full pool(halfannualPool). > > - incremental backup every night with a volume-retention of 40days > - differential backup every 1st february-june and august-december (at night, > same time) with a volume-retention of 7months > - full backup on january 1st and july 1st (at night, same time) with a > volume-retention of 12months > > file- and job-retention for that single client are set to the maximum > volume-retention. > -> File Retention = 12 months , Job Retention = 12 months > > Are there any mistakes? What can I do better?
That looks fundamentally sound, though it may be a little more complex than usual to write a suitable Schedule. Also, I note that I misspoke in the course of describing my setup. I said "Differential backup (based upon the last Differential or higher, so it records all changes since the last Differential or Full)," but this is of course wrong. A Differential backup records all changes since the last *FULL* backup ONLY, thus resetting the change history. Because of this a full restore requires only the last Full backup, the last Differential backup, and any incremental backups since the last Differential. > There just popped up another question in my head: > - should I preferably use the Virtual Full option to make full backups or the > normal full backup-option? Are there any downsides? It depends why you are doing full backups so infrequently. If it is because you have an extremely large dataset that takes a long time to do a full backup, then a Virtual Full backup can be a very good option because instead of actually having to run a complete new full backup, you use your past Full backup (which may be virtual) and the history of backed-up changes since then (i.e, the last Differential and any incrementals since the last Differential) to synthesize a virtual backup containing the calculated current state of the backup set. It can offer a significant savings in job time and network transfer bandwidth, but should be verified against the client from time to time to make certain that it does closely represent the actual state of the backup fileset. It is discussed in more detail here: https://www.baculasystems.com/incremental-backup-software/ Virtual Full backups are a good alternative if you would like to do Full backups more often but are limited by resource constraints. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
