SQL Server 2008 includes a rich array of
options that can be employed as parts of a customized backup and
recovery strategy. In this section, we'll consider three such options: checksums, backup mirroring, and transaction log marks.
But before we cover these options, let's have a look at an important
part of any backup strategy: the backup location and retention policy.
1. Backup location and retention policy
A
key component of a well-designed backup strategy is the location of the
backups: disk or tape (or both). Let's consider each of these in turn
before looking at a commonly used backup retention policy.
Tape
Historically,
organizations have chosen tape media as a backup destination in order
to reduce the cost of online storage while retaining backups for long
periods of time. However, a tape-only approach to backups presents a number of challenges:
Tape systems typically have a higher failure rate when compared to disk.
Typically,
tapes are rotated offsite after a predefined period, sometimes as soon
as the morning after the backup. Should the backup be required for
restore, there may be a time delay involved in retrieving the tape for
restore.
Depending on the tape system,
it may be difficult/cumbersome to restore a tape backup to a different
server for restoration verification, or to use it as a source for DBCC
checks or other purposes.
In addressing these concerns, disk backups are frequently used, although they too have some challenges to overcome.
Disk
Due
to some of the limitations with the tape-only approach, backup
verification, whereby backups are restored on a regular basis to ensure
their validity, are often skipped. As a result, problems are often
discovered for the first time when a real restore is required.
In contrast to tape, disk-based backups offer the following advantages:
When required for a restore, they are immediately available.
Disk media is typically more reliable than tape, particularly when RAID protected.
Disk-based
backups can be easily copied to other servers when required, making the
verification process much simpler compared with a typical tape-based
system.
Despite its advantages,
a disk-based backup approach has some drawbacks. The main one is the
extra disk space (and associated cost) required for the backup files.
Further, the cost advantage of tape is fully realized when considering
the need to store a history of backups—for example, daily backups for
the last 30 days, monthly backups for the past 12 months, and yearly
backups for the last 7 years. Storing all of these backups on disk is
usually more expensive compared to a tape-based system, not to mention
the risk of losing all of the disk backups in an environmental disaster.
With
the introduction of third-party backup compression tools and the
inclusion of backup compression as a standard feature of SQL Server
2008 (Enterprise edition), the cost of disk storage for backups is
significantly reduced, but the overall cost is still typically higher
than a tape-based system.
In addressing the negative aspects of both tape and disk, a common approach is to combine both methods in what's known as a disk then tape approach.
Disk then tape
As shown in figure 1, the ideal backup solution is to combine both disk and tape backups in the following manner:
Database backups are performed to disk.
Later
in the day/night, the disk backup files are archived to tape in the
same manner as other files would be backed up (documents, images and so
forth).
Typical
restore scenarios use the most recent backup files on disk. After a
number of days, the oldest disk-based backup files are removed in order
to maintain a sliding window; for example, the past 5 days of backups
are stored on disk.
If older backups are required, they can be sourced from tape.
The advantages of such a system are numerous:
Backups are stored in two locations (disk and tape), thus providing an additional safety net against media failure.
The
most common restore scenario, typically that of the previous night's
backup, is available on disk for fast restore without requiring tapes
to be requested from offsite.
A full history of backups is available for restore from tape.
The
cost of the overall system is reduced, while still providing all of the
advantages of disk-based backups for the most common restore scenarios.
A variation on this approach is using SAN-based backup solutions.Most of the enterprise-class SANs available today provide
several methods of snapping, or cloning,
LUNs in order to provide near instant backup/restore solutions. Once
snapped, the cloned LUN can be archived to tape, thereby providing
long-term storage like the disk then tape approach. If using these
backup types, take care to ensure the backup method used is SQL Server
compatible and enables transaction log roll forwards for point-in-time
recovery.
Regardless
of the backup destination, an important consideration is how long to
retain the backups before deleting or overwriting them.
Backup retention
Assuming
the disk then tape backup method is used, the retention period for each
location needs to be considered separately. For the disk backups, the
retention period is dependent on the backup model. For example, if a
weekly full, nightly differential system is in place, then the weekly
backup would need to be retained on disk for the whole week for use
with the previous night's differential backup. If disk space allows,
then additional backups can be retained on disk as appropriate.
In
considering the tape rotation policy (how long to keep a tape before
overwriting it), the classic rotation policy typically used is the grandfather-father-son (GFS) system, whereby 22 tapes are used per year.
The GFS tape rotation policy, as shown in table 1,
uses 6 sons, 3 fathers, and 13 grandfathers (52 weeks per year divided
by 4-week periods) for a total of 22 tapes per year. Optionally, one of
the grandfather tapes can be retained as a yearly backup tape for a
period of years.
Table 1. Grandfather-father-son tape rotation policy
| Week | Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|
| 1 | Son1 | Son2 | Son3 | Son4 | Son5 | Son6 | Father1 |
| 2 | Son1 | Son2 | Son3 | Son4 | Son5 | Son6 | Father2 |
| 3 | Son1 | Son2 | Son3 | Son4 | Son5 | Son6 | Father3 |
| 4 | Son1 | Son2 | Son3 | Son4 | Son5 | Son6 | Grandfather-x |
Regardless
of the disk location and retention period, ensuring backups are valid
is an important consideration. Short of actually restoring each backup,
one of the options available for detecting media failure is to use backup checksums.
