Frequency of Backups
How often you back up your databases depends on many factors, including the following:
The size of your databases and your backup window (that is, the time allocated to complete the task of backing up the database)
The frequency of changes to the data and method by which it is changed
The acceptable amount of data loss in the event of a failure
The acceptable recovery time in the event of a failure
First, you must establish
what your backup window will be. Because SQL Server allows dynamic
backups, users can still access the database during backups; however,
this affects performance. This means you should still schedule backups
for low-activity periods and have them complete in the shortest possible
time.
After you establish your
backup window, you can determine your backup method and schedule. For
example, if it takes 4 hours for a full backup to complete, and the
database is quiescent between midnight and 6:00 a.m., you have time to
perform a full backup each night. On the other hand, if a full backup
takes 10 hours, and you have a 2-hour window, you should consider
monthly or weekly backups, perhaps in conjunction with filegroup,
differential, and transaction log backups. In many decision-support
databases populated with periodic data loads, it might suffice to back
up once after each data load.
Backup frequency is also
directly tied to acceptable data loss. In the event of catastrophic
failure, such as a fire in the server room, you can recover data only up
to the point of the last backup moved offsite. If it is acceptable to
lose a day’s worth of data entry, nightly backups might suffice. If your
acceptable loss is an hour’s worth of data, hourly transaction log
backups would have to be added to the schedule.
Your backup frequency
affects your recovery time. In some environments, a weekly full backup
plus transaction log backups taken every 10 minutes provide an
acceptable data loss factor. A failure a few days after backup would
require a full database restore and the application of hundreds of
transaction logs. Adding a daily differential backup in this case would
vastly improve restore time. The full and differential backups would be
restored, and then six logs would be applied for each hour between the
differential backup and the time of failure.
Using a Standby Server
If the ability to quickly
recover from failure is crucial to your operation, you might consider
implementing a standby server. Implementing a standby server involves
backing up the production server and then restoring it to the standby
server, leaving it in recovery mode. As transaction logs are backed up
on the production server, they are applied to the standby server. If a
failure occurs on the production server, the standby server can be
recovered and used in place of the production server. If the production
server is still running, you should not forget to back up the current
log with the NO_TRUNCATE option and restore it to the standby server as well before bringing it online.
Note
Another advantage of
restoring backups to a standby server is that it immediately validates
your backups so you can be assured of whether they are valid. There is
nothing worse than finding out during a recovery process that one of the
backup files is damaged or missing.
The STANDBY =undo_file_name
option plays a key role in the application of transaction logs to the
standby server. When the database and subsequent log backups are
restored to the standby server with this option, the database is left in
recovery mode but is available as a read-only database. Now that the
standby database is available for queries, it can actually reduce load
on the production database by acting as a decision support system (DSS).
Database Consistency Checks (DBCC) can be run on it as well, further
reducing the load on the production system.
For the database to be
available for reads, the data must be in a consistent state. This means
that all uncommitted transactions must be rolled back. This rollback is
usually handled by the RECOVERY
option during a restore. In the case of a standby server, this would
cause a problem because you would intend to apply more logs, which
could, in fact, commit those transactions. This situation is handled by
the undo_file_name clause of the STANDBY
option. The file specified here holds a copy of all uncommitted
transactions rolled back to bring the standby server to a consistent,
read-only state. If those transactions subsequently commit a log
restore, this undo information can be used to complete the transaction.
The application of hundreds
or thousands of transaction logs to the standby server can be
challenging. Fortunately, SQL Server 2008 includes log shipping, which
automates the transfer of logs to the standby server. Log shipping,
which can be configured in SSMS, uses SQL Server Agent jobs on the
primary server to back up the transaction log and copy it to a folder on
the standby server. SQL Server Agent on the standby server then
executes a load job to restore the log. Automating your standby server
with log shipping reduces administration and helps to ensure that the
standby database is up-to-date.
Snapshot Backups
Snapshot backups
are developed in conjunction with independent hardware and software
vendors. These backups are not related to SQL Server database snapshots
and are not accessible from any of the SQL Server tools. They utilize
backup and restore technology and can provide relatively fast backup and
restore operations. Snapshot backups are typically utilized on very
large databases that are unable to perform database backups and restores
in a timely fashion using SQL Server’s conventional backup and restore
resources.
Considerations for Very Large Databases
When it comes to backup and
recovery, special consideration must be given to very large databases,
which are known as VLDBs. A VLDB has the following special requirements:
Storage— Size might dictate the use of tape backups over the network or a disk.
Time— As your time to backup increases, the frequency of backups might have to be adjusted.
Method— How you back up your database is affected by its size. Differential or file and filegroup backups might have to be implemented.
Recovery— Partial
database recovery, such as restoring a file or filegroup, might be
required due to the prohibitive time required to restore the entire
database.
When designing a VLDB, you
must integrate your backup plan with storage, performance, and
availability requirements. Larger databases take longer to back up
because the backup sizes are larger, and restores on this type of
database can take much longer to complete than with a smaller database.
Maintenance Plans
SQL Server includes
maintenance plans that provide database maintenance tasks, including
optimization, integrity checks, and backups. The backup options
available in the maintenance plans are comprehensive and include the
capability to regularly schedule full, differential, and transaction log
backups. This type of automation is essential to ensure that your
backups are taken with a reliable tool at regular intervals.
You can create maintenance plans from within SSMS. If you open the Management node in the Object Explorer, you see a node named Maintenance Plans.
If you right-click this node, you can select New Maintenance Plan to
create a plan from scratch, or you can select Maintenance Plan Wizard to
have a wizard guide you through the creation of a new maintenance plan.
The following options that relate to backups are available as part of a
maintenance plan:
Using these tasks in a maintenance plan is a great start to a solid backup and recovery plan.
