GFS to tape and how peroidic fulls to disk affect the setup

[Dark-Sider]

Hey guys,

I use a quantum Superloader 3 with 15 LTO-9 tapes and 1 Cleaning tape in conjunction with our 2-Tier backup2disk architecture.

The backup-infrastructure is nothing too complicated, just a few ESXi hosts and a couple of bare metal machines that have independent primary backup jobs. Depending on the size and criticality of the machines we have:
- One forever forward incremental chain (18 restore Points) for a ~40 TB storage tank
- Several ESXi hosts with 20 restore points, normal incremental backups with, peroidic fulls each week.
- Bare metal mimics the ESXi hosts settings

Those backups are then copied to a separate NAS building a GFS archive (7 daily backups, 4 weekly, 12 monthly, 10 yearly)

To make the backups portable for off-site storage we added above mentionend tape library and I configured a GFS Tape-Pool. The idea is to have 7 tapes for daily / weekly backups and a growing amount of tapes for monthly and yearly backups (both monthly and yearly get stored off-site)

What I noticed when the job ran the first time, it created a synthetic full backup as a monthly set (using ~3 Tapes). Then daily increments were written to the daily tapes (makes sense, saves tapes as they reference the monthly set). I assume the weekly set will do the same.

Since the GFS job works on our pirmary backup source, most backups don't have 31+ restore points and some of them even only have 6 .vibs for each .vbk. Then a new full backup is created. How will this affect my GFS pool? I assume that once a new full backup is created by the primary job, it needs to be written to tape, since the following .vibs are incompatibel with the monthly synthetic vbk, potentially wasting a lot of tape space.

What's with the forever forward 40 TB incremental backup that "only" has 18 restore points? Will result to a mid-month .vbk backup once some of the increments are no longer present on disk? In theory all the newer increments should still be compatibel with the synthetic .vbk. because only older increments got merged into the .vbk on disk, not affecting the tape stuff. But I noticed some odd behaviour with other tape jobs when the tape's rention period exceeded the amount of increments of the underlying forever forward incremental backups.

What is the best practice to not waste tape space? Switch to monthly .vbks instead and time them so the monthly tape job runs only after the monthly .vbk was created?

thanks,
Dark-Sider