1. Full Backups
The concept of backing up data is one of those things that should be extremely intuitive, but is often implemented poorly, if at all. I know quite a few database administrators (DBAs) that dont worry about regular, structured backups because their database server is on a SAN (storage area network) and the data is therefore backed up regularly. To me, this makes no sense at all, since there is absolutely no contingency for point-in-time restoration of data, outside of what happened to have been backed up as part of a complete Windows backup solution. If there were a catastrophic failure, and the DBA had to rebuild the database to the point of failure, it could not be easily done. The reason is because the entire Windows image would have to be rebuilt from the last Windows backup, which means that the database will only be current to that particular point of time, and not the desired point of time. For example, if the Windows image is run nightly, but the database backups are run hourly, then you will have a perfect set of hourly backups up to the point where the Windows backup is run. If Windows fails at 11:59 pm , then that entire days worth of database backups has been lost. The rule of thumb, generally, is to put backup files on a separate drive than the OS. This alleviates the issue outlined in the preceding, as long as the backup drive is not corrupted.
In the realm of database administration, I think it is best to imagine that your database server is a stand-alone system. This means to imagine that there is no SAN, no Windows backup solution, nothing like that at all. You must be able to manage the entire universe of your data as it pertains to your server. What does this entail, exactly? Thats what this book will address; how to back up and restore your most important assetthe data you are responsible for.
Note
We will also briefly cover data storage techniques in this book, although that will not be a main focus. This is because, although we will highlight specific techniques for storage, it is ultimately your decision whether or not to implement storage techniques outside of what is available from your local file system.
What Is a Full Backup?
A full backup is the entirety of the data within a database from the point in time that the backup was run. Part of the transaction log is also backed up in a full backup; this is done so a successful restore can eventually be run using the backed-up data. A backup can be saved to local disk, an available network share, or even in Windows Azure blob storage (if youre running SQL Server 2012 or later). The full backup type provides the starting point for a full restore, and also the starting point for a differential restore (covered in Chapter ). In other words, without a full backup, neither a differential nor a transaction log backup can be successfully restored.
In my first book, Practical Maintenance Plans in SQL Server (available from Apress), I briefly discussed the concept of backups in Chapter , titled Backing Up a Database. In that chapter, I went over recovery models and backup types, and then explained how to set up the maintenance task to perform these jobs automatically . For the purpose of this book, I dont think we need to go over the job creation part, but we will go over recovery models and backup types.
Recovery Models
A recovery model is how SQL Server is told to recover data. Figure shows where to look to find the recovery model configuration area. This is found by right-clicking an existing database and choosing Properties, then selecting Options from the left menu. In the example shown, I have chosen to create a new database, so the screen you see in the figure is the New Database screen.
Figure 1-1
Recovery models location in New Database screen
I am going to name this database backrecTestDB, and this is the database that we will be using throughout this book. Obviously, you will have your own databases that you will maintain separately, but this is what we will use as a reference.
Notice that we are on the General tab, as shown in the left pane of the preceding figure. Click Options, and you should see what is shown in Figure .
The initial interface for the Options area is now visible.
Note
Recall that I am using SQL Server Management Studio (SSMS), which is available as a separate download from Microsoft, to administer my SQL Server 2016 instance.
At the very top of this screen, the second option down is for recovery model. You have three options for recovery models . Those options are as follows:
Full: This option lets the database recover to nearly any point in time, and is the clear choice of many DBAs.
Bulk-logged: Similar to full recovery, but this scenario allows for logging to be minimized for bulk operations (copying, specifically).
Simple: This is the choice for smaller, nonmission-critical databases. It does not allow for point-in-time restores like full, or bulk operations like bulk-logged. It simply allows for recovery using the last backup.
We are going to keep the full option selected here, because we want to be able to look at point-in-time restores later on in this book.
Backup Types
SQL Server has three unique backup types, which are discussed in later chapters. They each perform differently, and they can either work together or separately to provide a backup solution for your data. The backup types that are available to you are also entirely dependent upon the recovery model used for your database. We will get more into this shortly. For now, lets take a look at Listing , which outlines the different backup types.
Listing 1-1. Backup Types
There are a few things to note about these different yet similar backup types.
First, a full backup is different from a transaction log backup, in that the full backup type has the entirety of the actual data within the database, while the transaction log backup only has the individual transactions through time that affected the data contained within the database.
Second, a differential backup is useless without the last full backup. The differential backup is applied to the full backup, which creates the point-in-time restore for that particular differential backup set. One important thing to remember about differential backups is that they do not contain the transaction log, so any data beyond the differential backup will not be restored without restoring the transaction log backups.