Must-Have Resources – SQL Server Backup & Recovery

One of the things that drives me crazy as I’m getting older is that my brain is losing the capacity to differentiate version numbers.  As I speak travel around speaking with customers and at conferences, I find my self saying things like “I can’t recall if this problem was fixed in SQL Server 2000 or 2005. But you don’t have to worry about that any more.”  Or things like “That feature was added in SQL Server 2008 R2, eh, or was that version 6.5.  DOH!” followed by a loud slapping sound as I whap my palm into my forehead.

The Internet doesn’t forget either.  Recommendations that were once helpful, if not outright essential, now are neutral or even downright bad. So now, whenever I put together new presentations, I always spend a lot of time in research, reassessing my knowledge on the topic.  (That doesn’t mean that I’ll extemporaneously say it wrong, because I speak in an off-the-cuff and rapid style. But at least my notes are usually correct).


Case In Point

Take backup and recovery (B&R), for example.  I’ve been writing about and performing B&R for years.  I’m even part of the team that builds the most popular B&R tool in the SQL Server space.  It’s an extremely important part of what I do.  And yet, even after spending a couple days re-researching topics (yet again), I still manage to get a few of the more specific details wrong because of changes over the years in the feature set.  How so?

During an Expert’s Perspective webcast last week (and available on-demand) covering the top backup and recovery mistakes on Microsoft SQL Server, I mis-explained the details concerning how SQL Server performs a differential backup.  A very clever SC on our team who was also attending the webcast pointed out to me after the session that I’d described differentials working at an 8k page-level when, in fact, they work at the extend-level (that’s a block of eight 8k pages). #FACEPALM!

When describing the differential backup I said that a bit was flipped on each page header and SQL Server would only back up those pages. Instead, whenever a page is changed a bit is recorded on the differential change map (1bit per extent), the backup process then queries these map pages and backs up those extents that have been marked as changed.


The Research Reveals

The cool revelation here is not that I can admit my mistakes.  The take-away from this blog post are all the great articles I read writing my latest slide deck.  These blogs and articles were so good that I needed to spread the word.  Add these to your must read list:

Virtual Log Files must be tamed!

Backup and Recovery Myth Busting

Other Good Sources

And just in case you need a refreshing in the basics of SQL Server backup and recovery, check these out:


  1. Nice article.

    May be off-topic but closely coupled with Backups : I wrote about trimming transactions log file
    hopefully, that will help to give some insights to readers!

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.