- 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).
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.
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?