I have a query around how to properly rerun a failed SQL backup.
If the scheduled SQL job fails and you want to rerun the backup, I understand you can go into the resource group and click "Back up Now" and select the relevent policy. However, is this then classed as an "on demand" backup and therefore may be subject to a different retention policy?
If this is the case, how do you rerun a failed backup and still make sure that it has the correct retention as set as per standard scheduled backup retention?
Do you rerun the job from within SQL Management Studio (we use SQL Agent to schedule rather than Windows task scheduler), via SnapCenter "Back up Now" or is there another method I'm unaware of?
Solved! See The Solution
2 REPLIES 2
Yes you are right, SnapCenter applies 2 differet retention between the scheduled backup and the on-demand backup, you can define the retention during the policy creation.
If you have to re-run the failed backup and want to apply the scheduled retention you need to trigger the backup either from the task schdule or from the sql schedule.
In this way SnapCenter things that the job started as per schedule and it will apply the proper retention
Fantastic thanks for the prompt response.
On that note, is it safe to rename the SQL jobs or will this affect SnapCenter in any way?
The reason I ask is that we create out backup jobs via the PowerShell cmdlets and using this method there is no option to name the SQL Job so the jobs are created with the name format "SnapCenter_RG<resource group ID>_policy<policy ID" (e.g. SnapCenter_RG10_Policy16), so it's difficult to see which backup job is doing what job.
I notice in the code that the SQL Job runs there is a "schedulename" parameter which is the same as the SQL job name, I wouldn't want to cause any issues by renaming the SQL jobs.
Edit: NetApp have confirmed that it is not supported to rename the SQL Agent jobs. They admitted the naming standard is not clear and are expecting improvements in 4.1 release.