Backup Health for long chains

[DaveWatkins]

Hi

This is something I should have thought of sooner but I'm wondering what protection is in place for long backup chains.

Say for example we have a 31 day chain with daily backups and it's reverse incremental so we don't schedule active fulls or synthetic fulls.

As far as I can tell the two maintenance functions that occur (health check and the defrag) both only use the repositories data. Is there a way to make the latest restore point be compared to the existing VM itself using some fairly low bandwidth check? Something like checksumming the VM data against the backed up data to make sure your backup chain is fine?

Is this sort of check even needed or is something already in place that removes the need for something like it?

What I'm trying to work out is if I should be scheduling Active Full backups on some schedule to be safe or if I can have a high degree of confidence that even without them my backups will be good. I'd rather not have to try and schedule active full's if I can possibly avoid it as the time required makes them non trivial to do

Thanks
Dave

[veremin]

What I'm trying to work out is if I should be scheduling Active Full backups on some schedule to be safe or if I can have a high degree of confidence that even without them my backups will be good.

Running SureBackup job with validating backup file option enabled should be enough. Thanks.

[DaveWatkins]

SureBackup isn't something I can run against all our VM's unfortunately. We simply don't have the infrastructure capability to run up all our VM's into a functional setup at our DR site (where our repo is). We'd run into both space and IOP's issues if I tried adding any significant load and doing test restores of our 2TB exchange servers plus DC's and front end gateways would be a noticeable load just from the data movement.

The two times I've tried to set it up for even basic testing it's failed. The first was not detecting the DC being up when it was, and the second was a SQL issue. One I think was fixed in a later VMWare patch but at the time I didn't have time to chase it.

Assuming Surebackup isn't an option, should I be scheduling full backups?

[Vitaliy S.]

In this case, when SureBackup is not an option, scheduling active full backups once a month should be a way to go.

[JoshuaPostSAMC]

I've been digging into SureBackup a lot over the last few months. Just so you know, it isn't doing a full restore of the VM to run the verification against, it is mounting the repository as a NFS datastore, so only the deltas while the VM is being powered on the isolated environment are being written to your production storage where SureBackup is running.

Also, when running SureBackup, only those VMs you include in the "Application Group" are kept running during the entire run. For me that are my Domain Controllers only. Then you add Linked backup jobs to SureBackup and you can configure how many of them to start at a time. So if you have 2 Domain Controllers backed up by Veeam, you could have SureBackup keep the 2 DCs running for the entire duration, but the primary disk is being read directly out of the repository and only the changed blocks while the job is running are written to your datastores, and then however many VMs out of your linked jobs are started at a time. I run 4 at a time, and when one finishes, it powers down the VM, removes the delta files, and then powers on the next VM out of the backup job.

So you don't need full compute capacity at your DR site to be able to use SureBackup to verify all of your VMs.

I'm testing 500 VMs daily on two hosts that are also running production workloads without a problem.

[DaveWatkins]

Hi Joshua

Thanks for that, I had read that in the past but forgotten, that does change the game a bit. Time to go back and give it another go!

Dave