Back up

SQL Server 2008 backups can be performed

during normal database activity. There is no need to disconnect users or shut down any services. Backups can be sent to disk. To send backups to tape, the tape device must be locally attached to the database server. --Full database backup of SmallWorks to a drive location BACKUP DATABASE SmallWorks TO DISK = C:\SQLBackups\FullSmallWorks.BAK WITH DESCRIPTION = SmallWorks DB Full

Backup Devices
Tape or disk locations can be mapped to a

backup device. A backup device is an alias to the disk or tape location. The only real advantage of backup devices is that they make the syntax of the backup command simpler. However, because the backup devices are usually created once to hold many backups, the device name will typically be less descriptive than is usually desired. The following example shows how to create a

--Create a device for SmallWorks database backups sp_addumpdevice Disk, SmallWorksDevice, C:\SQLBackups\SmallWorks.BAK; --Backup the SmallWorks database to the new device BACKUP DATABASE SmallWorks TO SmallWorksDevice WITH DESCRIPTION = SmallWorks Full Backup;
The sp_addumpdevice stored procedure does

not verify the existence of the target folder. When using this procedure, to avoid errors, be very sure that the folder exists and that you spelled it correctly before attempting to send a

 A more foolproof method of creating backup

devices is by using Management Studio. To do this, expand the Server Objects node in the Object Explorer of Management Studio, right-click Backup Devices, and select New Backup Device The Backup Device window will warn you if the folder specified does not exist.

SQL Server 2008 Backup Types

The scope of a backup of data (a data backup) can be a whole database, a partial database, or a set of files or filegroups. For each of these, SQL Server supports full and differential backups:

Full Backup
Simply backs up all the data in the database and records all database file locations.
SQL Server logs the beginning of a Full database backup in the transaction log, and then records

all modifications made to the database for the duration of the backup in the transaction log. When all the data pages from the database data files have been transferred to the backup media, SQL Server logs the completion of the backup, and transfers the portion of the transaction log that occurred during the backup to the backup media. Full backups can be used in any recovery model. The advantage of the Full backup is that it is exceptionally simple. However, Full backups take longer than other backup methods, and typically result in the same unchanged data being backed up over and over again, along with the new and updated data.

--Full database backup of SmallWorks BACKUP DATABASE SmallWorks TO DISK = C:\SQLBackups\SmallWorksFull.BAK WITH DESCRIPTION = SmallWorks FULL Backup;

Differential Backup
Differential backups are used to back up only the data that has changed since the last Full

backup. Like the Full backup, the Differential backup also consists of the portion of the transaction log that contains database modifications that occurred during the backup. Because Differential backups only contain the extents of data files that have changed since the last Full backup, they take less time to execute than Full backups. The Differential backup is available regardless of the database recovery model, and requires a Full database backup.
--Differential database backup of SmallWorks BACKUP DATABASE SmallWorks TO DISK = C:\SQLBackups\SmallWorksDiff.BAK WITH DIFFERENTIAL, DESCRIPTION = SmallWorks Differential Backup;

File/Filegroup Backup
When a database is divided across many files and filegroups, these files and filegroups can

be backed up individually. This type of backup is particularly useful for very large databases. File and Filegroup backups work similarly as Full and Differential backups in that the data pages of the file, and then all transactions made against the file or filegroup, are added to the backup media. The following is an example of a command that executes a backup of the SWUserData1 filegroup: --Backup of the SWUserData1 User-Defined Filegroup BACKUP DATABASE SmallWorks FILEGROUP = SWUserData1 TO DISK = C:\SQLBackups\SmallWorksUserData1FG.BAK WITH DESCRIPTION = SmallWorks SWUserData1 Filegroup Backup;

File/Filegroup with Differential

An additional option available when backing up files or filegroups is the ability to perform a

Differential File or Filegroup backup. This option works exactly like the typical Differential backup; only the changes to the file or filegroup since the last complete File or Filegroup backup are captured, as well as any changes to the files during the backup.
--Differential Filegroup Backup of the SWUserData1 User-Defined Filegroup BACKUP DATABASE SmallWorks FILEGROUP = SWUserData1 TO DISK = C:\SQLBackups\SmallWorksUserData1FGDIFF.BAK WITH DIFFERENTIAL, DESCRIPTION = SmallWorks Filegroup Differential Backup;
File and Filegroup backups are only available if the database is in Full or Bulk-Logged

recovery model, with one exception.

 Transaction Log backup

o Pure Log Backup o Bulk Log back up o Tail Log Back up

Partial Backup Copy Backup

Backup Options
backups can be sent to a disk.

Another possibility for backup destinations is to

send the backups to multiple destinations at the same time. The multiple destinations can be configured as a stripe of the backup or a mirror.

Backup Stripe: Striping a backup across multiple devices may save time in the backup process, because multiple physical devices are being written to simultaneously. To create a backup stripe, simply add multiple destinations to the BACKUP command,
BACKUP DATABASE SmallWorks TO DISK=C:\StripedBackupsA\SmallWorksStripe1.bak , DISK=C:\StripedBackupsB\SmallWorksStripe2.bak , DISK=C:\StripedBackupsC\SmallWorksStripe3.bak WITH DESCRIPTION = Striped Backup;

Mirrored Backup
SQL Server 2008 provides the built-in ability to mirror database backups. However, the mirror

option is only available with the Enterprise and Developer editions of SQL Server 2008. The following code demonstrates how to back up a database to one destination, and mirror the entire backup to another destination simultaneously. The WITH FORMAT option is required to create a new mirrored backup set. BACKUP DATABASE SmallWorks TO DISK=C:\MirroredBackupsA\SmallWorksMirror1.bak MIRROR TO DISK=C:\MirroredBackupsB\SmallWorksMirror2.bak WITH FORMAT, DESCRIPTION = Mirrored Backup;

Backup Strategies
Full Backup Only

if the database is backed up every day at 1:00 a.m. and there is a database failure any time before 1:00 a.m., the most recent restore point will be 1:00 a.m. of the previous day. For small databases with very few daily updates, this may be acceptable.

 Full Backup with Differential

Like the Full backup strategy, the Full Backup with Differential strategy is generally limited to databases configured in Simple recovery model, because it does not provide for any management of the transaction log. However, the addition of a periodic Differential backup makes this backup strategy more appropriate for slightly larger changing databases where the management of a transaction log is not desired. Because only data modified since the last Full backup is copied to the backup media, the periodic Differential backups will be smaller when compared to the Full backups and will take less time to execute.

 Full Backup with Transaction Log

In the event of a database failure, the database can be restored up to the moment of failure by performing periodic Transaction Log backups between Full backups.

Full and Differential Backup with Transaction Log The disadvantage of performing several Transaction Log backups between Full backups is that, to restore a database, the Full backup and all the logs must be sequentially restored. To minimize this issue, a Differential backup can be performed to capture all the changes to the database since the last full backup

File and Filegroup Backup

Database data files and filegroups can be backed up and restored individually, enabling the

administrator to avoid a time-consuming and unnecessary restore of a large database in its entirety. This method is especially useful if some of the filegroups contain read-only data. These filegroups can be backed up once, and then recovered later in the event of a failure with no loss of interim data. For example, a production database is comprised of four 25GB filegroups. One of the filegroups contains tables that are updated about once every three months. The other three contain data that is updated on a regular basis. The first filegroup can be configured as read-only and backed up. The remaining three can be backed up on a rotating basis, interspersed with Transaction Log backups

Filegroup with Differential If the filegroup strategy still backs up too much data that does not change, a File or Filegroup backup can be combined with a File or Filegroup Differential backup. This way, only the changes to the respective file or filegroup will be backed up.

 Partial Backup

the Partial backup backs up the Primary filegroup and all READ_WRITE configured filegroups by default

Restoring Databases
The critical issue in most restoration plans is the sequence of backups. Restore Process The restore process is made up of three phases: The Data Copy phase, where data pages are copied from the backup media to the data file(s) The Redo phase, where the record of committed transactions are restored from a log backup or the log portion of a database backup The Undo phase, where uncommitted transactions are rolled back from a log backup or the log portion of a database backup

 The Data Copy and Redo phases can span multiple backups.

For example, a database is backed up with a Full backup, followed by a

Differential backup and then a Transaction Log backup. To restore the database to its most recent state would require restoring the Full backup, then the Differential backup as part of the Data Copy phase. The log portion of the Differential backup would begin the Redo phase, followed by the committed transactions in the Transaction Log backup. After all committed transactions are reapplied to the database, the Undo phase begins, where all uncommitted transactions are rolled back.

 Each phase is linked to the next. If any backup is

missing from the sequence, the process stops at the end of the backup preceding the missing sequence.

Database Restore Preparation

1. Isolate the database by placing it in SINGLE_USER mode (if it is accessible). 2. Back up the tail of the transaction log if in Full or Bulk-Logged recovery mode. This captures all the recent activity. 3. Gather information about all the backups that are required to restore the database to the most recent consistent state.

Isolate the Database Isolating the database is typically required because, when restoring a database that is still online, SQL Server essentially drops and then re-creates the database from the backup media. A database cannot be dropped if someone is connected to it. Capture Recent Activity Backing up the tail of the log ensures that the most recent transactions (since the last backup) are recorded and recoverable.

Important
Although system databases do need to be backed up, the strategy for backing them up is very straightforward and is typically confined to Full database backups only. This is because system databases do not change as often and are typically quite small.

difference
Restoring a database is copying the physical files

from a backup medium (disk or tape) to the appropriate file locations for database operation. Recovery is process of updating database files restored from backup w/changes made to the database since backup, typically using redo log files.(Restored backup files + changes = Recovery)

RESTORE DATABASE database_name

FILE The RESTORE DATABASE database_name statement can be followed by the logical name of a database data file so that only that file is restored from the backup media. A file can be specified for FULL, FILE, and FILEGROUP backups.
RESTORE DATABASE SmallWorks FILE = SmallWorks_Data2 FROM DISK = C:\SQLBackups\SmallWorksFull.BAK

FILEGROUP The RESTORE DATABASE database_name statement can also be followed by the name of a database filegroup so that only that filegroup is restored from the backup media. A filegroup can be specified for FULL and FILEGROUP backups.
RESTORE DATABASE SmallWorks FILEGROUP = SWUserData2 FROM DISK = C:\SQLBackups\SmallWorksFull.BAK

READ_WRITE_FILEGROUPS The READ_WRITE_FILEGROUPS option only restores those filegroups in the database not marked as read-only. This option can be used with Full and Partial backups.
RESTORE DATABASE SmallWorks READ_WRITE_FILEGROUPS FROM DISK = C:\SQLBackups\SmallWorksFull.BAK;

RESTORE LOG database_name The RESTORE LOG statement specifies that the restore process is for a database transaction log.
RESTORE LOG SmallWorks FROM DISK = C:\SQLBackups\SmallWorksLog.BAK;

RECOVERY | NORECOVERY When restoring a database from a sequence of backups, all but the last backup must be restored with the NORECOVERY option. This allows for additional backups to be applied to the database. The RECOVERY option completes the Redo/Undo phase of restoration, as previously described, making the database available to client connections and preventing further restore operations. WITH RECOVERY is the default setting, so it is important to override it until the final backup is being applied. When restoring a sequence of backups such as a Full backup and a series of Transaction Log backups, the Undo phase and database recovery will have to be delayed so that each additional backup can be restored. Once a database has been recovered, no additional

RESTORE DATABASE SmallWorks FROM DISK = C:\SQLBackups\SmallWorksFull.BAK WITH NORECOVERY;

RESTORE LOG SmallWorks FROM DISK = C:\SQLBackups\SmallWorksTailLog.BAK WITH RECOVERY;

Restoring User Databases

Full Restore The periodic Full backup of a database is the simplest of all backup strategies and is also a very simple restore strategy. If the database needs to be restored, simply find the most recent Full backup and use it to restore the database.

Full with Differential Restore Differential backups require a Full backup to be applied prior to the restoration of the Differential. Figure illustrates a failure of the SmallWorks database at 9:00 a.m. on Wednesday. Because a Differential backup was completed at 12:02 a.m. on Wednesday, the Differential backup on Tuesday can be ignored. The recovery process is the Monday Full backup, followed by the Wednesday Differential backup.

Full with Transaction Log Restore

Full and Differential with Transaction Log Restore When using both Differential and Transaction Log backups to capture changes to the database, the important thing to remember is sequence. Each Differential backup contains the changes made to the database that were recorded in transaction logs during the interval between the Full backup and any Differential backup completed.

 File and Filegroup Restore

Partial Restore

The Partial restore process is very similar to the File/Filegroup restoration process. The significant difference is that Partial restores always include the Primary filegroup.

Point-in-time restore: Point-in-time database restore operations are useful to restore a database to a point just prior to data corruption because of a malicious or accidental modification of data. For example, an accidental update to the SmallWorks database occurs at 3:00 p.m., but is not detected until 6:15 p.m. A scheduled database backup was completed at 4:00 p.m. and a scheduled Transaction Log backup occurred at 5:00 p.m. To restore the database to just before the accidental update, a point-in-time restore is used. The sequence of events to restore the database is as follows:
RESTORE DATABASE SmallWorks FROM DISK = C:\SQLBackups\SmallWorksFull1600.BAK WITH STOPAT = 06/05/2006 14:59:00 ,NORECOVERY; RESTORE LOG SmallWorks FROM DISK = C:\SQLBackups\SmallWorksLog1700.BAK WITH STOPAT = 06/05/2006 14:59:00 ,RECOVERY;

Database Snapshots
A snapshot is a point-in-time, static, read-only

view of a database. Reversing the effect of database modifications.

 Sunday 09 pm : Database is backed up. and is running fine. Monday 08 am : Went down / crashed due to some reason. To bring up the database, we have 2 options: 1. Simple Restore : copying files from backup taken sunday night

and open the database. Here, we loose all the changes that are done since sunday night. 2. Restore and Recovery: Copying files from backup taken sunday night and applying all the archivelog and redo log files to bring up the database to the point of failure. Here you dont loose the changes done until Monday o8 am. Restore : copying files from the backup overwriting the existing database files Recovery: applying the changes to the database till point of failure. these changes are recorded in redolog and archivelog ( which are the backups of redolog) files.