Backing Up and Restoring in SQL Server
This article is excerpted from Essential SQL Server 2000: An Administration Handbook (Addison Wesley, 2001, ISBN: 0201742039).
This chapter is from the book
This chapter is from the book
This chapter is from the book
In its simplest form, the database backup and restore procedure for SQL Server 2000 is incredibly easy. One command or just a few clicks in Enterprise Manager performs a backup or restores one. You can make these backups to disk, network shares, or tape.
If you need a test database to play with, you can easily get one by backing up the current database and restoring it with another name. You don't have to create a set of special files first, or make any other changes to your database server to do this. As a matter of fact, the users don't even have to be out of the database while you're backing it up, although that's usually a good idea anyway. Both the backup and the user activity will be slightly slower during backup.
Once the database is backed up, it's an equally simple matter to restore it, even to another server. Of course, during a restore, the users cannot access the database.
Backups can be taken graphically or with the command line tools, and they can also be scheduled.
The backup and restore process really isn't that difficult, and they are usually quite fast. Even so, large databases, in the multi-gigabyte range, can take more than a few hours to complete. You might wonder what data is stored in the backup file if the backup starts at midnight but it doesn't complete the backup until one in the morning, and people are still entering data in the database. The answer is the last piece of data that makes it into the database at one in the morning.
Backing Up Databases
Even though backing up a simple database is easy, rarely are things in their simplest form.
One of the primary variables that will affect your backup is the size of the database. Obviously, a bigger database means a longer, larger backup. If a database is quite large, it may not fit on a single tape or one drive location. This lengthier backup may also take more time than available to complete the backup.
To deal with these issues, SQL Server 2000 provides the ability to stripe backups across multiple tapes or disk devices, so that several devices can be combined to deal with the size and time factors.
You can also structure your backups so that only the changes since the last backup are included, which helps you deal with the size and time elements.
Recovery Models
The next factor that will affect your backups is the recovery model.
In most cases, when data is written to a SQL Server 2000, it is written not to the database, but to a separate file called the log.
This log file contains all the individual data transactions, and a logging process writes those changes to the database. The committed data items are then marked to indicate they made it into the database, a process called a checkpoint. The recovery model determines what happens next.
If the database has been set to the Simple recovery model, the marked data is erased from the log file after the change is written successfully to the database. In that way, the log shrinks and expands automatically, if the database option auto shrink is on.
If the Bulk-Logged model is selected for the database, then changes are not erased after they make it to the database until you back up the database or log. Certain bulk-load operations are not completely logged, so all data may not make it to the log backups. Recovery can as recent as the last log backup.
If the Full model is selected for the database, then the changes are not erased after they make it to the database, and are only erased when you back up the database or log.
In this model, all operations are logged, so all data makes it to the log backups. This slows the process of bulk-logged operations, but is safer. Recovery can as recent as the last log backup or to a specific point in time.
Full Backups
As an example, imagine a database set to the Simple recovery model. You perform a full backup at midnight when no one is using the database, and people start to enter data again at 7:00 in the morning.
At 11:01, your server catches on fire, and after it is replaced, the backup you restore brings you to a current state as of midnight the night before.
Log Backups
Next, imagine the database is set to use the Full recovery model. You make that same midnight backup, and then every two hours, starting at 7:00, you make a separate backup of the log.
A fire breaks out again at exactly 11:01. This time, however, you restore that midnight backup, making you current as of midnight.
Next you apply the 7:00, 9:00, and then the 11:00 log backups in that order.
You've now lost only one minute's work.
Large Backups
The recovery model not only affects what level of recovery you can achieve, but also the time it takes to create your backup.
With the database set to Simple recovery, you must perform a full backup of the database with exceptions, which may take a while if the database is huge, in the multi-gigabyte range.
With the database set to the Full or Bulk-Logged model, you would perform that lengthy full backup only periodically, and you perform periodic log backups that take very little time because they contain only the changes.
To restore the database to a good state, you would restore the full backup and then each log backup in order, starting from the earliest log backup.
The other side of that coin is that it takes a bit longer to restore under the latter model because you have to do all the log restores in order.
Differential Backups
I mentioned an exception earlier. The exception involves something called a differential backup. This is sort of like an extended log backup (except in the Simple model), in that it backs up just the changes, but it's all the changes since the last full backup. This type of backup can be used with any of the recovery models.
Let's return to the combustible server example to illustrate. In the Simple recovery model, you back up the database at midnight, as before. This time, however, you take a differential backup at 10:00, intending to do so every four hours thereafter.
The server is again well engulfed in flames by 11:01, but this time, you are safe as of 10:00. What you have to do at this point is to restore the full backup of midnight and then the differential one from 10:00.
In the Full and Bulk-Logged models, assuming a large database, the strategy is that a full backup is taken on the weekend, which gets all data.
Logs are backed up every two hours as usual, but because the database is so large, you would have to apply the full restore, and then far too many log backups to be comfortable.
The answer to this dilemma is to perform a differential backup each night, which gets all the changes since the last full backup. You now don't need the log backups between the time you took the full and differential backups, since the differential backup is a kind of combined log backup. This strategy allows you to restore the full backup, the differential backup, and then only the log backups since the differential backup. The restore time in this model takes a lot less time. The tradeoff here is that the differential backups can become quite large.
Backup Locations
Assuming that you've installed the required tape hardware and drivers on your NT or Windows 2000 system, you can send your backups there.
The first tape drive is referred to as \\.\TAPE0, replacing the 0 with the next number (1,2,3, etc.) for the other tape drives you have on your system. The tape drives must be physically located on the server to do this, so you can't use remote tape drives with SQL Server 2000's native backup commands.
SQL Server 2000 backups can exist on the same tape as a Windows NT backup made with the NTBACKUP command, but you'll want to put the SQL backup on first, and set the backup switch that doesn't rewind the tape. Personally, I don't use this feature; always feeling a bit insecure about how much room will be left on the tape for either backup.
The other option is to send the backup directly to disk, specifying the path and filename directly. Your NT backup program can back up these files since they aren't in use. In this model you'll want to carefully monitor your drive space, and a good compression utility can bring the size of the .BAK file to less than 25 percent of its original size.
Backup Devices
Not only can you send the backup file directly to tape or hard drive paths, but you can also specify a friendlier name by creating a logical device.
Recovery Process
You can recover a database using Enterprise Manager or Query Analyzer. The types of commands involve the recovery model of the database.
If the recovery is set to the Simple model, the recover process involves restoring the last full backup, leaving the database in a usable mode. This effectively closes the database and allows connections from users.
If the recovery model is set to Full or Bulk-Logged, the recovery involves restoring the last full backup, and leaving the database non-operational but able to restore log backups. To complete the backup, you restore the logs, in order, from earliest to last. At the last log restore, you leave the database operational.