I’m wondering about how the database recovery landscape is shaping up these days. There are so many options available, and they differ from one SQL Engine to the next. Regardless of your engine, and the failover capabilities available to you, one thing that seems to be pretty common in just about any implementation is the backup of the database to disk, using whatever tools are available for the engine you have deployed.
This seems to be the easiest common denominator for disaster recovery. It may be as simple as making a copy of the actual database file, the execution of a complete database backup to a file, or the extract of the database content by creating a complete set of SQL insert statements, and sending those to a file. At the end of the day, the backup content is a file, which may be copied to other resources for disaster recovery purposes. Every engine I have worked with supports one of these strategies to backup the database to disk.
One thing I have noticed is that many implementations, even with sophisticated failover strategies, include a database backup to disk for a complete worse case disaster recovery solution. Even though they may be using something like Always On, database clustering, co-location, Database Replication or Mirroring, or even disk based replication such as SAN replication, there seems to be one further ace up the sleeve strategy of a complete database backup to disk, just in case it’s needed.
And, the complete database backup can be used for other purposes; it’s not restricted to disaster recovery needs. It can be used to update databases for other environments such as system testing, training, development, Quality Assurance, etc.
What are you seeing for your installations? Are full database backups a common place thing? If they are, what restrictions to you place on those complete backups? Do you have a special place you store them? Do you copy them to other locations in your enterprise?
Drop us a note with your suggestions…
Cheers,
Ben