Backing up Fulls Weekly from Storage Repository

[Ontittech]

We are currently working on implementing a GFS backup solution to tape for offsite archival, and have run into a bit of an issue.

Currently we have 17 Backups Jobs backing up a total of 280TB of VMs to a Backup SAN, which ends up at 126TB of Compressed full backups. These Backups have 14 restore points, with weekly Synthetic fulls

The VM Backup Jobs are configured as follows:
Backup Mode: Incremental
- Create Synthetic Full Backups periodically (1 day of the week, different per Job to spread load)
- Transform previous backup chains into rollbacks (to ensure we only keep 14 points)

These backups run throughout the day at various times to ensure we can run all jobs successfully (mostly between 6:00PM - 4:00AM)

The Tape drive is a Quantum Scalar-i3 with dual drives connected directly to repository server that is serving the storage for the Backup SAN.

The Tape Backup GFS pool has been set to the following:
- Add Tapes from Free Media Pool automatically when required
- Daily Media set (unchecked)

- Weekly Media set overwrite (1 week) (for while we test)
- Use any available Media
- Do not append
- Export to vault Offline Media

- Monthly Media set overwrite (12 months)
- Use any available Media
- Do Not append
- Export to vault Offline Media

- Quarterly Media Set (Unchecked)

- Yearly Media Set (1 Year)
- Use any available Media
- Do Not append
- Export to vault Offline Media

- Enable Parallel Processing for tape jobs using this media pool up to (2) tape drives simultaneously
- Enable Parallel processing of backups chains within a single tape job

And the Backup to Tape Job is set to the following:
Backups - (each of the 17 Jobs is selected)
Media Pool - The Tape Backup GFS Pool is selected
Options - Eject Media (Unchecked for testing)
- Export the following media sets upon Job completion (Weekly, Monthly, Yearly)
Advanced Options - Process the most recent restore point instead of waiting

But the problem is the Job has now been running for over 130 Hours, and keeps stating that jobs have changed and so a retry is required. So from what I can gather, its trying to continually process the whole backup chain for all the jobs, but because the jobs are changing before the Tape job completes the tape job will just keep retrying ad infinitum.

All we are really concerned about is getting the most recent Full VBK for each of the VMs from the backup SAN on a weekly basis as this tape solution is only for DR purposes (in case the building is cratered, and at that point any backup is better than no backup, and the exact point it was backed up is a minor point)

So the question is, is there a easier way to implement this? We want to grab the VBKs from the Backup SAN so we don't impact the performance of the production SAN, but with having the VBKs being created on various days across the week it looks like the current implementation is not going to work

Thanks

[HannesK]

Hello,
if I did not oversee anything, then I can suggest two options. Right now your are trying to copy 126TB to tape with one job. Because the transforms on the backup jobs happen on different days, it will lead to issues.

Option 1: you use multiple tape jobs that run after the transforms of the backup jobs. So you have one week time to finish the job (well, not really, because you don't want to run backups and tape jobs at the same time)

Option 2: you change to "forever forward incremental" backup mode and use "Virtual synthetic fulls". That means, you do not need space, but the GFS job will create a virtual full to write the latest data to tape.

To speed up transforms, you could also consider using ReFS.

Best regards,
Hannes

[Ontittech]

I believe we are currently using option 2, but the issue is because the entire tape backup job is so large, the GFS rescan causes jobs that had been completed already to update to have to run again because there has been a backup of the job in the interim.
I am going to try option 1 and split the backup to tape jobs into 7 daily jobs (So the backup to tape runs after the Synthetic Full Backup Job) depending on which day the backup Job runs its synthetic fulls to see if that helps.

[HannesK]

Hi,

Transform previous backup chains into rollbacks

according this you are using the slowest mode that exists. The mode I mean is if you only check the "incremental". Nothing synthetic. In the end it does this (the first animation)

The forever forward incremental mode is the only mode where the virtual synthetic backup for GFS works.

But no matter which backup mode, I would say it's a good idea to split over the week and try to avoid having backup and tape jobs at the same time.

Best regards,
Hannes