Am 07-Sep-2021 05:27:41 +0200 schrieb ph...@caerllewys.net: > 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.
Okay, thank you for your help. > 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. Thanks for clearing it up! > > 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. > Okay, I just paid the link a small visit and scanned through the text. It looks quiet interesting and promising. I will come back to it this evening with more time on my hands. If after that I should have any questions left I will come back and write something to the mailing list. Thanks again for your detailed answer and your fast help! Sebastian ------------------------------------------------------------------------------------------------- FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
