On Thu, Feb 25, 2021 at 3:48 PM J W <jsw...@gmail.com> wrote: > 1. The full backups are about 2.8 TB with 12,000,000 - 20,000,000 files > and each run for 2 - 3 days. This is a problem since it means that we can > lose up to three days of files if someone has a problem. > I am looking for suggestions about how to configure my backup schedule to > avoid this. >
My solution to this was to go to an incremental-only schedule with virtual full backups. The virtual fulls run in hours instead of days. 3. I would try Virtual backups. > Can I just run virtual full backups periodically after the first full > backup? I already have full backups so I could just schedule virtual full > backups instead of full ones. > Basically yes. > Do I need separate media types or devices for Virtual Full backups? My ZFS > partition is already at ~ 80 % so I do not have much room. > No, you don't need a separate media type. You can set "Pool" and "Next Pool" to the same media pool. Getting it to not deadlock can be tricky. I ended up setting up each pool with an autochanger with two virtual devices, and setting Max Read Jobs to 1 to make sure that there would always be one available for writing. > > Are Virtual full backups sort of like pruning so that my oldest backup > data is from when the last VirtualFull took place? > Yes, but the VirtualFulls are backdated to the oldest incremental in the last VirtualFull job. It ends up looking a lot like a normal full followed by a series of incrementals, the date of the full just rolls forward over time. Note that when the virtualfull runs you'll need to have at least as much free space as the full backup you're consolidating, since it's effectively a copy followed by a prune. -- David Brodbeck (they/them) System Administrator, Department of Mathematics University of California, Santa Barbara
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
