I've recently switched our SharePoint 2010 backups from using stsadm to the PowerShell backup-spfarm technique but just have a bit of a worry about differential backups.

Essentially we're running daily full SQL backups of the content database and then weekly full SharePoint backups and daily differentials using backup-spfarm. I've seen before how SQL's backups (through a maintenance job) interfered with differential SQL backups done by 3rd party backup software in that the differential was from the last full, i.e. the last SQL backup, so we have to switch to doing copy backups instead of full by taking it out of the maintenance job and scheduling a separate custom Agent job.

So I'm just wondering if someone can confirm whether SharePoint just uses SQL's built-in tracking of full/differentials (which would mean a problem for us) or whether the two don't interfere for some reason.

I hope to do a test restore using a full SP backup and differential a couple days after the full to confirm but in the meantime I could do with sleeping a bit better!

Thanks a lot!


1 Answer 1


SharePoint will honor the SQL Archive bit for databases. If you run:

  1. Full SP Backup
  2. Full SQL Backup
  3. Diff SP Backup

When you attempt to restore you still need to use the SQL backup or the SP Diff will fail in restoring the databases (or they will be in an inconsistent or corrupt state).

What RPO are you trying to achieve? For 24 hour RPO, you probably can drop the SharePoint diff and stay with weekly SharePoint backup and nightly SQL fulls. IMO Probably the only reason to stick with Diffs at all is if the Search index is too large to rebuild in a timely manner (and they would have to be pretty large, or resource restricted to not rebuild in a 24 hour period). Keeping the diffs also add an additional step to your recovery.

  • Thanks, just good to know so we keep that in mind, but I think you're right in saying weekly full SP and nightly SQL backups, thanks!
    – ebooyens
    Commented Jun 24, 2013 at 8:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.