B+R V10 BackupJob Secondary Destination to Nimble Snapshot is not application-consistent

[UlrichThomas]

CaseID #04114901

Hello all,
Backup Jobs with secondary destination to Nimble Snapshot causes crash-consistent snapshots on instead of application-consistent ones.
Running a backup job without a secondary desitination directly as Nimble snapshot, this snapshot is application-consistent.

I think this happend since B+R Version 10.

Regards,
Ulrich

[veremin]

I see that the support engineer is analyzing the logs submitted, so, let's wait for the results of his findings. Thanks!

[foggy]

Hi Ulrich, this might be a UI bug. Please let our engineer explore the logs deeper but seems you're looking at snapshots created by different jobs - backups from storage snapshot (which shows as app-consistent) and snapshot-only job (which does VSS freeze only processing and shows up as crash-consistent, which we should look at closer as it is unexpected).

[UlrichThomas]

Hi, i noticed that there is something wrong by running a SureBackup Job for one of my domain controllers.
SB using a snapshot, the UI shows application-consistent, works fine but using a snapshot, which seenms to be crash-consistent, throws an error:

Error: Results: unable to perform Domain Controller restore from a crash-consistent backup. Be sure application-aware processing is enabled in the backup job settings

[foggy]

We've done some more tests internally and there's indeed an issue, though it's a bit the other way around from what I've assumed above. The backup from storage snapshot job with the secondary target set to snapshot on the primary array results in a crash-consistent state for VMs residing on that snapshot even though AAIP is enabled. This is planned to be addressed in the upcoming update, so thank you for the heads up!

As for the SureBackup issue, it does seem unrelated, so please continue investigating with support.

[UlrichThomas]

For Information:
Both issues are confirmed bugs that will be fixed in upcoming versions. But Veeam support don't have an ETA for that.

[DaStivi]

hi,
i've discovered that storing an netapp snapshot as secondary backup destination does not create an Application Consistent Snapshot... at least my expectation, or what i think i've seen it in the past, that using this in the primary job created an snapshot clone of the primary snapshot that was used in the snapshot backup... but at least in v10 i see the snapshot thats hold up for the default 14days is now only crashconsistent..

creating an snapshot only job, of course the vms in the snapshot are application consitent!

best regards
Stephan

[foggy]

Hi Stephan, already a known v10 issue, please see the above. Should be addressed in the next Veeam B&R update. Thanks!

[DaStivi]

thx for pointing me to this... good to see i wasn't wrong what i had in mind from earlier versions...

another thing i did notice, maybe i i don't understand it correctly, and i'm also not sure if thats somehow related too to this bug...

when trying to create the seconday destination storage snapshot, it does not in one job for me now, where i don't have backup from (primary) storage snapshot is enabled (not even possible, btw.) but basically creating the storage snapshot is possible, because api connection is there to the storage, but not direct san access is given.... but anyway my impression is that it should still be possible to trigger the (application) aware snapshot anyway on the storage array, even when only hot-add or NBD backup is then used!

[foggy]

I'm not sure I fully understand the issue. Do you mean the job fails in case there's only management access to the storage and no data access? If I'm getting you right, you're running a backup job with a secondary destination set to a snapshot on the primary storage - it will expectedly fail and will not create that snapshot as well, the failure occurs at the stage of proxy detection, before even attempting to take a snapshot. You should be able to use a snapshot-only job though - you're anyway not expecting a backup so no reason for selecting a backup repository at all.

[DaStivi]

basically i've an storage integrated in veeam, but no physical connection for storage-snapshot based backup...
backup of the vms schould be via. hotadd/nbd, but still i would like to create an storage snapshot, creating storage snapshot does indeed work without san access to the storage, as this is triggered via the network API, and that is connected...

case1: "normal" veeam backup job to backup repo, no storage snapshot backup enabled (couldn't work, as no SAN access is available), but still secondary backup repo. is set to store an storage snapshot
normal backup does work, but no storage snapshot is created (job does not fail, just no storage snapshot created for secondary backup repo selection)

case2: snapshot only "backup", so in primary backup repository windows in the veeam job, when i select the storagesnapshot,
the storage snapshot is created successfully

[foggy]

Yes, this is exactly how it is supposed to work.

[DaStivi]

Sorry but I've to contradict you on that..

Even wenn not using storage snapshot as backup source, it should be possible to save ah storage snapshot as 2nd option... Even the GUI does offer this! But it's simply not created ... So somehow there has to be some confusion going on... Because when this is how it's supposed to be then the storage snapshot option shouldn't appear (as long storage based snapshot backup is not used )!

Theres Not even ah noticed that it's not being created or an issue happened...

[foggy]

As I've mentioned above, it doesn't even reach the stage where the snapshot is created - the failure occurs at the stage of proxy detection. Since there's no proxy available for backup from storage snapshot, the job doesn't go the storage integration path at all, failing over to available transport methods (hotadd or NBD). The secondary destination option is not even taken into account in this case. That also explains why the storage snapshot option is available in the job wizard - at that moment we have no idea of storage access at the time of actual backup.

[DaStivi]

I understand your point, but! The very same VMs residing on the storage where I don't have ah path to backup from storage snapshot, does make ah (application-aware) storage snapshot on the storage when using the snapshot as primary target...

So technically it is possible to create the storage snapshot without San/snapshot access..

That it does not trigger the snapshot I'm 2nd destination is simply wrong and shouldn't even have ah link to if storage snapshot to backup from is used or not!

[foggy]

I see what you're saying but the current implementation differs for the cases where you select the snapshot as a primary or secondary target.

[UlrichThomas]

Seems both bugs are fixed in 10a. Thanks

[foggy]

Kudos to you for letting us know!