1. MS SQL by: Bryan Bankhead CIS 407

2. General Concepts  Backing up and Restoring databases and transaction logs is a way that SQL Server provides protection from data loss. The backup operation creates a copy of a database. This copy can be used to restore the database ○ if the media failure occurs ○ if the database is somehow damaged  SQL Server supports the following kinds of backup: Full database backup ○ it is a full copy of the database Differential backup ○ it contains the copy of only the database pages modified after the last full backup Transaction log backup ○ it contains the copy of the transaction log only  SQL Server supports three recovery models which determine how your data is backed up and what your exposure to data loss is. Simple recovery model Full recovery model Bulk-Logged recovery model

3. Types of Backups  SQL Server provides several different kinds of backups. A combination of these backups may be used to formulate a robust disaster recovery strategy.  Backup Type Description Complete -- Backs up the entire database. Differential -- Backs up only modified extents since the previous complete backup. Transaction Log -- Backs up the active portion and truncates the inactive portion of the transaction log. File / Filegroup -- Backs up individual files and filegroups within a database. File differential -- Combines differential backups and file or filegroup backups.

4. The following illustration shows a backup strategy that supplements full database backups with differential database backups and also a series of routine log backup  The presence of transaction log backups reduces potential work-loss exposure to the time after the most recent log backup.  After the first database backup, a series of three differential backups is taken.  The third differential backup is large enough that the next backup is a full database backup.  This establishes a new differential base.

5. Simple Recovery Model  The Simple Recovery model allows the database to be recovered to the point of the last backup (to the most recent backup).  With this recovery model, you cannot restore the database to the point of failure or to a specific point in time. So, changes since the last backup will be lost.

6. Full Recovery Model  The Full Recovery model allows the database to be recovered to the point of failure or to a specific point in time.  This recovery model provides the best protection of your data, but requires more time to make backup and restore.  With the Full Recovery model, all operations, including bulk operations such as SELECT INTO, CREATE INDEX, and bulk loading data, are fully logged.

7. Bulk-Logged Recovery Model  The Bulk-Logged Recovery model provides better performance in comparison with the Full Recovery model because the SELECT INTO, Bulk load operations, CREATE INDEX and WRITETEXT, UPDATETEXT operations are minimally logged.  Full and Bulk-Logged Recovery models are similar, and you can switch between them easily.  The Bulk-Logged Recovery model does not allow the database to be recovered to a specific point in time.  Under this recovery model the transaction log backups capture both the log and the results of any bulk operations performed since the last backup, so it is not necessary to perform a full database backup after bulk copy operations complete.

8. Transaction Log Backup  A transaction log captures the modifications made to the database.  If SQL Server service shuts down unexpectedly, upon restart the recovery process examines the entries in the transaction log and if there are transactions that have not been rolled forward completely, the recovery process rolls back the changes performed as part of these incomplete transactions.  A transaction log backup backs up all transactions since either the previous transaction log backup, or the complete database backup if there have been no transaction log backups performed for the database in the past.  A transaction log backup also truncates the inactive portion of the transaction log, unless the database is configured as a Publisher in transactional replication and there are transactions pending propagation to Subscribers.  Each transaction log backup contains a First and Last log sequence number (LSN). Consecutive transaction log backups should have sequential LSNs for the boundary log records. These LSN values may be examined using the RESTORE HEADERONLY command. If Last LSN from the previously restored transaction log backup does not match the First LSN from the backup that is currently being restored, the restore operation fails with the following error  Transaction log backups provide the possibility of performing a point-in-time restore or point-of-failure restore.

9. Resources  http://msdn2.micros oft.com/en- us/library/ms190217.aspx http://msdn2.micros oft.com/en- us/library/ms190217.aspx  http://www.mssqlcity. com/Articles/Adm/ba ckup_database.htm http://www.mssqlcity. com/Articles/Adm/ba ckup_database.htm  http://cis407.asgard designsystems.com/ http://cis407.asgard designsystems.com/  http://www.microsoft. com/technet/prodtec hnol/sql/2000/maint ain/sqlbackuprest.m spx http://www.microsoft. com/technet/prodtec hnol/sql/2000/maint ain/sqlbackuprest.m spx