Feature Request | Test Mode for Backup Jobs

[johnlockie]

I think it would be really cool if we can run a backup job in "test" mode.

This would do all the tasks that a normal backup would do, except not process the VM entirely. Maybe only up to 1% and then finish....or not at all. A simple, "yep everything looks good assuming we are able to process the VM".

The reason I ask is that for teir 1 applications I cannot run backups during certain hours (the hours I am at work). Our bottleneck is usually "source" (the VM being backed up). So when a job runs users can be impacted, especially teir 1 apps. And when we are trying to troubleshoot failed backups it could take days before we get it solved (not good). I cannot actually verify the job works until it runs at the appropriate scheduled time.

For example, I am getting "object not found" - a very simple error that I am sure might be fixed now. The "processing" is not failing, but the actual prep work for processing the job is failing. There's no way to test this....without actually running the job.

[foggy]

This would do all the tasks that a normal backup would do, except not process the VM entirely. Maybe only up to 1% and then finish....or not at all. A simple, "yep everything looks good assuming we are able to process the VM".

This would be similar to starting the job and stopping it manually immediately, no?

[dellock6]

I'm also thinking about the fact that some activities of the backup are out of control of Veeam and delegated to vCenter/ESXi, like snapshots management, so there is no complete way of testing a backup without effectively doing it. A "dry-run" in this situation sounds hard to me.

Luca.

[johnlockie]

This would be similar to starting the job and stopping it manually immediately, no?

Exactly. Except maybe not putting the job in a FAILED state(?). Because every time you cancel a job, it shows up as failed. Basically leave the job state alone (actually, I don't think I have tried this on 6.1 so maybe you guys changed this). I am also not comfortable enough with stopping a job to trust it won't have a negative impact on the backup files, corruption etc. I have seen these take a long time to cancel, and even a few times had to reboot the Veeam servers to get it to stop. Many times snapshots are left behind too, and that requires manual cleanup of the virtual infrastructure

Also @dellock6 these are the exact things I want tested. All of the processes surrounding the actual backup which include creating and mounting the snapshot, permissions to the VM, ability to delete the snapshot, and storage repository requirements, etc. All of this takes <5 minutes and has very little impact on the environment....yet would be a great tool to managing the backups and troubleshooting errors.

Cause when a job fails, and after reviewing logs and making changes, I have no way to really verify it's fixed without running a live backup. Specifically with errors like "object not found", I would like a way to do the dry run.

I am an infrastructure guy, not a programmer....but it seems to me this shouldn't be too difficult to add down the road, and it would only differentiate Veeam further from the competition. Not a deal breaker though, just a suggestion/request from a user.

[Gostev]

This sounds good, thanks for a great suggestion.

[rct]

Launching a job and stopping it manually will only tests vm backup/replica until the manual stop.
A dry run will test them all.
Example : after a vSphere migration some hosts uuid have been changed (?!?) so some vm were backuped successfully and other not.

It will be a good feature !!!

[Gostev]

One of our QC folks suggests that you create a job with all disks excluded from processing to achieve what you want. Pretty genius I think, thanks for the idea Nikita!

[Jamie Pert]

Gostev - will that mean that snapshotting, proxy connectivity and repository connectivity etc are still all tested? If so, that's a genius solution.

I could create a test run for each of the jobs in my Veeam server and run them before a bvackup job and stitch it with a proper job with the new "run after" feature in 6.5.... it's excessive, but could come in handy in some scenarios...

so then when it comes to checking backups in the morning I can see that prior to the backup job the proxy, snapshotting, and repository were all fine

[brupnick]

I have used this method to test my backup configurations in my development environment and it works very well for what you are looking to do. I will say that it does actually back up the configuration files (.vmx, .vmxf, and .nvram), so it will add a restore point to a job. If you can, it would probably be best to create a true test job (rather than temporarily modifying a production job) when doing this.

[Vitaliy S.]

Gostev - will that mean that snapshotting, proxy connectivity and repository connectivity etc are still all tested?

That's correct - excluding disks doesn't affect VM snapshot creation operation, as snapshot is always created for the whole VM (for all VM disks).

[rct]

It would be better if it was a feature but if we can do that way it's a good news!

Thank you.

[damocue]

Hello,

After some time using and upgrading Veeam Backup, I miss a test or preview for jobs. Each time after doing a change on backup infrastructure, I'd like to do a test execution and not a execution. With this option, I think over 70% of first failures will be resolved without getting failed backups. Has anyone missed to have this possibility too?

Regards,

[dellock6]

How can you test a snapshot of a VM without doing it? I have no idea if it ca be simulated...

Luca.

[ZachW]

To add in.. There are definitely things that we could "test" successfully in a pre-flight check but it is very unlikely that we would have the availability to completely test all components to check for a failure without actually attempting to perform these actions.

[damocue]

I was looking for this topic!
As told before, I think there are things that could be tested without doing a snapshot to VM:

• VM found on virtual platform.
• Host found on virtual platform.
• VSS testing.
• Successful backup mapping.
• CBT warning (I'm not really sure about this possibility).
• Time estimation for a backup job. This could be done testing network connectivity, estimation of data readed at VM, etc.

Regards,

[gsroute]

Recently I put this on twitter

@Veeam I had an idea for you that I wish I had, can we have a "Dry Run" option for backups, i.e. test the process without moving any data?

It got a couple of responses:

by @Veeam: Surebackup?^RV

Should clarify, Surebackup would do a dry run of sorts of the recovery.^RV

by @ChrisDearden: don't forget v8 will also have the ability to do a dry run on the application processing side too.

by @Veeam: It's an interesting thought but many problems are with the target storage. Would still require snapshotting the VMs ^DH

good topic for our forums though... ^DH

So here it is.

Basically, what I was thinking is a way to run a backup that wouldn't really move data or interfere with data already there, such as restore points. Basically a test mode that runs through everything but doesn't upset live backups. Would this be a good idea or would anyone else use it to make it worthwhile?

[dellock6]

The trick of excluding every disk can be effective, as long as you have a fixed selection of VMs and not a dynamic component like a datastore or a resource pool.
But in any case, snapshots of the VM will be created, so you will interfere with production.
with V8 you can now check all the used credentials, and this one was one of the biggest need when people asked for a dry run.

If instead is all about estimating size and performances, size can be estimated using Veeam One reports: total size of VMs for the full and daily change for the increments. Then, applying a conservative 50% reduction, you have an esstimate of the final backup file sizes.

[gsroute]

Thanks Luca,

The introduction of credential check will be a big plus, I have seen that as a necessity, similar to Backup exec. but what I am trying to describe is to be able to run a job in test that will check that all elements will actually work, but doesn't involve upsetting the restore points, or copying data over and having to wait etc.

The idea came up when I was troubleshooting a job when one VM started to fail, but I had to create a new job and cancel it when data started moving, this was my only way to test if things were working again. without loosing any restore points from all other VMs.

Thanks.

[justind]

You should check out the new Quick Backup feature in v8. This allows you to re-run a single VM backup within a job and not mess with all the others VMs restore points and CBT etc.

It still moves data but it's pretty handy.