Help with setting tape options for append

[Blue407]

Morning All

Just come from BackupExec, where I'm used to doing things a certain way (Logically I believe)

I have 2 backup jobs:-
1. Critical Servers 2 Disk - Runs every 2 hours during the working day. Reverse Incremental so the latest file created is always a full backup.
2. Non-critical servers to Disk - Runs every 4 hours during the working day. Reverse Incremental so the latest file created is always a full backup.

I have now created 2 new backup jobs:-
1. Critical Servers 2 Tape - To run every night at 20:30, to copy the last backups from local disk to tape. Because I use reverse incremental I have a full backup to put on tape.
2. Non-critical servers to Tape - To run every night at 22:00, to copy the last backups from local disk to tape. Because I use reverse incremental I have a full backup to put on tape.

Tapes:-
Monday tape (re-used every week)
Tuesday tape (New one each week, kept for 2 years)
Wednesday tape (re-used every week)
Thursday tape (re-used every week)
Friday tape (re-used every week)

I have one media pool called 'Daily Tapes', all jobs use this pool. I only have a single LTO7 drive, using LTO6 tapes.

The critical servers works to tape okay, it automatically clears the tape off and puts the full backup onto it.

The non-critical job does not work, I want it to append to the tape that's already in there, after the critical server backup.
How do I acheive this?

Thanks in advance for ideas and suggestions.

[Shestakov]

Hello Paul,
Thanks for the clear explanation. What Media set creation option is activated in your case. I suppose it`s set as Create new media set for every backup session and "non-critial" job can`t use the tape since it`s locked once the "critical" job is over.
By the way, have you considered tape GFS retention?
Thanks!

[pkelly_sts]

Welcome to the rollercoaster that is BExec-to-Veeam migration!

I wonder if it's worth configuring a *single* tape job with both source backup jobs (critical and non-critical) in it to run at 20:30? Should all hit the same media set then I'd imagine...

[Shestakov]

I`m sure you will be glad in the end of migration roller-coaster

I wonder if it's worth configuring a *single* tape job with both source backup jobs (critical and non-critical) in it to run at 20:30? Should all hit the same media set then I'd imagine...

If backups of both jobs need same retention that`s a good idea which will help you with job and tape management.

[Blue407]

Welcome to the rollercoaster that is BExec-to-Veeam migration!

I wonder if it's worth configuring a *single* tape job with both source backup jobs (critical and non-critical) in it to run at 20:30? Should all hit the same media set then I'd imagine...

Yes, that does seem to be the only way. But not very tidy!

I currently have the following jobs:-

Critical Servers - Backup 2 Disk
Critical Servers - Backup to Tape
Critical Servers - Replication
Non-Critical Servers - Backup 2 Disk
Non-Critical Servers - Backup 2 Tape
Non-Critical Servers - Replication

All very nice and neat, combining the two into 1 job to tape is not so logical

[pkelly_sts]

I detect a little OCD? ;-D

I can see your needs for the separate backup & replication jobs as your two sets of servers have different backup/replication frequency requirements but, seeing as there's only one "final" full backup of each set at the end of the day that you want to write to tape, I wouldn't personally get too hung up on it, I might even go so far as to say that it's neater!

(Side Note: Your backup storage must be EXTREMELY busy if it's creating a reverse incremental every 2hrs AND every 4hrs during the day!)

[Blue407]

I detect a little OCD? ;-D

I can see your needs for the separate backup & replication jobs as your two sets of servers have different backup/replication frequency requirements but, seeing as there's only one "final" full backup of each set at the end of the day that you want to write to tape, I wouldn't personally get too hung up on it, I might even go so far as to say that it's neater!

(Side Note: Your backup storage must be EXTREMELY busy if it's creating a reverse incremental every 2hrs AND every 4hrs during the day!)

Maybe slightly OCD, but sensible naming makes it easier for the Helpdesk Guys to manage it once I hand it over

It's a dedicated server with just over 20TB usable space (RAID 5), dedicated 10Gb network connection to the primary Hyper-V Host and each reverse incremental finishes in just over 4 mins... (Thats 3 primary servers)

I'm extremely impressed with Veeam compared to BE. To our old LTO5 drive, BE used to take > 12hrs to backup 1.3TB. With Veeam I can do a full back to disk in 2.5hrs and then another 2.5hrs to tape, so much faster and more efficient than BE. BE's days are numbered!! I cannot understand why it's so slow in comparison, tested using same hardware etc.

[pkelly_sts]

Wow, that's quick! I always thought reverse incremental was the slowest/most disk-intensive operation (except for active full obviously).

I'm similar setup, 20Tb RAID-10 but with FC storage all the way but My backup copy jobs take 3+hrs to complete their transforms. Are you doing per-vm backups to Scale-Out repository?

I've never done reverse incrementals myself as I never wanted daily full to tape so up to now have primarily done Forward Incremental with weekly active.

I also found similar performance increase to tape over BExec (4hr full to tape instead of 12hr full in BE) but I can certainly see that with the sort of end-to-end throughput you're getting you might as well make use of (equivalent of) daily full anyway!

[Blue407]

Wow, that's quick! I always thought reverse incremental was the slowest/most disk-intensive operation (except for active full obviously).

I'm similar setup, 20Tb RAID-10 but with FC storage all the way but My backup copy jobs take 3+hrs to complete their transforms. Are you doing per-vm backups to Scale-Out repository?

I've never done reverse incrementals myself as I never wanted daily full to tape so up to now have primarily done Forward Incremental with weekly active.

I also found similar performance increase to tape over BExec (4hr full to tape instead of 12hr full in BE) but I can certainly see that with the sort of end-to-end throughput you're getting you might as well make use of (equivalent of) daily full anyway!

Per VM backups are done, the Critical Server Backup does 3 (All File Servers) and the Non-Critical does 7. These are all to a local Backup Repository. What advantage/difference does the Scale-out one make?

I created separate repositories for the Backups vs the Replications (Same server), just different RAID5 disk sets. With critical servers being backed up every 2 hrs from 08:00 to 20:00 I am planning on 8 weeks worth of incrementals I can go back to from disk (280 points per VM). Our data usage change is obviously not that high, hence relatively small backup times, logs show avg of 4-10Gb change per backup.

The replication works better than MS native in Server 2012 R2, it has reporting options and doesn't randomly freeze/stop . Plus can look at replicating it to multiple locations. Need to do some more testing with this though.

I just get a nice warm feeling knowing I have a full backup I can go back to from either disk or tape, rather than having to worry about incrementals. Plus we have the tape capacity and the time, so why not do it!

We are using LTO6 tapes in LTO7 drive, they have sufficient space for now, plus LTO7 tapes are so expensive!!

Currently BE is still running daily at the moment, until I resolve these last few issues (Both are currently running every day)

[pkelly_sts]

What advantage/difference does the Scale-out one make?

For you? It sounds like Scale-Out won't bring anything to the party as it doesn't sound like you have any capacity/runtime issues to resolve but per-VM splits backups into chains per VM (e.g. a .vbk & .vib/vrb's per VM rather than one huge one per job).

In theory if you have a backup corruption issue it should only affect a single VM backup as opposed to the whole file. If you create a SOBR from multiple simple repositories as well as use per-vm backups then it can speed throughput even more but, again, sounds like that's just not an issue for you anyway.

I created separate repositories for the Backups vs the Replications (Same server), just different RAID5 disk sets.

Do you mean you created different LUNS for backups & replication? Replication obviously goes to VMFS volumes, unless you're talking about the replication metadata which is tiny in comparison to the VMs (generally up to a few 10's of Gb at most I think)

With critical servers being backed up every 2 hrs from 08:00 to 20:00 I am planning on 8 weeks worth of incrementals I can go back to from disk (280 points per VM). Our data usage change is obviously not that high, hence relatively small backup times, logs show avg of 4-10Gb change per backup.

Hmm, that's a lot of RP's there, not sure what the performance would be like trying to go to an RP that far back. I think I have it the right way around when I say that going "back in time" to a long reverse incremental chain is harder work (on infrastructure) than going "back in time" to a long Forever Forward chain.

The replication works better than MS native in Server 2012 R2, it has reporting options and doesn't randomly freeze/stop . Plus can look at replicating it to multiple locations. Need to do some more testing with this though.

I just get a nice warm feeling knowing I have a full backup I can go back to from either disk or tape, rather than having to worry about incrementals. Plus we have the tape capacity and the time, so why not do it!

Can't argue with that!

We are using LTO6 tapes in LTO7 drive, they have sufficient space for now, plus LTO7 tapes are so expensive!!

Yeah, they tend to drop in price about halfway through the life cycle of a tape technology (LTO-5, 6, 7 etc.)

Currently BE is still running daily at the moment, until I resolve these last few issues (Both are currently running every day)

Same here but things are still a bit too unpredictable for me tape-wise to switch to Veeam primarily at the moment, as much as I desperately want to!