Developing a Backup and Restore Plan
Developing a solid backup
and restore plan for SQL Server is one of the most critical tasks an
administrator performs. Simply put, if you are a database administrator
(DBA) and have a significant loss of data in a database you are
responsible for, your job may be on the line. You need to carefully
examine the backup needs of your organization, document those needs, and
deliver a plan that defines how your backup and restore plan will meet
those needs.
The best place to start in
identifying the backup requirements is to ask the right questions. The
following questions can help drive out the answers you need:
How much data loss is
acceptable? For example, if you choose to do only full database backups
each night, would it be acceptable to lose all the data added to the
database during the next day? This could happen if you had a failure and
had to restore to the last full backup.
What
is the nature of the database? For example, is the database used for a
data warehouse, or is it used for a high-volume transaction processing
system?
How often
does the data in the database change? Some databases may change very
little or not at all during the day but sustain heavy batch updates
during the evening.
What
is the acceptable recovery time in the event a database must be
restored from previous backups? This question is directly related to the
amount of downtime acceptable for the applications using the database.
Is
there a maintenance window for the application/database? The
maintenance window is typically a period of time when the database or
server can be taken offline. What are the exact times of the maintenance
windows?
What is the size of the database(s) you need to back up?
What media is available for backup, and where is the media located?
What
is the budget for database backup and recovery? If no budget has been
established, the answers to some of the preceding questions drive the
cost of the solution.
Some of the questions that need
to be asked to come up with a good backup and restore plan may raise
some eyebrows. For example, you may find that the answer you get for the
question “How much data loss is acceptable?” is “None!” Don’t panic.
There are sensible responses for these types of answers. The reality is
that you can deliver a solution that virtually eliminates the
possibility of data loss—but that comes at a cost. The cost may come in
the form of real dollars as well as other costs, such as performance or
disk space. As with many other technical solutions, you need to consider
trade-offs to come up with the right plan.
Note
Many of the questions
that relate to database backup and restore are related to system backups
as well. System-wide backups, which happen independently of SQL Server
backups, capture all or most of the files on a server and write them to
appropriate media. These server backups are often performed by DBAs,
system administrators, and the like. You should consider having the
person or persons responsible for the system backups present when asking
the database backup and restore questions. This will help with the
coordination and timing of the backups.
When you have the answers
to these questions, you need to document them, along with your
recommended solution. You should identify any assumptions and make sure
to outline any portion of the plan that has not met the requirements.
The
good news is that the implementation of the plan is often less difficult
than coming up with the plan itself. Microsoft provides a myriad of
tools to create database backups that can meet the needs of your
organization.
Types of Backups
SQL Server offers several
different types of backups you can use to restore a database to a former
state. Each of these backups uses a file or set of files to capture the
database state. The files are found outside the SQL Server database and
can be stored on media such as tape or hard disk.
As described in the following sections, these backup types are available with SQL Server 2008:
Full Database Backups
A
full database backup is an all-inclusive backup that captures an entire
database in one operation. This full backup can be used to restore a
database to the state it was in when the database backup completed. The
backup is transactionally consistent, contains the entire database
structure, and contains the related data stored in these structures.
As with many other backups,
SQL Server allows for updates to the database while a full backup is
running. It keeps track of the changes occurring during the backup by
capturing a portion of the transaction log in the database backup. The
backup also records the log sequence number (LSN) when the database
backup is started, as well as the LSN when the database backup
completes. The LSN is a unique sequential number you can use to
determine the order in which updates occur in the database. The LSNs
recorded in the backup are used in the restore process to recover the
database to a point in time that has transactional consistency.
A full database backup is
often used in conjunction with other backup types; it establishes a base
for these other types if a restore operation is needed. The other
backup types are discussed in the following sections, but it is
important not to forget about the full backup that must be restored
first in order to utilize other backup types. For example, let’s say you
are making hourly transaction log backups. If the database is to be
recovered using those transaction log backups, the last full database
backup must be restored first, and then the subsequent log backups can
be applied.
Differential Database Backups
Differential database
backups capture changes to any data extent that happened since the last
full database backup. The last full database backup is referred to as
the differential base
and is required to make the differential backup useful. Each data
extent that is monitored consists of eight physically contiguous data
pages. As changes are made to the pages in an extent, a flag is set to
indicate that a change has been made to the extent. When the
differential database backup is executed, only those extents that have
had pages modified are written to the backup.
Differential database backups
can save backup space and improve the overall speed of recovery. The
savings in space and time are directly related to the amount of change
that occurs in the database. The amount of change in the database
depends on the amount of time between differential backups. When the
number of database changes since the last backup is relatively small,
you achieve the best results. If, however, a significant number of
changes occur to the data between differential backups, the value of
this type of backup is diminished.
Ultimately the number of
data pages that are affected by the changes determine the number of
pages that must be included in the differencial backup. The number of
pages is affected by the indexing structure as well as the nature of the
updates. If for example, there
are many rows that are changed but those rows are all clustered on a
limited number of data pages then the differencial backup will not be
that large.
Partial Backups
Partial backups provide
a means for eliminating read-only data from a backup. In some
implementations, a portion of the data in a database may not change and
is strictly used for inquiry. If this data is placed on a read-only
filegroup, you can use partial backups to back up everything except the
read-only data. This technique reduces the size of your backup and
reduces the time it takes to complete the backup. The read-only
filegroups should still be backed up, but this needs to occur only after
the read-only data is loaded.
Differential Partial Backups
Differential partial backups
work like differential database backups but are focused on the same type
of data as partial backups. The extents that have changed in filegroups
that are not read-only are captured in this type of backup. This
includes the primary filegroup and any read/write filegroups defined at
the time of the backup. Like differential database backups, these
backups also require a differential base, but it must be a single
differential base. In other words, multiple base backups that have been
taken at different times for different database files will not work. You
must use a single base backup that encompasses all of the database
files.
File and Filegroup Backups
File and filegroup backups
are targeted at databases that contain more than one filegroup. In these
situations, the filegroup or files in the filegroups can be backed up
independently. If a filegroup is backed up, all the files defined in the
filegroup are backed up.
File and filegroup backups
are often used for larger databases where the creation time for a full
database backup takes too long or the resulting backup is too large. In
these situations, you can stagger the backups of the files or filegroups
and write them to different locations.
The main disadvantage of this
type of backup is the increase in administrative overhead. Each of the
files in the database must be backed up, and a complete set of these
files must be retained to restore the database. For a full recovery
model, the transaction log backups must also be retained.
Note
SQL Server 2008 supports
file and filegroup backups for all recovery models, including simple
recovery. The catch with simple recovery is that the files and
filegroups are limited to read-only secondary filegroups. SQL Server
2000 did not allow these types of backups with simple recovery.
Copy-Only Backups
Copy-only
backups allow a backup of any type to be taken without affecting any
other backups. Normally, a database backup is recorded in the database
itself and is identified as part of a chain that can be used for
restore. For example, if a full database backup is taken, any subsequent
differential database backups use this full database backup as their
base. A restore process utilizing the differential database backups
would have a reference to the full database backup, and that backup
would have to be available.
Copy-only backups do not
affect the restore chain. They are useful in situations in which you
simply want to get a copy of the database for testing purposes or things
of this nature. Microsoft has made it easier to make this kind of
backup by adding the Copy Only Backup check box when performing a backup
using SQL Server Management Studio (SSMS). In SQL Server 2005, the Copy
Only Backup had to be performed via the Transact-SQL (T-SQL) BACKUP command.
Transaction Log Backups
Transaction log backups
capture records written to the transaction log file(s) defined for a
database. The full and bulk-logged recovery models are the only models
that support transaction log backups. These models cause transaction
events to be retained in the transaction log so that they can be backed
up. Simple recovery mode causes the transaction log to be truncated
periodically and thus invalidates the usefulness of the transaction log
backups.
