Splitting Large VM Backup

[nunciate]

I have a very large VM that we backup with multiple jobs. The VM is over 8Tb using 7 different drives/vmdks. We backup this file server by using 7 jobs to grab each drive so we don't have 1 huge VBK file. I am able to do normal file restores from this with no issues. I have 2 concerns with this method.

First off I am getting an error when I try to do a backup copy of the entire VM over to our DR site. Can setup a single backup copy of the entire VM and have the job know to pull from the 7 different backups or do I need to do something else? I tried choosing the source as "From Jobs" and selected all the jobs but I received an error. I think that one or more of these was done with a different block size and so that may be the issue. I need to run active fulls on all of them to be sure.

My other concern is a full VM restore from multiple backups. I am guessing I can just restore the VM and then do each drive one at a time and reattach them but since I have never tried to restore I am not sure what the best method would be.

Are others splitting up their large servers into multiple jobs? If so what has been your experience?

[tsightler]

I certainly don't recommend this and it's one of the advantages of V7 parallel processing since it can now process multiple VM disks from the same VM concurrently. That's not to say that it doesn't work, as long as all disks are completely independent, but if there are any dependencies then you have to remember that each disk was backed up at a different time. Also, since it's such a large VM it will take a very long time to do a full restore, and you won't likely be able to take advantage of Instant Restore, at least not easily. V7 should be able to easily handle this VM in a single job.

[foggy]

With such a scenario, you will get a mess of restore points containing VM with some single disk each, so you will not be able to restore entire VM from such a backup unless you restore all the disks individually and mount them to the restored VM.

[nunciate]

OK that is kinda what I thought on the restore side. How about on the backup copy side? Should I be able to do a backup copy of the VM using these different backup jobs as a source or is the backup copy looking for the source to be a single backup job?

I will be building out a new backup server with lots of storage in the next couple of months so once that is done I plan on running this as a single job.

[foggy]

Since backup copy job does not perform a simple file copy but syncs the latest VM state instead, and the backed up VM is the same in all those backup jobs, only one (the most recent across all newly created by all backup jobs) restore point for this VM will be copied during each copy interval. Cannot imagine what you can get in the target repository with this setup.

[antspants77]

HI,
I have a similar situation, but my customer's server is 20TBs. This is our initial engagement with the customers, so we have already expressed to the customer, that they need to make the server smaller by archiving data. The old ways of just letting data grow and then throwing more resources at it to fit in your backup window are over. But in the mean time, we have a challenge around granular restore of tape data. With a 20TB VBK file, you need 20TBs of space (and lots of time) to restore a single file, mail etc. We have analysed all the reports and reduced rate of change / incremental backup sizes significantly by scheduling SQL, Exchange & other jobs only on weekends, and by using the WAN processing mode on Exchange & SQL servers, so we can keep more retention pints and thus reduce the need to restore from tape, but am dreading the day when they want something back from 9 months ago, that is only on tape.

Do you have any other suggestions, for restoring granular data from tape in this scenario that doesn't require us to maintain 20TBs+ of disk space?

[Vitaliy S.]

Hello Tony,

In order to restore granular data you need the entire restore point to be present on the disk that can be accessed by the backup server.

Thank you!

[francs]

Very large single files are difficult to deal with on tape.
We backup all the Veeam files to tape using TSM. Backing them up is no problem and restoring them does take long.
Splitting the VBK files into smaller chunks would help with the following issues:
- If a restore from tape fails for whatever reason you will have to restart from the beginning. With smaller files you only have to restart from the last failed file.
- TSM does space reclamation on it's tapes to optimally use the free space on them. Moving large files around takes a long time and should you have to cancel such a reclamation (to maybe do a restore) you will also have to restart this job.
In fact I've had to cancel these house keeping jobs in order to free up the tape drives for the next evening's backup run.