Best Practices for

Backup and Restore

in SQL™ Server 2005
By Javier Loria

Edited with permission from SQL Server Magazine.

Copyright © 2008 Penton Media, Inc.
All rights reserved.

Third-party information brought to you courtesy of Dell.

THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECH-
NICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND.
 Best Practices for
Backup and Restore
➔ Contents in SQL Server 2005
Introduction................................................... 1
Audience: Who should read this.............. 1
Introduction to the Data Recovery Plan......... 2
Threat Analysis (What can happen, and
what you can afford to lose).......................... 2
Source...................................................... 2
Business Requirements............................. 2
Operational Requirements....................... 2
Introduction
Backup Objectives................................... 3 In an ideal world, hard drives and other hardware never fail, software
Backup Strategies (What you are is never defective, users do not make mistakes, and hackers are never
willing to pay)............................................... 3
Backup Types................................................ 3 successful. However, we live in a less than perfect world and we should
Full Backup.............................................. 3 plan and prepare to handle adverse events.
Differential Backup.................................. 4
Log Backup.............................................. 4
Backup Targets............................................... 4 In our database environment, that plan is called the Data Recovery
Database Backup..................................... 4 Plan (DRP). The DRP is the set of actions that database administrators
File Backup.............................................. 5 (DBAs) take to handle adverse events that may affect the availability of
Filegroup Backup..................................... 5
Partial Backup.......................................... 5 their database environments. Microsoft SQL Server 2005 has a variety of
Backup Strategies.......................................... 5 different technologies that can help DBAs build a DRP. These technolo-
Full Backup—Simple Mode..................... 5 gies include: Failover Cluster, Database Mirroring, Database Replication
Log & Full Backup................................... 6
Full & Log Backup................................... 6 and Log Shipping. In spite of the advantages these technologies might
Full – Differential – Log........................... 6 offer, DBAs should always plan backups and restores as the last line of
Full – File/Filegroup – Log Backup........... 7 defense of the DRP.
Service Level Agreement............................... 7
Operational Best Practices............................. 8
Performance............................................. 8 In this whitepaper, we will discuss some of the best practices in Backup
Security.................................................... 8 and Restore operations when using SQL Server 2005. In this whitepaper,
Other Best Practices.................................... 10
Summary of Backup Best Practices.............. 11 we will cover:
• What types of Backup and Restore options SQL Server offers
• How to combine Backup and Restore types in a DRP
• Best practices you should follow in your backup and restore strategy

Audience: Who should read this

This whitepaper is intended for DBAs involved in the design, plan
and execution of the backup and restore operations in the Microsoft
SQL Server 2005 platform. This paper assumes some knowledge of
SQL Server commands and a basic foundation in administering the
Microsoft® Windows® platform.
1 BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 courtesy of Dell
Introduction to the Data Recovery Plan ° A non-user (hacker) may gain access to your
database server and delete or destroy data or
The first best practice for Backups and Restores in SQL database objects.
Server 2005 is to have a DRP. DRPs are like insurance • Environment: The last source of events, which too
plans for your database. When you buy an insurance often database administrators forget, is environment
policy, you have to consider two main factors: how much vulnerabilities. Your database DRP should also consider:
can I afford to lose in case of an adverse event; and how ° Fire and Flood in the data center.
much am I willing to pay to protect from it, even when ° Earthquake, Tornado.
nothing wrong happens. How much you can afford to ° Theft and Civil disorder.
lose is the Threat Analysis. You should begin designing
your plan with a threat analysis. How much you are will- Make sure your plan handles threats from all sources:
ing to pay is the backup and restore strategy. Obviously Hardware, Software, People and Environment.
these two components are tightly related and influence
each other. Business Requirements
After considering all the possible events that may
affect your database, it is time to analyze the Business
Threat Analysis (What can happen, and Requirements. Some of the elements you should consider:
what you can afford to lose) 1) Value: The first question you should answer when
Following the insurance paradigm, the first factor to con- designing your plan, is how much is your data worth?
How much money the company will lose if you lose
sider in your DRP is what coverage your insurance policy
one day of transactions? How much money if you lose
must have. You should plan and design a strategy accord- one hour of information? Answers to these questions
ing to the events you want to take preventive actions are important because they also tell you how much you
about. should invest in protecting the database.
2) Volatility: The second element to consider is how
Source volatile is the database? Some databases are read only
The threats that menace your data can be classified and change only sporadically, while others handle
according to the source: Hardware, Software, People and millions of transactions per minute. Volatile databases
Environment. often require frequent backups.
• Hardware: Hardware is always the first source of threats 3) Size: the third element to take into account is the size
to consider in a database environment. Some events you of the database. Obviously, large databases take longer
should consider in your plan: to back up and restore than small databases. Very Large
° Hard drive failure. Databases (VLDB) may take weeks to restore in case of
° Other I/O component failures. a total server collapse.
° CPU, memory and video malfunction. 4) Usage: the final factor to consider is database usage in
° Total server collapse. order to minimize the impact of the backup procedures.
• Software: Some of the software vulnerabilities you For example: if the database is used only 8x5 (eight
should consider: hours, five days a week) you can adopt a backup plan
° Risks related to software upgrades or patches. A to be executed when users are not working. Such a plan
faulty software component may inadvertently delete will take more time to execute but will take less time to
or damage information in the database. restore in the eventuality of a failure. If, however, the
° Software bugs may inadvertently damage data. database is heavily used 24x7 (twenty-four hours, seven
° Malware (Virus, Trojans) may also delete or damage days a week) you may need to adopt a backup plan
data. that have the lowest impact to the system. Such a plan
• People: Some of the people-related vulnerabilities you will take less time to execute but will take more time to
should consider: restore in the eventuality of a failure.
° Users may accidentally delete or incorrectly update
information in your database, even when they do You should consider the value, volatility, size and usage
not have administrative rights. of your database when designing your data recovery
° Database administrators may intentionally or plan.
unintentionally delete or wrongly update data in the
database. For example a delete without a WHERE Operational Requirements
statement. As any other system, the DRP should also take into
° Database administrators may intentionally or account operational requirements. The most relevant
unintentionally drop a database or database objects.
operational requirements of data recovery plans are

2 BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 courtesy of Dell
 security, performance and manageability. Make sure Backup Types
your plan considers these requirements.
The most relevant requirement to consider is security. SQL Server 2005 offers three basic types of backups:
Security is the most sensitive operational requirement Database (Full), Differential, and Log backups.
to contemplate, because backups are more exposed to
physical attacks than the databases they hold. Consider Full Backup
the following examples1: A full backup makes a copy of all used database pages in
1) Someone takes the backup and makes a copy. This is a the database, meaning it copies all the information (Data
confidentiality threat. and indexes) of the database, and excludes all empty data
2) Someone overwrites the content of the backup. This is pages. Full backups also duplicate the part of the transac-
an integrity threat. tion log that includes all open transactions and transac-
3) Someone steals the tapes. This is an availability threat. tions that occurred during the backup process. This allows
the restore process to achieve transactional integrity. The
We will discuss later in this white paper some of the mea- following code is an example of Full Database Backup
sures you may take to reduce these threats. command:

Backup Objectives BACKUP DATABASE AdventureWorks

There are three main objectives of performing backups: TO DISK = N’C:\Backup\AdventureWorks.bak’
1) To recover lost data: This is the most obvious objective
of a backup/restore plan. In case of an event, you will You may also create backups using SQL Server
be able to recover the data that is lost. Management Studio (SSMS). To create a database backup
2) To minimize the data loss: Sometimes it is inevitable to using SSMS (Figure 1), follow these steps:
lose some data. Your plan should also try to minimize 1) Open SSMS
the amount of data that is lost. For example, if you 2) Connect to the SQL Server instance that holds the
back up databases daily, your system may lose up to database.
24 hours of data. You will reduce this number if you 3) Navigate to the Server\Databases folder.
perform other backups during the day.
4) Right click the database you want to backup.
3) To minimize the downtime cost: Another factor to
consider is how difficult and lengthy it will be to restore 5) From the shortcut menu, select Tasks, Backup.
the system, and how to reduce the downtime cost. If 6) In the Database Backup dialog box, select the type of
you need to restore one Full and forty-five transaction backup you want the server to perform, the backup
log backups, the downtime cost is probably higher destination path and the backup options.
than restoring one Full, one differential, and three 7) Select OK to backup the database or press the script
transaction log backups. button if you want to generate a script to generate a
Backup with the selected options.
Backup Strategies (What you are
willing to pay)
After performing the threat analysis, the DBA should cre-
ate a plan for handling backup and restores. To create
such strategy you need to understand the different backup
types and backup options available.

1 This example was authored by the Application Consulting & Engineering (ACE) Team (http://blogs.msdn.com/threatmodeling/). The ACE Team created the
Threat Analysis and Modeling Tool, that can be downloaded from http://msdn2.microsoft.com/en-us/security/aa570413.aspx

courtesy of DELL BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 3
 Figure 1 Backup Database Window in SSMS 2005

Differential Backup Backup Targets

Differential backups are designed to reduce the amount of
Besides the backup type, SQL Server allows four differ-
time it takes to perform full backups. Instead of copying
ent backup targets: Database, Filegroup, File and Partial.
all used pages, the differential backup copies only pages
These targets only apply to the Full and Differential
that have changed since the last full backup. Similar to
Backup types; they do not apply to the log backup.
the Full Backup, differential backups also copy a part of
the transaction log to maintain the transactional integrity
Database Backup
when the backup is restored. The following code is an
A database backup makes a copy of the entire database.
example of how to create a Differential Backup.
If you are using a Full database backup it includes all
BACKUP DATABASE AdventureWorks used database pages in the database; if you are using a
TO DISK = N’C:\Backup\AdventureWorks.bak’ Differential Database backup, it includes all changed
WITH DIFFERENTIAL database pages of the database that have changed since
the last full backup. Some examples of how to perform a
Log Backup Full and Differential Database backup are:
The only type of backup that does not actually copy data-
base pages is the Log backup. The Log backup copies the -- Full Database Backup
transaction log of the database. After it copies the log, the BACKUP DATABASE AdventureWorks
TO DISK = N’C:\Backup\AdventureWorks.bak’
backup truncates the part of the log that is not required -- Differential Database Backup
by active transactions or transactional replication. The BACKUP DATABASE AdventureWorks
syntax to back up the Log is: TO DISK = N’C:\Backup\AdventureWorks.bak’
WITH DIFFERENTIAL
BACKUP LOG AdventureWorks
TO DISK = N’C:\Backup\AdventureWorks.bak’

4 BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 courtesy of Dell
File Backup Partial Backup
File backups do not copy the database; instead the file Partial backup is similar to File and Filegroup backups;
backup aim is to back up only one or more files that are they do not back up the entire database. Partial backups
part the database. always back up the Primary Filegroup and every Read and
Write Filegroup that is part of the database. Besides the
Databases in SQL server 2005 have three different types fact that partial backups simplify the backup statement to
of files: Primary, Secondary, or Log Files. Primary and back up only read and write filegroups, they also offer the
Secondary files hold database pages; in contrast, Log files advantage of allowing this type of backup when using a
hold the transaction log. File backups can make copies of simple recovery model in the database. To perform a par-
pages from Primary and Secondary Files. tial backup, use the Read_Write_Filegroups option of the
Backup command as the following example does:
This type of backup can be used to speed up the restora-
tion process, when the device that stores one of the files -- Full Partial Backup
BACKUP DATABASE AdventureWorks
fails but the rest of the devices are working correctly. In Read_Write_Filegroups
this case, there is no need to restore the full database; TO DISK = N’C:\Backup\AdventureWorks.bak’
only the affected file. The following SQL code performs
Full and Differential File backups: -- Differential Partial Backup
BACKUP DATABASE AdventureWorks
Read_Write_Filegroups
-- Full File Backup
TO DISK = N’C:\Backup\AdventureWorks.bak’
BACKUP DATABASE AdventureWorks
WITH DIFFERENTIAL
FILE=’AdventureWorks_Data’
TO DISK = N’C:\Backup\AdventureWorks.bak’

-- Differential File Backup

Backup Strategies
BACKUP DATABASE AdventureWorks Combine different backup types to create a backup
FILE=’AdventureWorks_Data’ strategy.
TO DISK = N’C:\Backup\AdventureWorks.bak’
WITH DIFFERENTIAL
Full Backup—Simple Mode
One important element to remember when using File When you follow this strategy, the DBA configures the
Backups is that they should either be read only (the file- database recovery model to simple, and performs peri-
group they belong to) or combined with Log Backups to odic Full Database backups. This is the simplest backup
restore transactional integrity of the database. File back- strategy, and the simplest to restore. But it is also the one
ups do not automatically back up the transaction log. that takes the longest to back up and is not feasible in
most scenarios. You can use this strategy in the following
Filegroup Backup cases:
• Development Databases: Databases used in developing
You can group Primary and Secondary files in two differ-
or testing environments, if you can afford to lose
ent types of Filegroups: Primary and Secondary filegroups. daily work, otherwise consider a Full and Log Backup
The main difference between primary and secondary file- strategy.
groups is that the Primary filegroup holds the Primary file, • Stage Databases: Databases used in Data Warehouse to
where system tables are stored. stored intermediate data extracted from source systems.
Similar to File backups, Filegroup backups do not copy • Read Only Databases: Databases that have only read
the entire database; they copy only pages from files that only information, for example subscriber databases that
belong to the filegroup. Some examples of how to per- store information for reporting purposes.
form Filegroup backups are: • System Databases: master, msdb and distribution. Do
not back up tempdb. And unless you plan to change its
-- Full Filegroup Backup contents, do not back up the model database. Backing
BACKUP DATABASE AdventureWorks up Master also backs up the ResourceDB.
FILEGROUP=’PRIMARY’
TO DISK = N’C:\Backup\AdventureWorks.bak’ Because the transaction log is never backed up and it is
-- Differential Filegroup Backup
never truncated; the recovery mode should be changed to
BACKUP DATABASE AdventureWorks simple mode to avoid the continuing growth of the data-
FILEGROUP=’PRIMARY’ base. Use the Full Backup simple mode strategy only on
TO DISK = N’C:\Backup\AdventureWorks.bak’ development, read only, stage or system databases. For
WITH DIFFERENTIAL
example, you can schedule daily backups every night or
every weekend of all system databases.

courtesy of DELL BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 5
 A diagram of Full-Backup and Simple Mode strategy:2 A diagram of a Log & Full backup strategy:

Log & Full Backup Full & Log Backup

This strategy is similar to the previous one; however, In this scenario, the DBA schedules one full backup and
instead of changing the recovery model of the database, multiple Log backups, between full backups. This plan
you back up the log just before the full backup. This has the advantage of reducing the amount of lost infor-
approach has the advantage of capturing not only the mation in case of total server collapse, because you can
data, but also the changes that occurred since the last schedule log backups more regularly than you can sched-
backup. The benefits of a Full & Log backup strategy are: ule full backups.
1) If Database files and Log are physically separated and
the database hard drive fails, you may back up the Log A diagram of a Full & Log backup strategy:
and not lose any data.
2) In case of a software failure, human error (end user or
DBA) or security breach; the DBA can first backup the
transaction log first and then restore the database to
a point in time, reducing the amount of loosed data.
Leaving the full recovery model on, allows you to
backup the transaction log first and restore the database
and the part of the transactions up to the last known
good reliable state. Consider the use of the Full & Log backup strategy in 8x5
3) If the database has multiple files and one fails, you databases, and non-volatile 24x7 databases. For example,
can first backup the tail of the transaction log (that you may schedule nightly Full Database backups and Log
include the transactions that occurred since the last backups every four hours.
log backup), and using the last full backup restore
only the failed file and the transactional log to restore Full – Differential – Log
transactional integrity.
Sometimes the information stored in a database is so
4) The transactional log backups can be used in forensic
analysis. valuable that you want to back up the information very
often. However, relying on backup logs is not feasible
There is some additional space involved in having the because, in case of failure, you will have to restore every
transaction log backup on a daily basis; however, in most log backup since the last full backup. In this case, the Full
databases this is not a relevant factor to consider. – Differential and Log strategy may help.

Schedule the Log backup before the full backup. This When using Full, Differential, and Log Backups the DBA
approach will speed up the recovery process. If you schedules a Full Backup occasionally, differential back-
schedule the Log backup before the full backup, you will ups often, and Logs very often. In this case, occasionally
only need to restore the last full backup and one transac- means as frequently as needed, to minimize the impact of
tion log to recover the database. Scheduling after the full a full backup, but enough to avoid differential backups to
backup will demand the restoration of the last full backup grow too much; often means as frequently as needed, to
and two transaction logs backups. minimize the impact of restoring too many log backups;
and very often means as frequently as needed to mini-
Use the Log & Full backup strategy in 8x5 databases mize data loss exposure. Some implementations of this
where you can afford to lose up to one day of work. strategy may be:
1) Full backup every month, differential backups every
night, and log backups every two hours.

2 The scale on the Backup strategies diagrams is deliberately abstracted. Some databases will require weekly full database backups; more often business
should choose daily backups; and finally others will required multiple daily full backups. Take into account the business requirements: value, volatility, size
and usage, when defining your backup plan.

6 BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 courtesy of Dell
 2) Full backup every week, differential backups every 6
hours, and logs every fifteen minutes.

A diagram of a Full – Differential – Log backup strategy:

Backup filegroups partitioned by I/O System (High avail-

ability), is simple because you only have to back up one
filegroup every time. However, when the filegroups are
partitioned across I/O systems (to increase performance)
you have to back up every file of each filegroup that
Use the Full, Differential and Log strategy in volatile resides in the same hard drive I/O System. Finally you
24x7 databases, when the value or your data requires may consider flagging a Filegroup as read only to elimi-
very frequent log backups, and in non-partitioned Data nate or reduce the frequency of the backups of that file-
marts. group. The following code marks a Filegroup as read only:

Full – File/Filegroup – Log Backup ALTER DATABASE AdventureWorks

In some databases the impact of a full backup is so large MODIFY FILEGROUP AdventureWorks2001 READONLY
that you want to avoid it as much as possible; at the same
time your database is most likely large enough to consid- Consider the use of a Full - File/Filegroup – Log Backup
er the use of multiple file and filegroups. In that scenario, strategy in Very Large Databases (VLDB) or partitioned
most likely you don’t want to back up the complete data- Data marts/Data warehouses. For example, you may back
base at once, you only want to back up parts of it. up a Full Database once a year, a Filegroup (assuming
that the filegroups are designed with High availability in
To create a backup strategy when using Filegroups, you mind) backup every day, and Log backups every hour.
have to be aware of the two main patterns that DBAs
often use to create filegroups. The first pattern is used to A diagram of a Full – Partial – Log backup strategy:
maximize performance and the other to maximize avail-
ability. In the first approach, to maximize performance,
the DBA assigns every Filegroup to one or more files in
each hard drive or I/O subsystem. Using this schema the
performance is increased because the server can use all
the devices in parallel. The following diagram may help
how understand how filegroups are assigned when their
purpose is to maximize performance. Service Level Agreement
Based on the analysis of the business and operational
requirements, the possible threats, and the options that
SQL Server 2005 provides to protect the data; the DBA
should write a Service Level Agreement (SLA). The SLA is
an agreement between customers and users on one side
and service providers on the other side. The SLA is writ-
ten like a contract and describes a set of operational goals
On the contrary, to maximize availability, Filegroups are that the IT Department promises to achieve. The following
assigned to one or more files in a single hard drive or I/O example is the part of an SLA3 regarding disaster recovery
subsystem. The benefit of using this approach is that if and backup and restores plans:
one of the hard drives fails, you will only have to restore • In case of the following incidents that disrupt the
that Filegroup. The following diagram may help you database service , the IT department will resolve the
understand how filegroups are assigned when their pur- problem under the following conditions:
pose is to maximize availability. ° In case of I/O system failure or human error, the
database service will be available within 4 hours of
the first report of the incident, and no more than 15
minutes of data will be lost.

3 A short SLA template can be found in http://www.nextslm.org/internalsla_short.html.

courtesy of DELL BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 7
 ° In case of a server breakdown due to software will be removed in future releases of SQL Server.
or hardware issues, the database service will be • When using the file system for backups, grant file and
available within 12 hours of the first report of the folder access to the SQL Service account and DBA
incident and no more than 15 minutes of data will only. The SQL Service account will require Read and
be lost. Write access to the folder or shared folder and the DBA
° In case of data center breakdown due to fire, flood, will required Full Control and should be the owner
earthquake or other environment or civil disasters, of the folder. Restring access to the backup files will
the database service will be available within 24 four prevent users from copying the files and restore them in
hours and no more than 4 hours of data will be lost. a server where they have administrative rights.
• Consider establishing an Auditing Policy on the Backup
To set unambiguous expectations of users, write an SLA Folder. Enabling file access auditing to the Backup
that describes the response time the IT Department will Folder will monitor user access to the backups.
provide in case of each type of event. • After the database is back up in a file or files, compress
and encrypt the files before moving the contents to
tape backups or other forms of long term storage.
Operational Best Practices Encrypting the backup files will help you protect the
Beside the backup and restore strategy, the DBA should confidentiality of the information if somebody gains
also consider different options and practices to handle physical access to the media.
backup and restore activities. The following guidelines • Physically secure backup media. Do not rely only on
may help you take some decisions about backup and encryption to secure the media, make sure that the
media is always physically secure to avoid someone to
restore procedures:
copy the media, and use brute force attacks to decrypt
the file and eventually restore the database in another
Performance server.
• Schedule Backup Operations When Database Activity Is • Sanitize the backup media before disposal. Do not
Low: Database operation may have an important impact throw tape media in the trash, unless you are absolutely
on the server; avoid backup operation when the activity certain that the data has been erased. Deleting the files
of the server is high, especially full database backups. or overwriting the files may not be enough. Consider
• Back up first to disk, whenever possible. Consider using the use of specialized software or magnetic methods to
a File Server to store the backups. Backing up to disk erase the information.
will greatly increase the performance of the backup
process and free the resources of SQL Server. Using file Integrity
backups also simplifies the restoration process. When • Use the CHECKSUM option of the Backup command.
backing up to a remote share, use UNC paths and do This option, new in SQL Server 2005, essentially
not use mapped drives. performs two types of verifications on database
• When using a File server to store backups, consider backups. The first one is that it stores a CHECKSUM
using a private LAN trunk to avoid general network of the backup that can help you verify if the backup
congestion. A private trunk requires that both the File is corrupt. The second verification only works if the
and the Database Servers have an additional network PAGE_VERIFY option of the database is in CHECKSUM
card connected to a private LAN. This practice also or TORN_PAGE_DETECTION mode. If one these modes
increases the security of the backup process. are enabled, the BACKUP statement will verify that
• Back up to tape or other devices for long run storage. the pages are reliable before they are backed up. The
Tapes and other media types offer an economical option default of the PAGE_VERIFY option is CHECKSUM;
to store the information for the long run. however the CHEKSUM option of the Backup command
• Do not use the same physical disk that hold the is not enabled by default. The following exemplifies the
database files or Log files for backup purposes. Using CHECKSUM option of the backup command:
the same physical disk not only affects the performance,
but also may reduce the recoverability of the plan. BACKUP DATABASE AdventureWorks
TO DISK = N’C:\Backup\AdventureWorks.bak’
Security WITH CHECKSUM
The following measures will help you reduce or handle
security threats: • Test Backup files periodically using the RESTORE
VERIFYONLY command. The following code is
an example of how to use RESTORE VERIFYONLY
Confidentially
command:
• Do not use the Password option of the Backup RESTORE VERIFYONLY
statement: The password option of the backup statement FROM DISK = N’C:\Backup\AdventureWorks.bak’
provides weak protection and does not prevent reading WITH CHECKSUM
of the data. The password option is also deprecated and

8 BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 courtesy of Dell
Availability the recovery team will test their ability to configure an
• Use the Mirror option of the Backup command to alternate environment ready for production.
backup to a local hard drive and a backup server
simultaneously. Having a local copy of the backup Manageability
increases the response time of the restoration process • Use SQL Server Agent to automate the Backup process.
and having a remote copy makes the copy available in Automating the backup process will facilitate the
case of a server collapse. The following command is backup process and reduce the likelihood of human
an example on how to use the MIRROR clause of the errors. The SQL Server agent will help DBAs automate
BACKUP command: administrative tasks, which include the backup process.

BACKUP DATABASE AdventureWorks To create a Job to backup a database use the following
TO DISK=’C:\Backup\AdventureWorks.bak’
MIRROR TO DISK=’\\ILUVATAR\Backup\AdventureWorks.bak’
procedure:
WITH FORMAT 1) Open SSMS
2) Connect to the SQL Server instance that holds the
• Perform trial restorations frequently. Frequently you database.
should verify that the backup system is properly copying 3) Navigate to the Server\Databases folder.
the database and that the backup hardware and process 4) Right click the database you want to backup.
is working correctly. Trial restorations should use test 5) From the shortcut menu, select Tasks, Backup.
server and should never be performed in a production 6) In the Database Backup dialog box, select the type of
environment. backup you want the server to perform, the backup
• Perform Fire Drills periodically. A fire drill is a
destination path and the backup options.
procedure that tests if the backup and restore plan will
help the IT department to be compliant with the SLA. In 7) Press Crl+Shift+M or select Script to Job option in the
a fire drill not only the backup is restored to verify the Backup Database window to create a Job.
integrity, the whole recovery plan is executed to verify 8) Select Schedules in the Select a Page listbox.
readiness in case of an event. A fire drill will assume 9) Press new to create a schedule for the backup.
that the production server or data center is down and 10) Configure the backup schedule (Figure 2) and select
Ok to confirm your selection.

Figure 2 New Schedule Window

courtesy of DELL BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 9
11) Select Ok to create the Job. Either approach can be adapted to handle intra-day back-
• Document the backup strategy: Documenting the ups.
backup strategy will help the restoration process. • Create a backup media log: A backup media log
• Define a backup media/tape rotation policy. A rotation keeps records of who handles backup media. Keeping
policy guarantees that there will be multiple copies of logs may be helpful in case of an event that requires
backups to recover from and protects the media from restoring the data and may be used for legal purposes.
excessive wear and damage. You should always keep
at least three different medias and at least one of them
should be an off-site copy. Other Best Practices
• Before restoring any database, consider the need of
The two most common strategies for tape rotation are backing up the existing log file. When the database
Grandfather – Father – Son (GFS) and Tower of Hanoi. files and the log are in different devices and the
database device fails; or if the database file is corrupted
The GFS approach uses three levels of tape rotation. or damaged you may be able to backup the log and
The first level contains daily backups, the second level recover the transactions up to the moment of failure.
Backing up the log file may also be useful for forensic
weekly backups and the third level contains monthly or
purposes in the case of security breaches. To back up a
four week period backups. Using this method in a 24x7 database that has the database files damaged, use the
database will require twenty two tapes per year, assum- NO_TRUNCATE or the COPY_ONLY and CONTINUE_
ing that each backup will use one tape. Six of the tapes AFTER_ERROR options of the BACKUP command. The
will be used in for daily backups (Sons), three tapes for following code is an example of how to back up an
weekly backups (fathers) and thirteen tapes will be used orphan log.
as monthly backups (Grandfathers). Monthly backup
will also be used for long term archiving. The following BACKUP LOG Test
TO DISK = ‘C:\Backup\AdventureWorksLog.bak’
diagram will help you understand the GFS tape rotation WITH COPY_ONLY, CONTINUE_AFTER_ERROR
policy:
• Before performing any High Risk
operation add a Log Mark or create a
Database snapshot. Adding a Log Mark
or a Database snapshot will facilitate
the recovery process in the event of
failure or need to recover.

To add a Log Mark use the WITH MARK

option of the BEGIN TRANSACTION
Command. An example of the code can be found bellow:
The Tower of Hanoi is a more complex system but uses
fewer tapes than the GFS strategy. It will require 18 tapes BEGIN TRANSACTION UpgradeVersion
per year to back up a database that uses one tape per WITH MARK ‘Upgrade to Version 2.1 ‘
backup. In the Tower of Hanoi approach there are 5 lev- GO
els of tape rotation: Level A is used every 2 days; Level -- Add Transactional code here
COMMIT TRANSACTION UpgradeVersion
B every 4 days, Level C every 8 days, Level D every 16
days, and Level E every 32 days. Finally, a Level F is also
every 32 days, but it is used only for long-term archiving.
The following diagram will help you understand the
Tower of Hanoi tape rotation policy:

10 BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 courtesy of Dell
To restore a database up to the mark, use the BACKUP DATABASE AdventureWorks
STOPATMARK option of the RESTORE LOG command. TO DISK = ‘C:\Backup\AdventureWorks.bak’
WITH COPY_ONLY
The following code will restore the database up using the
previously created log mark.
Summary of Backup Best Practices
RESTORE DATABASE AdventureWorks The following guidelines are a summary of the best prac-
FROM DISK = N’C:\Backup\AdventureWorks.bak’
WITH FILE = 1 tices included in this whitepaper:
, NORECOVERY • Have a Data Recovery Plan
° Begin designing your plan with a threat analysis
GO ° Make sure your plan covers threats from all sources:
RESTORE LOG AdventureWorks Hardware, Software, People and Environment.
FROM DISK = N’C:\Backup\AdventureWorks.bak’
WITH FILE = 2
° ou should consider the value, volatility, size and
Y

, STOPATMARK=’UpgradeVersion’
usage of your database when designing your data
GO recovery plan.
° The most relevant operational requirements of data
recovery plans are: security, performance, scalability
You can also use database snapshots when you want to
and manageability. Make sure your plan considers
have the ability to recover in case of a high risk operation. these requirements.
Database snapshots contrary to Log Marks can be used to • Backup Strategies
recover databases that use the simple recovery model. On ° Combine different backup types to create a backup
the other hand, database snapshots are only available in strategy.
the Enterprise Edition of SQL Server 2005. The following ° Do not backup tempdb.
code creates a database snapshot of the AdventureWorks ° Unless you plan to change its contents, do not back
database: up the model database.
° Use the Full Backup simple mode strategy only in
CREATE DATABASE AdventureWorks_PreviousVersion development, read only, stage or system databases.
ON ( NAME = AdventureWorks_Data ° Schedule the Log backup before the Full backup
, FILENAME = ‘C:\Backup\AdventureWorks_ ° Use the Log & Full backup strategy in 8x5 databases
PreviousVersion.ss’ ) where you can afford to lose up to one day of work.
AS SNAPSHOT OF AdventureWorks;
GO ° Consider the use of the Full & Log backup strategy
in 8x5 databases, and non-volatile 24x7 databases.
The following code will restore the database from a previ- ° Use the Full, Differential and Log strategy in volatile
24x7 databases, when the value or your data
ously created snapshot: requires very frequent log backups, and in non-
partitioned Data marts.
RESTORE DATABASE AdventureWorks
FROM DATABASE_SNAPSHOT = ‘AdventureWorks_
° Consider the use of a Full - File/Filegroup – Log
PreviousVersion’
Backup strategy in Very Large Databases (VLDB) or
partitioned Data marts/Data warehouses.
• Only DBAS should be able to restore and back • Write a Service Level Agreement that describes the
up databases: Limit access to Backup and Restore response time the IT Department will provide in case of
operations, because either one can hinder your backup each type of event.
plan. • Performance
• Use the COPY_ONLY option for unscheduled backups. ° Schedule Backup Operations When Database
The COPY_ONLY option of the BACKUP command Activity Is Low.
identifies backups that should not affect the normal ° Back up first to disk, whenever possible. Consider
sequence of backups. This command is useful when you using a File Server to store the backups.
want to backup databases outside your DRP. If you do ° When using a File server to store backups, consider
not use this option you may disrupt the plan, because using a private LAN trunk to avoid general network
the backup may not be available in case of a disaster. congestion.
When you run a full backup with the COPY_ONLY, the ° Back up to tape or other devices for long run
command will not affect following differential backups storage.
that will not use this backup as the starting point. When ° Do not use the same physical disk that hold the
you run a Log backup with the COPY_ONLY option, the database files or Log files for backup purposes.
Log is not truncated and will be available for the next • Security
Log backup. An example of how to use the COPY_ONLY ° Do not use the Password option of the Backup
option: statement.
° When using the file system for backups, grant file

courtesy of DELL BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 11
 and folder access to the SQL Service account and Javier Loria is a Solid Quality Mentors Mentor based in
DBA only Costa Rica. He began his professional career in 1992,
° Consider establishing an Auditing Policy on the as a software developer and system engineer. His career
Backup Folder evolved rapidly to the training side, especially in the XML
° After the database is back up in a file or files, and OLAP world, training customers at different loca-
compress and encrypt the files before moving the
contents to tape backups or other long term storage. tions in Latin America. He is a software architect, and
Business Intelligence Architect assisting our customers in
° Physically secure backup media.
° Sanitize the backup media before disposal. Latin America. Javier became SQL Server MVP in 2001.
° Use the CHECKSUM option of the Backup Javier is an MCT, MCSE, MCSD, MCDBA, and MCAD.
command Javier was an active member responsible for writing the
° est Backup files periodically using the RESTORE
T
 Microsoft SQL Server 2005 courseware. He is the coau-
VERIFYONLY command. thor of several books including MOC2782: Designing
° Use the Mirror option of the Backup command to Microsoft® SQL Server™ 2005 Databases, MCTS Training
backup to a local hard drive and a backup server Kit 70-431: Implementing and Maintaining SQL Server
simultaneously. 2005 and Microsoft SQL Server 2005 Database Essentials
° Perform trial restorations frequently. Step by Step.
° Perform Fire Drills periodically.
•M anageability
° Use SQL Server Agent to automate the Backup
process.
° Document the backup strategy.
° Define a backup media/tape rotation policy.
° Create a backup media log.
•O ther Best Practices
° Before restoring any database, consider the need of
backing up the existing log file
° Before performing any High Risk operation add a
Log Mark or create a Database snapshot
° Only DBAS should be able to restore and backup
databases.
° Use the COPY_ONLY option for unscheduled
backups.

For more information, contact Dell. Information in this

document is subject to change without notice.

Microsoft, SQL Server, and Windows are registered

trademarks of Microsoft Corporation. Other trademarks
and trade names may be used in this document to refer to
either the entities claiming the marks and names or their
products. Dell disclaims proprietary interest in the marks
and names of others.

12 BEST PRACTICES FOR BACKUP AND RESTORE IN SQL SERVER 2005 courtesy of Dell