topic Re: SMSQL verify on secondary storage when available only in ONTAP Discussions

SMSQL verify on secondary storage when available only

mheimberg — Thu, 05 Jun 2025 07:13:46 GMT

We have integrated SnapManager for SQL Server with Protection Manager and successfully use the feature to run the verification on the secondary storage.

Recently we had a problem on the DFM server, so the archiving of the snapshot did not take place.

Surprisingly SMSQL failed back for verification to the local snapshot, mounted this one and ran verification on the primary storage.

Under normal circumstances I would be happy with this design, but in this special case, there should be no verification at all if the secondary storage or the archiving-feature is not available.

Is there a way to prevent a local verification if the secondary storage is not available?

regards

Mark

Re: SMSQL verify on secondary storage when available only

qzhang — Mon, 07 Jun 2010 16:25:40 GMT

What you can do is to change your scheduled backup job to not to perform backup verification.

Thanks,

-Qing

Re: SMSQL verify on secondary storage when available only

mheimberg — Tue, 08 Jun 2010 08:46:01 GMT

What you can do is to change your scheduled backup job to not to perform backup verification.

Yes, this is one possibility. Next we schedule a dedicated verification job, because we need the backups to be verified. The question would then be: is that "verify-only"-job acting the same way? That is: if the secondary storage is not available it mounts the snapshot of the primary?

We have to test it....

thanks

Mark

Re: SMSQL verify on secondary storage when available only

qzhang — Tue, 08 Jun 2010 16:27:40 GMT

Verify only job would not try to verify local backup if you specify to verify remote backup.

Thanks,

-Qing

Re: SMSQL verify on secondary storage when available only

mheimberg — Wed, 09 Jun 2010 06:45:29 GMT

Verify only job would not try to verify local backup if you specify to verify remote backup.

Ok, good...but we will test it anyway.

thx

Mark