Backup Preparations

I’m sure that many data professionals recognize the importance of having backups in the event of some issue. Many of you will schedule these as soon as you create a database, and then not think much of the process, ignoring it as long as the backup job continues to run.

As you gain experience, you may even set up backups on new instances and versions without much thought, assuming you know how the process works. That’s probably true of SQL Server, as the backup system and structure hasn’t changed for years. However, do you think backups work the same on other platforms, such as Oracle, PostgreSQL, or MySQL? What about MongoDB or Neo4j? Don’t we just run the backup command to a file and the restore from file sequence if there is an issue?

Backups aren’t the same on all platforms, and they may function differently enough that you can find you aren’t prepared for a disaster situation. I was considering this over the last week as I read about the challenges of restoring from Azure SQL Database and Amazon RDS. With the popularity of both cloud computing and SQL Server, we have a few different flavors of platforms between on-premises installs, AWS, Azure, and likely other hosted solutions.

Whenever you work on a new platform, even if it’s a variant of one you have experience working with, there is a chance that the techniques and commands you run to manage backup or restore will change. Since a restore situation is often a stressful event, with the pressure of an RTO upon you, this isn’t the time to learn that your backup preparations are inadequate.

As much as I might joke about ensuring your resume is up to date in case of a restore problem, I would emphasize that your resume isn’t going to be as helpful if you are negligent and unprepared because you haven’t done everything you could to be ready for a disaster. While your employer might not allocate enough disk space or other resources to ensure their RTO and RPO can be met, you can certainly ensure that your skills, knowledge, and recommendations aren’t the reason that data is lost.

I periodically practice restores, I’ll take a tail log backup, I’ll ensure that I understand how to export a BACPAC, all to be sure that my skills are up to date. I don’t want to encounter a situation where I need a filegroup, point in time, or striped backup restore and not know what I’m doing. You might want to do the same, taking time every month to ensure that you perform some different restore technique. Just in case disaster strikes next week.

Steve Jones

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged , . Bookmark the permalink.