Hi Dima, I believe I have gone through the overview section but I shall do so again, having gained some personal insight/experience with it (it often never helps reading the "manual" before you've used the product much!).
However I have an excellent case in point right now having agonised yesterday over how I would like to manage tape backups.
To support my testing (of both SOBR and tape) I'm running a second, completely independent, parallel backup chain which is a Forever Forward job, currently configured with 14 RPs but which, as of yesterday, had only been running for a week so was up to 7 RPs as of yesterday afternoon.
After much deliberation, I decided the following:
1) That I would like to run a daily tape job, doing either a synthetic or active full (not decided yet) at the end of each week, probably on Friday or Saturday (Note: I already have off-site copies for now)
2) I would like subsequent incrementals to go to the same physical tape so each week a tape should consists of the full .vbk then generally 6 x .vib
3) I will start a new media set each week on the same day as I run the full backup, this should ensure that the chain is kept together
4) I would like to rotate these through 8 tapes, so therefore I should be able to maintain 56 RPs on tape quite easily
5) To achieve this, I'll configure an overwrite protection of 8 weeks (for now, this can get slightly more complicated if jobs run slightly late etc. but I'll re-visit that later)
So, looking at my (per-VM) test backup set, I currently have one .VBK and 7 .VIBs per VM, representing approximately 7 days of backups (I might have paused it for a day so the range might span a little more)
Knowing that my full backup as a single .vbk comes in around 1.6Tb or so, and my incrementals average about 25Gb/day, even taking into account 10% larger due to per-vm, I should easily fit this set onto a single tape as first run job.
I configure a media pool as follows:
1) To process BOTH full AND incremental backups
2) To create a new Media Set each Saturday
I configure the job to run yesterday evening, expecting the following:
1) Create a new media set as this will be the first media set in this pool
2) To copy the .vbk files to the tape (1 per-vm, somewhere around 1.6-1.8Tb)
3) To copy the .vib files to the tape (7 per-vm, somewhere around 175 - 250Gb) So *total* on tape should perhaps be slightly over 2Tb worst-case
4) To have enough space on the tape to sqeeze on another few incrementals between now & Saturday as an exception
5) To ensure I have another blank tape available for Saturday when a synthetic full (to tape) is configured
What I actually found when I came in this morning was that the job had so far processed, read & transferred 2.4Tb, waiting for a second tape, and was *only 70% complete* !!!
I then immediately reviewed both simple repositories that make up this SOBR to check their sizes on disk: Repo1 has 635Gb, Repo2 has 1116Gb - TOTAL 1751Gb !!!
So how on earth can I be up to 2.4Gb already at only 70% completed???? IT MAKES NO SENSE!!!
When things like this are happening, I can make the most detailed plans in the world but they mean absolutely nothing in the real world so I really do not know what to do
[Edit: Just to confirm, I've just gone through the stats for the original source job and confirm the following sizes written to disk, as reported by the job itself:]
Incr 1 26.5Gb
Incr 2 5.9Gb
Incr 3 23.7Gb
Incr 4 21.3Gb
Incr 5 23.9Gb
Incr 6 22.8Gb
Incr 7 36.1Gb