1. Recovery Models
The first thing you need to be
aware of when determining a backup strategy is the database recovery
model. A database recovery model determines how transactions are logged
and therefore impacts the type of backup operations that can be
performed on a database. You can set a database to use one of three
different recovery models that provide different levels of transaction
protection.
Full:
The full recovery model provides the highest level of data protection
by logging all transactions. It is usually the preferred recovery model
for all production databases. The full recovery model also gives you the
most flexibility in your backup strategy by allowing you to perform any
type of backup available in SQL Server.
Bulk-logged:
The bulk-logged recovery model is much like the full recovery model
except that certain operations are minimally logged, reducing the space
that would be required to store the entire transaction in the log file.
You will also receive performance gains on bulk operations, since only
the end result is logged and not the entire operation. As with the full
recovery model, you can also perform any type of backup for a database
that is bulk-logged. The limitation is that you may not be able to do a
pointin- time recovery if a
bulk operation has been performed. The following are considered bulk
operations and are minimally logged when using the bulk-logged recovery
model.
SELECT INTO
BCP
BULK INSERT
OPENROWSET with the BULK rowset provider
CREATE INDEX
ALTER INDEX REBUILD
DROP INDEX (The page deallocation is fully logged, but if a heap rebuild is necessary, it will be minimally logged.)
Partial updates to large data types using the .WRITE clause
Simple:
The simple recovery model does not offer any form of logged data
protection and is generally not used in production environments that
require point-in-time recovery since the last full backup. The
transaction log only holds the data until a checkpoint has occurred and
the data is written to disk. For this reason, you cannot perform
transaction log backups on a database that is using the simple recovery
model. As with the bulk-logged recovery model, bulk operations are also
minimally logged using the simple recovery model.
You can also use sort of a
hybrid method between the full and bulk-logged recovery models. You can
set the database to use the full recovery model, and then change it to
use bulk-logged when performing specific bulk operations that may not
perform well using the full recovery model. You should back up the log
before switching to the bulk-logged recovery model, and then back up
once again after switching back to the full recovery model. This will
minimize the logs that cannot be restored using the point-in-time
recovery option.
To check the current recovery model, you can use the DATABASEPROPERTYEX system function using the RECOVERY parameter, as shown in Listing 1. To change a database recovery model, you can use the ALTER DATABASE statement specifying FULL, BULK_LOGGED, or SIMPLE, also shown in Listing 1.
Example 1. Code to View and Change the Database Recovery Model
USE master
GO
--Select the database recovery model
SELECT DATABASEPROPERTYEX('AdventureWorks2008','RECOVERY');
--Change the database recovery model
ALTER DATABASE AdventureWorks2008 SET RECOVERY FULL;
2. Backup Architecture
Backups are grouped into logical containers known as media sets. A media set
is one or more tapes or disk files that contain an ordered collection
of backups. A media set must be either completely on tape or completely
on disk. You can't create a media set that spans multiple device types. A
new media set is created the first time a backup is performed or by
using the FORMAT option in the BACKUP statement. The FORMAT
option deletes the old media header and creates a new header for the
media set. The header contains information about the media type and
media family.
Media family
refers to the type of device that was used to create the media set. If
you use multiple backup devices in a media set, your backup set will
contain multiple media families. For example, if you back up your
database to two disk files, the media set will contain two media
families that are both marked as disk devices.
Media sets are made up of one or
more backup sets. A backup set consists of all the information gathered
during an individual backup process. Each time a successful backup is
performed, a backup set is added to the media set. The backup set is
evenly distributed across all the devices that make up the media set.
Look at the sample code in Listing 2. The BACKUP command creates a media set named AdventureWorks2008_MediaSet that contains two disk devices, meaning the media set contains two media families. Each time the BACKUP command is executed, a backup set is evenly written across the two devices. The illustration shown in Figure 1 assumes you have executed the BACKUP command three times to create three backup sets.
Example 2. Code to Create a Media Set with Multiple Devices
USE master
GO
BACKUP DATABASE [AdventureWorks2008] TO
DISK = 'C:\Backup\AdventureWorks2008_1.bak',
DISK = 'D:\Backup\AdventureWorks2008_2.bak'
WITH MEDIANAME = 'AdventureWorks2008_MediaSet'
GO
|
Most of the time this
architecture goes unnoticed because a database is backed up to a media
set on a single disk to a single file; so we tend to think of it as just
a backup file. If you think of backups in terms of backup sets, media
sets, and media families, it will make a lot more sense when reviewing
many of the backup options available in SQL Server.
