Weekly synthetic & monthly fulls to tape

[pkelly_sts]

Given the following:

A source backup job configured as Forever Forward with 56 RPs and monthly active full (say, the last Sunday of the month)
A *daily* tape copy job configured to both process incrementals fulls, and configured to create a weekly synthetic full to tape on Sundays

what is written to tape on the last Sunday of the month?

Will I end up copying both the monthly active full from disk to tape and the weekly synthetic full to tape within that iteration of the tape job?
If so, how can I avoid a double-copy, to the daily media set, in this scenario?

My primarily plan is to have a weekly synthetic full plus the following 6 incrementals stored on the same physical tape, with a new media set started with the synthetic full each week but the requirement for the monthly active full to disk is throwing me a little...

Important note: I'm already planning on running two tape jobs: 1 daily including incrementals as above, and one monthly GFS only keeping monthlys, no weekly or quarterlys.

[Edit: Important note 2: THIS is why we NEED GFS tape jobs to process incrementals!! "One tape job to rule them all..." ]

[PTide]

Hi,

A source backup job configured as Forever Forward with 56 RPs and monthly active full (say, the last Sunday of the month)<...>My primarily plan is to have a weekly synthetic full plus the following 6 incrementals stored on the same physical tape, with a new media set started with the synthetic full each week but the requirement for the monthly active full to disk is throwing me a little...

Please note that source job configuration must not have scheduled synthetic or active full backups. If it does, the virtual full will be disabled even if configured in the tape job. Schedule a standalone active full with Windows Scheduler so that your backup chain does not contain scheduled fulls and configure the Media Pool to create a new media set on Sunday before the tape job starts.

Please check this article to get more details about how virtual full works.

Thanks

[pkelly_sts]

Argh! I'm glad I checked here first now!

OK, so my plan for tapes would still work provided I disable active/synthetic fulls on the source backup & just leave it as a standard FF job.

My main concern is the long FF chain - how badly (or not) is restore performance impacted by having a relatively long (56 RPs) chain? I seem to remember one kind of incremental was significantly worse than the other (e.g. comparing Forever Forward to Reverse Incremental?) if restoring from the older points of the chain. Which way round is it please?

[PTide]

<...>how badly (or not) is restore performance impacted by having a relatively long (56 RPs) chain?

Generally the impact is not very significant as you don't have to collect blocks from all of the previous restore points in order to restore one of them - only needed blocks have to be collected. Also a longer forward incremental chain means higher chances of corruption, so you should consider using a backup copy job.

I seem to remember one kind of incremental was significantly worse than the other (e.g. comparing Forever Forward to Reverse Incremental?)

Reverse Incremental mode is very IO intensive during backup session though restores are not much different from forward incremental. Speaking about restore speed - that depends on how close is the restore point to the start/end of the chain:

F-i-i-i-i-i
r-r-r-r-r-F

See the difference?

Thanks

[pkelly_sts]

OK, understood. Extra copy jobs are not a problem, I'll be doing copy jobs to remote site anyway plus I have enough disk space available that I can run weekly extra backups in a dedicated job & just not bother sending those to tapes if it makes me feel warm & comfy at night...

F-i-i / r-r-F makes perfect sense too, thanks.