Nimble VSS snapshots affecting RedGate SQL backups

[sql-lover]

VSS backups were enabled on all our MSSQL servers few weeks ago. They are running every hour. And since enabled, my regular SQL backups are failing. This does not happen on a specific database but randomly and when it does, RedGate just retries the backup. But this is causing some delays and the logic is skipping a purging step, at the end of the day, I have extra backups that were not deleted because of this.

msdb states that the snapshot backup takes around 30 seconds per database. IT states that Nimble's dashboard or logs says it only takes one second. I do believe it takes longer than that and it is affecting the storage and temporary blocking or disconnecting MSSQL affecting backups while it lasts.

Have someone seen this before? I want these two to coexists, but the errors and problems are happening every day.

[Nick_Dyer]

Hello Jose,

Couple questions:

• Are you using the Nimble Protection Manager functionality for quiesced SQL backups every hour?
• What time are you taking the regular SQL backup?

Whilst Nimble's storage snapshot technology really does take a second or two, if you're using the NPM functionality for SQL quiescing then it could be that it's colliding with regular SQL backup process - as the VSS process may already be in use (NPM will call VSS synchronisation before a Nimble snapshot is taken, if it's enabled).

[sql-lover]

Hi Nick

Thanks for reply.

IT is running Nimble VSS snapshots every hour, which is FULL backups using COPY_ONLY option. I am assuming they are using NPM for that? But I am not sure.

The time varies because we have four different SQL instances, each runs on its own virtual machine. But the differential usually start at 6pm PST. Our backup strategy is one FULL every week plus daily DIFF and that's true for each MSSQL instance. They are scaterred a bit in order to avoid collisions with other MSSQL instances. So let's say that machine A runs its DIFFs at 6pm, then machine B does the same at 7pm.

I am using RedGate backup Pro for my regular TSQL backups. DIFFs time varies depending of the database size of course, but usually takes few seconds to several minutes. What I've seen is that if redGate backup for database ABC runs at 6:05 pm (just an example) and by chance Nimble is running its VSS backup at that time too, then Nimble "wins" and the RedGate backup fails and later retries. The problem is that our TSQL jobs have several steps. So even though the backup succeed, next step did not run and old backups are not being deleted. The failures are also extending the backup time because the retries.

[rottengeek35]

I have seen this happen, too.

I'm wondering why you would do both?  I could see doing NPM replication for DR, or to make it easy to attach a LUN to a different server, but other than that...

I've had to change the times I do my SQL backups, as well as make sure they go to a separate LUN.  If you are doing DIFFS as well as an hourly COPY_ONLY, I'm guessing you are trying to manage your transactions without losing the log chain, so maybe staggering some t-log backups in there would help?

I have all the databases we do nimble replication for set to SIMPLE recovery model, because it meets our RPO/RTO and so far our transaction performance has not been overly impacted.

when you query msdb for backups, what does it tell you?

[chris24 · Accepted solution]

Hello Jose,

Simply set an exception in the snapshot schedule to prevent the Nimble from taking snapshots during your other backup window that does the log consolidation.

Many thanks,

Chris