If a database file is lost but the log file is still intact, replaying the tail-log backup into the restored database allows you to bring the database up-to-date and eliminate the loss o
Trang 1Backup Type Functionality Purpose
Copy Only Same as the full backup,
however, the copy-only backup does not mark the database as having been backed up You cannot take differential backups based on a copy backup.
Take an additional database backup without interfering with normal backup sequence.
Transaction Log Back up all log entries
since the last full backup Multiple continuous log backups can be restored or
“replayed” into a restore of a full backup, bringing the database up-to-date.
Perform a fast and efficient backup of all changes since the last full backup Unlike differential backup, you can restore or “replay” a log backup to a particular point-in-time This allows you to roll back unwanted activity like malicious deletions This also truncates the log file.
Tail-Log Backup Backup of the
transaction log performed just before
a restore operation.
If a database file is lost but the log file is still intact, replaying the tail-log backup into the restored database allows you to bring the database up-to-date and eliminate the loss of transactions that occurred after the backup.
Table 7.2 Continued SQL Server 2008 Backup Types
TEsT Day Tip
Study the various types of backup available and ensure that you
understand the differences between them Remember that although
differential and transaction log backups are quicker to perform, they
take a longer time to be replayed into a restored database On the other hand, while backing up the entire database is time consuming, restoring
it as a whole is faster than replaying numerous differential and
transac-tion log backups into an initial restored database.
Trang 2Choosing a Database Backup Strategy
Choosing the appropriate database backup strategy depends on your organization’s individual business continuity requirements, the size of your database, and the amount of time allocated for backup operations The data loss tolerance is a measure defining how much data your organization is prepared to lose in the worst case scenario For example, if your organizations data loss tolerance is one day, you must take some form of backup at least every day If the data loss tolerance is six hours, you must take some form of backup at least every six hours
The challenge of any disaster recovery strategy is balancing the data loss tolerance against the amount of time it takes to perform a backup For example, a full backup
of a large database can take 24 hours or longer This means that you cannot conduct full backups every six hours In this situation, you may wish to settle for a full backup every weekend and a differential or log backup every six hours
Use the following best practices as your guide when selecting a backup strategy: For small databases, you can choose to take full backups only Perform a full
■
■
backup as often as your data loss tolerance dictates, e.g., every day or every weekend Restoring a full backup is the most complete and time-effective way to restore a database Tail-log backups can be used in conjunction with
a restore from a full database backup in the event that the database file is lost but the log file is not
Full + transaction log backup strategy is suitable to larger databases For
■
■
example, you can choose to backup the database every weekend and trans-action logs every day This achieves a reduction in backup time and a reduction in the space consumed by the backup while providing you with the complete backup of the daily database activity The trade-off is in the restore time It takes longer to replay every single log backup into the database than simply restoring the entire database from a full backup When recovering the database protected by this backup strategy, you must first restore the latest full database backup You must then restore every log backup, including the tail-log backup if desired This is the only strategy that allows you to recover to a point-in-time
Full + differential backup strategy is suitable for very large databases, where
■
■
certain extents are updated more frequently than others For example, you can choose to backup the database every weekend, and back up the differences every day This gives you a complete backup of daily database activity as well as a reduction in backup time and a reduction in space con-sumed by the backup Again, the trade off is in the restore time It takes
Trang 3longer to replay all the daily differentials into a database than to restore the
entire database from a full backup When recovering the database protected
by this backup strategy, you must first restore the latest full database backup
You can then restore the latest differential backup Finally, you can restore
any transaction log backups (including the tail-log backup) taken since the
last differential backup This strategy consumes less restore time than an
equivalent full + log backup but more restore time than the full backup only
File or filegroup backup strategy consists of alternately backing up each
■
■
read/write file or filegroup that comprises the database Additionally, the
transaction log grown between file or filegroup backups is also backed up
This strategy is suitable for large partitioned databases Although this strategy
consumes less backup time than a full backup, it is more complicated
New & Noteworthy…
Backup File Compression
Compressing backups is a new feature of SQL Server 2008 Performing
compressed backup is only available in the Enterprise edition of SQL
Server 2008 All editions of SQL Server 2008 and later can restore
com-pressed backups Comcom-pressed backup offers performance advantages as
the backup file is smaller However, performing compressed backups is
more processor intensive than performing uncompressed backups.
Compressed backups cannot reside on the same media set (file or
tape) with uncompressed backups or non-SQL Server backups Compressed
backups cannot be read by earlier versions of SQL Server.
TEsT Day Tip
Remember that only a transaction log backup can be used to restore a
database to a point-in-time You can only replay a transaction log
backup into a restored database For example, if you took a full
data-base backup on 15 February at 1:00 a.m and log backups every day until
20 February, you can restore the database from the full backup then
bring it forward to any point in time between 15 February 1:01 a.m and
20 February You cannot, however, roll the database back to 14 February
or any time before the full database backup.
Trang 4Restoring Databases
When you wish to recover database data, you must restore the database from
backup to an operational state During a restore, the database is copied from backup, but the restore operation is not marked complete At this point, any contiguous transactions recorded in the log can be applied to the restored database This process
is known as “roll forward”, because it advances the database state to a target recov-ery point The recovrecov-ery point is usually all available data However, in certain
circumstances you may wish to roll the database forward to a specific point in time Once the restore is marked complete, no subsequent differential or log backups can
be rolled forward into the database
There are multiple possible restore scenarios The restore scenario you choose depends on your restore requirements and the type of backup you are restoring from The restore scenarios are dependent on the database recovery model and the SQL Server edition
When you restore a database from a database backup, SQL Server re-creates the database All database and log files are placed in their original location, unless new
Configuring & Implementing…
Performing Test Restores
Disasters strike unexpectedly To be prepared for disaster recovery, you must perform regular test restores Performing a test restore can help you determine whether the recovery procedures defined in your disaster recovery strategy meet your organization’s objectives for data recovery Test restores also help administrators understand the course of action to take in the event of a disaster If a disaster occurs, they will be able to act
in a competent manner.
Test restores also validate the backup procedures Only a successful test restore can assure that the backup is functioning, the backup hard-ware is working correctly, and the backup media is intact.
When performing a test restore, you should consider doing so on a separate lab server Alternatively, if this is not possible, you can restore the database under a different name onto the existing server.
Trang 5locations are explicitly specified SQL Server databases are inherently portable
You can restore databases from backup on any SQL Server or even restore a copy
of the database under a different name on the same server
Performing Online Restore
During a full restore, the database is normally rendered inaccessible, and users
cannot connect to or use the database However, sometimes you may be restoring
only a small part of the database like a file, filegroup, or individual page In this case,
it is possible to leave the database online, and all parts of the database, except the
ones you are restoring, will be accessible to users Online restore is the default when performing file, filegroup, or piecemeal (multiple filegroup) restores
To perform an online restore, follow these steps:
1 Restore the data file, filegroup, or page
2 Restore the log Use the WITH RECOVERY option for the last log
restore (see Example 7.22)
3 The restored data will become accessible once the log has been replayed
successfully
Example 7.22 Performing an Online Restore
First, restore the filegroup A and C
RESTORE DATABASE adb FILEGROUP='A',FILEGROUP='C'
FROM partial_backup
WITH PARTIAL, RECOVERY;
Next, restore the filegroup B At this point filegroups A and C are
accessible to users.
RESTORE DATABASE adb FILEGROUP='B' FROM backup
WITH RECOVERY;
Restoring Individual Pages
Sometimes data corruption can result in “suspect” pages These are pages that
cannot be read by SQL Server or that result in errors when accessed You can view
the list of suspect pages for all databases by querying the suspect_pages table in the
MSDB database If the suspect page occurs in a nonclustered index, you can repair
the index by rebuilding it If the suspect page contains table data, you will have to
restore it from backup Page restores are performed online Example 7.23
demonstrates the proper use of PAGE parameter with RESTORE DATABASE