Impact of leaving app group running in SureBackup

[michaelryancook]

Hello and sorry if this has been covered before. I did search but was not able to find an answer.

If I leave a SureBackup job running via the "keep the application group running..." checkbox, is there any conflict when the backup job the VMs are "mounted" from runs? Will the job still be able to backup the servers and if so will the app group in the virtual lab be impacted?

My understanding is that as the virtual lab VMs do not maintain changes thru a reboot then the changes are being written to a different location and they would not be impacted unless the retention period required removal of that restore point.

[foggy]

Michael, SureBackup job stops and virtual lab shuts down when backup job starts that is going to write to the same backup file that is used for recovery verification. So everything depends on the backup method (forward/reverse) and restore point selected in SureBackup job. This also applies to the jobs with the "Keep application group running" check box selected.

[michaelryancook]

Thanks Alexander. I am using reverse incremental and the SureBackup job will be using a restore point that is 7 days old whereas my retention is set to 28 days. Based on you clarification I should be able to leave it running for up to 20 days before it would be shut down as at that point the backup would want to remove the restore point.

[nefes]

Michael, it is not so.
For using 7 days old reverse incremental restore point in SureBackup, you actually need to open all last 7 files (since every .vrb depends on .vbk and all .vrb-s between them).
So every next run of backup job will modify your .vbk, stopping SureBackup for that.

[michaelryancook]

Ah, yes, I didn't think of that. Thanks Nikita. I see the same situation would be present with forward incremental as it would require the .vbk plus associated .vib files and the .vbk would constantly be updated if the chain was as old as the retention period. Hmm, I guess my options are they have a single day at a time to test or else we could restore to a different location and attach the restored VMs to the lab vSwitches. I would prefer the former as the latter would require extra disk space as well as time to restore.

[foggy]

I see the same situation would be present with forward incremental as it would require the .vbk plus associated .vib files and the .vbk would constantly be updated if the chain was as old as the retention period.

With forever forward incremental - yes, however in case of regular forward incremental, backup files are not touched during subsequent runs.

You can also copy backup files to some other location specifically for SureBackup.

[michaelryancook]

Thanks for bringing up a couple options for me Alexander.

[Alan_ORiordan]

So if you have your vLab set for the latest restore point on (for example) a Monday and the backup is run using forward incremental will it need to shut down the lab? Does it not just create another .vib incremental file for a more recent restore point? Leaving the previous .vbk (synthetic) from Saturday (for the running vLab) In that case with a 5 day retention policy you could run the lab Mon-Fri before the configured synthetic full job on the Saturday rolls the .vibs into a .vbk?

To demonstrate:

Saturday.vbk (Synthetic) - Virtual Lab SureBackup job using this
Monday .vib - Created without shutting down vLab?
Tues .vib
Wed.vib
Thursday.vib
Friday.vib
Saturday.vbk - vLab needs shut down before the synthetic full is run again?

For a longer term lab I take your point that a new Veeam B&R server with a restored copy of the VM's would be more appropriate so nothing interferes with the lab files

[foggy]

In case of simple forward incremental the lab will not be shut down, since VBK file is not touched during incremental backup (which is not the case with forever forward incremental mode).