SQL Server 2008 R2 : Database Backup and Restore (part 6) - Backup Scenarios

Full Database Backups Only

A full database backup, without the use of other database backups, is often found in nonproduction environments where the loss of transactional data is relatively unimportant. Some development environments are good examples of this. In these environments, a nightly full backup is sufficient to ensure that recent Data Definition Language (DDL) changes and the related development data for the day are captured. If a catastrophic failure occurs during the day and causes a restore to occur, the database can be restored from the prior night’s backup. The following example shows a full backup of the AdventureWorks2008 database:

--Full Database Backup to a single disk device
BACKUP DATABASE [AdventureWorks2008]
 TO  DISK = N'C:\mssql2008\backup\AdventureWorks2008.bak'
 WITH NOFORMAT, INIT,  NAME = N'AdventureWorks2008-Full Database Backup',
 SKIP, NOREWIND, NOUNLOAD,  STATS = 10

The sole use of daily full database backups needs to be carefully considered. The benefits of limited administration and limited backup space requirements have to be weighed against the costs of losing an entire day’s transactions.

Full Database Backups with Transaction Log Backups

Compared to making a full database backup only, a more comprehensive approach to database backups includes the use of transaction log backups to augment the recoverability of full database backups. Transaction log backups that are taken periodically capture incremental database activity that can be applied to a full database backup during database restore.

You need to measure the frequency of the transaction log backup against the tolerance for data loss. For example, if the requirement is to prevent no more than one hour’s worth of work, the transaction log backups should be taken hourly. If the media on which the backup is stored is accessible, you should lose no more than one hour’s worth of data.

As mentioned earlier, the database must be placed in full or bulk-logged recovery mode to capture transaction log backups. Listing 1 shows the commands necessary to place the AdventureWorks2008 database in full recovery mode, the required backup to establish a base, followed by the command to perform the actual transaction log backup.

Listing 1. Full Backups with Transaction Logs

--First need to change the recovery model from simple to full
--so that the tlogs are available for backup
ALTER DATABASE [AdventureWorks2008] SET RECOVERY FULL WITH NO_WAIT

--*** A Full database backup must be taken after the
--*** recovery mode has been changed
--*** in order to set a base for future tlog backups.
--*** If the full backup is not taken
--*** then tlog backups will fail.
--The Following full backup utilizes two devices on the same drive.
--Often times multiple devices are backed up to different drives.
--Backing up to different drives
-- can speed up the overall backup
time and help when you are running low on space on a drive
-- where your backups are written.

BACKUP DATABASE [AdventureWorks2008]
 TO  DISK = N'C:\mssql2008\backup\AdventureWorks2008_Full_Dev1.bak',
     DISK = N'C:\mssql2008\backup\AdventureWorks2008_Full_Dev2.bak'
 WITH NOFORMAT, NOINIT, SKIP, NOREWIND, NOUNLOAD,  STATS = 10

--Transaction log backups can be taken now that a base has been established
--The following tlog backup is written to a single file
BACKUP LOG [AdventureWorks2008]
 TO  DISK = N'C:\mssql2008\backup\log\AdventureWorks2008_FirstAfterFull.trn'
 WITH NOFORMAT, INIT,  NAME = N'AdventureWorks2008-Transaction Log  Backup',
 SKIP, NOREWIND, NOUNLOAD,  STATS = 10, CHECKSUM


					  

Differential Backups

Differential backups can be used to reduce the amount of time required to restore a database and can be particularly useful in environments where the amount of data that changes is limited. Differential backups capture only the database extents that have changed since the last database backup—typically, a full database backup.

The addition of differential backups to a plan that includes full database backups and transaction log backups can significantly improve the overall recovery time. The differential database backup eliminates the need to apply any transaction log backups that have occurred from the time of the last full backup up until the completion of the differential backup. Figure 5 depicts a backup plan that includes full database backups, transaction log backups, and differential backups. The differential backups are executed on a daily basis between the full backups.

Figure 5. A backup plan that includes differential backup.

It is important to remember that differential backups are cumulative and contain all changes since the last differential base. There is no need to apply previous differential backups if the new differential base has not been established. For example, in the backup plan shown in Figure 14.5, if a media failure occurred in the middle of the day on January 3, the differential backup that would be used is the one taken at the beginning of the day on January 3; the differential backup that occurred on January 2 would not be needed. The full backup from January 1, the differential from January 3, and any transaction log backups that had occurred since the differential on January 3 would be used to restore the database.

You can create differential backups by using SSMS or T-SQL. The following example demonstrates the creation of a differential backup for the AdventureWorks2008 database using T-SQL:

BACKUP DATABASE [AdventureWorks2008]
 TO  DISK = N'C:\mssql2008\backup\AdventureWorks2008_Diff2.bak'
 WITH  DIFFERENTIAL , NOFORMAT, INIT,
 NAME = N'AdventureWorks2008-Differential Database Backup',
 SKIP, NOREWIND, NOUNLOAD,  STATS = 10

Partial Backups

Partial backups are useful when read-only files or filegroups are part of a database. Listing 14.2 contains the commands necessary to add a read-only filegroup to the AdventureWorks2008 database. The commands in Listing 2 do not perform a partial backup, but they do modify a sample database so that a partial database would make sense.

Listing 2. Adding a Read-Only Filegroup to a Database

--Need to add a read only filegroup first to demonstrate
ALTER DATABASE AdventureWorks2008
ADD FILEGROUP ReadOnlyFG1
GO
-- Add a file to the Filegroup
ALTER DATABASE AdventureWorks2008
ADD FILE
(    NAME = AdventureWorks2008_ReadOnlyData,
    FILENAME = 'C:\mssql2008\data\AdventureWorks2008_ReadOnlyData.ndf',
    SIZE = 5MB,
    MAXSIZE = 100MB,
    FILEGROWTH = 5MB) TO FILEGROUP ReadOnlyFG1
go
--Create a table on the ReadOnly filegroup
CREATE TABLE AdventureWorks2008.dbo.MyReadOnlyTable
  ( FirstName varchar(50),
    LastName varchar(50),
    EMailAddress char(1000) )
ON ReadOnlyFG1

--Insert some data into the new read only Filegroup
insert AdventureWorks2008.dbo.MyReadOnlyTable
 select LastName, FirstName, 'xxx'
 from AdventureWorks2008.person. person

--Make the filegroup readonly
 ALTER DATABASE [AdventureWorks2008] MODIFY FILEGROUP [ReadOnlyFG1] READONLY


					  

When you have a filegroup that contains read-only data, a partial backup can be valuable. The partial backup by default excludes any read-only filegroups and backs up only the read/write data that could have changed.

Listing 3 contains three separate backup commands that relate to the partial backup. The first backup command is not a partial backup but instead backs up the read-only filegroup. If the read-only filegroup is not backed up prior to the partial backup, the read-only filegroup is backed up, as is part of the partial backup. The second backup command creates the actual partial backup. The key parameter in this backup is READ_WRITE_FILEGROUPS, which causes the backup to skip the read-only data. The third backup command in Listing 14.3 shows that it is possible to perform a partial backup that includes the read-only data as well. This command includes a specific reference to the read-only filegroup, which causes it to be backed up as well.

Listing 3. Making a Partial Backup

--Need to backup the readonly filegroup that was created
-- or it will be included in the partial backup
BACKUP DATABASE [AdventureWorks2008]
 FILEGROUP = N'ReadOnlyFG1'
 TO  DISK = N'C:\mssql2008\backup\AdventureWorks2008_ReadOnlyFG.bak'
 WITH NOFORMAT, NOINIT,  NAME = N'AdventureWorks2008-Full Filegroup Backup',
 SKIP, NOREWIND, NOUNLOAD,  STATS = 10

--Create the Partial Database Backup
--It will not contain the data from readonly filegroup
--The partial database backup can be restored without affecting
-- the data in the readonly filegroup
BACKUP DATABASE [AdventureWorks2008] READ_WRITE_FILEGROUPS
 TO  DISK = N'C:\mssql2008\backup\AdventureWorks2008_Partial.bak'
 WITH NOFORMAT, INIT,  NAME = N'AdventureWorks2008-Partial Database Backup',
 SKIP, NOREWIND, NOUNLOAD,  STATS = 10

--It is possible to backup the readonly filegroup(s) as well
--by listing the readonly filegroups in the backup command as shown in the
--following backup command
BACKUP DATABASE [AdventureWorks2008] FILEGROUP = 'ReadOnlyFG1',
 READ_WRITE_FILEGROUPS
 TO  DISK = N'C:\mssql2008\backup\AdventureWorks2008_Partial_WithReadOnly.bak'
 WITH NOFORMAT, INIT,  NAME = N'AdventureWorks2008-Partial Database Backup',
  SKIP, NOREWIND, NOUNLOAD,  STATS = 10


					  

File/Filegroup Backups

Much of our discussion thus far has focused on backing up an entire database, but it is possible to back up only particular files or a group of files in a filegroup. A SQL Server database, by default, has only two files: the data file (with the file extension .mdf) and the log file (with the extension .ldf). You can add additional files and filegroups that contain these files to extend the database beyond the original two files. These additional files are often data files added to larger databases that require additional space. With very large databases, performing a full backup that contains all the database files can take too much time. In such a case, the individual files or filegroups can be backed up separately, enabling you to spread out the backup.

Listing 4 shows the T-SQL command that can be used to back up the read-only file you added to the AdventureWorks2008 database in Listing 3.

Listing 4. Creating a File Backup

BACKUP DATABASE [AdventureWorks2008] FILE = 'AdventureWorks2008_ReadOnlyData'
 TO  DISK = N'C:\mssql2008\backup\AdventureWorks2008_ReadOnlyData.bak'
 WITH NOFORMAT, INIT,  NAME = N'AdventureWorks2008-Readonly File Backup',
  SKIP, NOREWIND, NOUNLOAD,  STATS = 10


					  

There is some additional administrative overhead associated with file and filegroup backups. Unlike a full database backup that produces one file that contains the entire database, the file backups do not stand by themselves and require other backups to be able to create the entire database. You need to keep the following points in mind when performing file and filegroup backups:

• A file or filegroup backup does not back up any portion of the transaction log. To restore a file or filegroup backup, you must have the transaction log backups since the last file or filegroup backup, including the tail of the log, for the database system to ensure transactional consistency. This also implies that the database must be in full or bulk-logged recovery because these are the only models that support transaction log backups.

• Individual file or filegroup backups can be restored from a full database backup.

• Point-in-time recovery is not permitted with file or filegroup backups.

• Differential backups can be combined with file or filegroup backups. These differential backups capture only those extents that have changed since the file or filegroup backup was made.

File and filegroup backups can be very powerful options for very large databases, but you need to ensure that the relevant backups can be accounted for. In all backup situations, the key to a successful plan is testing your backup strategy; this is particularly true with file and filegroup backups.

Mirrored Backups

The use of mirrored backups can help diminish the possibility of losing a database backup. Database backups can be your lifeline to recovery, and you do not want to lose them. Mirrored backups simultaneously write the backup information to more than one media set. You can mirror the backup to two, three, or four different media sets. Listing 5 gives an example of a mirrored backup that writes two different media sets.

Listing 5. Creating a Mirrored Backup

BACKUP DATABASE AdventureWorks2008
TO disk = 'C:\mssql2008\backup\AdventureWorks2008_Mirror1a.bak',
   disk = 'C:\mssql2008\backup\AdventureWorks2008_Mirror1b.bak'
MIRROR TO disk = 'c:\mssql2008\backup\AdventureWorks2008_Mirror2a.bak',
   disk = 'C:\mssql2008\backup\AdventureWorks2008_Mirror2b.bak'
WITH FORMAT,
    MEDIANAME = 'AdventureWorks2008MirrorSet'

The example in Listing 14.5 is simplistic and demonstrates only the backup’s capability to write to two different locations. At the end of the backup example, four files will exist. Each pair of files can be used to restore the database. In the real world, a backup like that in Listing 14.5 would write to two different disk or tape drives. Storing the media on the same drive is very risky and does not give you all the advantages a mirror can afford.

Copy-Only Backups

If you want a backup that will not affect future or past backups, copy-only backups are for you. The copy-only backup allows you to make a database or log backup without identifying the backup as one that should be included in a restore sequence.

Contrast this with a full database backup: If a full database backup is taken, the information related to this backup is captured in the system tables. This backup can form the base for other backups, such as transaction log backups or differential backups, and must be retained to be able to restore the backups that depend on the base.

The following example shows a copy-only backup; the COPY_ONLY parameter is the key to creating this kind of backup:

BACKUP DATABASE [AdventureWorks2008]
 TO  DISK = N'C:\mssql2008\backup\AdventureWorks2008_COPY.bak'
 WITH COPY_ONLY

Compressed Backups

How would you like to create a backup file that is smaller and takes less time to create? Sign me up. This has got to be an option that the average database user would love to use. Compressed backups are smaller in size than uncompressed backups. The reduced size of a compressed backup typically requires less device I/O and can therefore reduce backup times significantly.

You must be aware that there are some trade-offs, however. First, this feature is available only with Enterprise Edition or Developer Edition. Second, the creation of a compressed backup can impact on the performance of concurrent operations on your database server while the backup is being created. Specifically, CPU usage increases during the backup. This may or may not be an issue for you. Consider that many full database backups are taken during off-hours, so there are more CPU cycles available during this time. Either way, you should monitor the CPU usage using compression versus not using compression to evaluate the impact. Another option is to create low-priority compressed backups in a session whose CPU usage is limited by the Resource Governor. 

When you get past these hurdles, the creation of a compressed backup is straightforward. One option is to set a server option so that all backups are created as compressed files by default. You can use the sp_configure stored procedure to set the backup compression default. If this is set to true, future backups will be created in a compressed format unless the backup is specifically created with the NO_COMPRESS option.

You also have the option of creating a compressed backup regardless of the server option. This is done using the new COMPRESSION option available with the T-SQL BACKUP command. The following example shows how to create an AdventureWorks2008 backup in the compressed format:

BACKUP DATABASE [AdventureWorks2008]
TO DISK = N'C:\MSSQL2008\Backup\AdventureWorks2008_compressed.bak'
WITH NOFORMAT, NOINIT,
 NAME = N'AdventureWorks2008-Full Database Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10

The compression is quite impressive. In some simple tests performed on the AdventureWorks2008 database, the compressed backup was one fourth the size of a noncompressed backup. The compression ratio varies depending on the type of data in the database that you are backing up but can be as good as or better than 4:1.

System Database Backups

The system databases are the master, model, msdb, resource, tempdb, and distribution databases. SQL Server uses these databases as part of its internal workings. All these databases should be part of your backup plan, except for resource and tempdb. The important point to remember about all these databases is that they contain key information about your SQL Server environment. The msdb database contains information about backups and scheduled jobs. The master database contains information about all the user databases stored on the server. This information can change over time.

To ensure that you do not lose the information the system databases contain, you should back up these databases as well. Typically, nightly full database backups of these databases suffice. You can use the same backup T-SQL syntax or SSMS screens that you use for a user databases to accomplish this task.