What Every Accidental DBA Needs to Know Now: Backups

I’ll be presenting a session at the 2016 IT/Dev Connections Conference titled (some) of the Top 10 Things Every Accidental DBA Needs to Know . Why “some”? Because the list is actually endless it’s difficult to say what is considered important for a DBA just starting their professional journey and one who is an established database administrator moving towards Senior DBA status.

In advance of this year’s IT/Dev Connections conference I’ll elaborate on these ten points I intend to cover in my session and will extend this into a regular series of articles aimed at those IT professionals who have found themselves assigned stewardship of their company’s data.

This first two articles cover what are arguably the most important aspects of the Database Administration profession: the ability to recover lost or damaged data through the backup and restore process. I’ve always stated that a successful backup is irrelevant and I adhere to that steadfastly still. But the reason I say that is that the only thing that matters in backup and recovery is the latter: a successful recovery in the event of loss or corruption of data. That being said though one doesn’t work without the other. The act of backing up data and subsequently restoring your backups in a process that yields continuity of your data is a yin-yang of information technology. Successful restores require solid backup strategies.

Successful backup strategies in Microsoft SQL Server require an understanding of the fundamentals of what types of backups are possible, the understanding of recovery models for databases, a basic knowledge of the use and structure of the transaction log in SQL Server as it pertains to logging and recovering transactions, and syntax. We will cover each of those here in various depths in this first article. The second in this series published later this week will cover the recovery / restore side of this symbiotic relationship.

Types of Backups

There are three basic types of backups in Microsoft SQL Server:

Full Backups

Differential Backups

Transaction Log Backups

Additionally it’s possible to backup files and filegroups in Microsoft SQL Server but those are advanced topics that will not be covered in this series aimed at the new Database Administrator.

Full Backups

A Full backup is essentially a file copy of the .mdf and any .ndf files: the data file(s) for a SQL Server database. The term “Full” can be construed as a complete copy of the database and that is incorrect. These data files only store the data that has been permanently written to the database. This doesn’t include all transactions necessarily as the transaction log is used for making a record on transactions as their being committed and eventually persisted through a write process to the data file(s). While the Full backup primarily stores copies of all the data files there is a portion of the transaction log (the .ldf file) that is included in a full backup. This portion of the transaction log allows for restoring transactions that are committed to the data files during the backup process and for noting the transactions not yet committed that are “in-flight” when the backup is being taken. Depending upon the type of restore and the type of recovery model for the database (both topics discussed later in this series and in this article respectively) those “in-flight” transactions will be either rolled back and not included in a restore or they’ll be accounted for in a subsequent recovery step through an additional differential or transaction log restore later during recovery.

It should be noted that just because you take a Full backup of your database you may not be able to recover your database to a specific point in time since a Full backup by itself can only be restored to the time the backup was taken. In order to restore to a specific point in time you’ll need to use a variety of backups: Full, (possibly Differential), and Transaction Log backups against a database in a compatible Recovery Model (covered in the next section of this article).

Differential Backups

Differential backups are similar to Full backups in that they’re representative of the data pages (and with enough transaction log information for the roll-forward/roll-back of committed and pending transactions taking place during the differential backup process). However the scope of the data pages that are backed up in a Differential backup process are only those pages that have changed since the last Full backup. Furthermore, each subsequent Differential backup taken after a Full backup will include all of the pages already included in any Differential backup plus those pages changed since the last Differential backup. This means that with regards to Differential backups:

Each Differential backup will continue to grow in size (so long as there are transactions changing data values or structure in the database) until the next Full backup is taken.

When a recovery process is initiated you may find yourself not needing to use all Differential backups taken against a database depending upon what time to which you want to recover your data.

A differential backup is no good without a previous Full backup and a Full backup must have previously been taken for the database before you’re even allowed to perform a Differential backup. An error will be raised if you attempt to take a Differential backup when no Full backup exists in the backup chain (think “roadmap for restoration” or “metadata history of backup actions” when you hear the phrase Backup Chain ) for the database. This is inherent in the definition of a Differential backup as already explained: a copy of all changed data pages since the last Full backup .

Transaction Log Backups

Unlike the other two backup types Transaction Log (or simply “Log” backups) don’t take into consideration the data pages / data files for the database. These backups only cover the transaction log files themselves and specifically the transactions documented since the last Transaction Log backup was taken. Like Differential backups a Transaction Log backup can only be taken if two conditions are met:

A Full backup exists in the database’s backup chain.

The database is in a recovery model that allows for logging of transactions (see next section.)

When it comes to the ability to restore a database to a specific point in time you can only do so if you’re taking transaction log backups. Even then, as you’ll see, there are some exceptions to that rule. Depending on the amount of logged transactions, the frequency at which you take Transaction Log backups, and the structure/configuration of your transaction log file the individual transaction log backups can be quite large.

I’ve referred to recovery models and transaction logging a few times now. Let’s spend a bit of time looking at what I mean by recovery model and how the recovery model for a database affects what sort of backup can be taken as well as your options for restoring backups.

SQL Server Database Recovery Models

Recovery model refers to the method in which SQL Server logs transactions to the database and what sort of transactions are logged to the transaction log for the sake of a potential recovery situation. There are three recovery models in Microsoft SQL Server:

Full

Simple

Bulk-Logged

Full Recovery Model A database running under Full recover