0% found this document useful (0 votes)

1K views

SQL Server Backup and Recovery

This chapter covers topics that every DBA needs to be well-versed in. In this chapter we'll cover the types of SQL Server backups and recovery models, how to develop an efficient backup strategy, and taking backups via SSMS and TSQL. We'll also discuss the fundamentals of restoring and work through restoring a database, collection of databases and an entire server.

Uploaded by

LearnItFirst

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

1K views

SQL Server Backup and Recovery

Uploaded by

LearnItFirst

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 251

SQL Server Backup and Recovery

Presented by Scott Whigham

What We’re Going to Cover

Restoring Databases
Overview

Backup Your Databases

• Overview • Backup • Restoring
of Chapter Strategies User
• Scenario • Backing Databases
Setup Up Your • Restoring
• Types of Databases System
SQL Server • Backing Databases
Backups Up Your
• Recovery SQL Server
Models
Chapter Overview

• Lack of backups can break a company

• As the DBA, it is your responsibility to
create backup and recovery plans and
test those plans
– Perform these tests early and often for any critical
project
Chapter Overview

• This chapter will teach you how to:

– Develop backup plans
– Understand the risks associated with any single
plan
– Take and restore backups
Chapter Overview

• This chapter will not teach you how to:

– Implement Database Mirroring, Log Shipping,
Replication, or Snapshots
– Discuss creating or managing jobs and logs
Next up…

Restoring Databases
Overview

Backup Your Databases

• Before we get too deep, we need a real

world example to use
• For the scenarios in this chapter, you are
the database administrator for
LearnItFirst.com
Scenario Setup

• LIFWeb: Manages online website

– Small-to-medium size (100GB)
– Real-time data and transactions
– Few bulk transactions (indexing only)
– Backup and restore goals:
• ___________________________
• ___________________________
Scenario Setup

• LIFWeb: Manages online website

– Real-time data and transactions
– Few bulk transactions (indexing only)
– Backup and restore goals:
• Be able to restore quickly
• Ensure no lost transactions
• Be able to recover to “point of failure” and “point in
time”
Scenario Setup

• LIFUtility: Internal support

– Very small (100MB)
– Static data (numbers tables, functions, procs)
– No bulk transactions
– Backup and restore goals:
• ___________________________
• ___________________________
Scenario Setup

• LIFUtility: Internal support

– Very small (100MB)
– Static data (numbers tables, functions, procs)
– No bulk transactions
– Backup and restore goals:
• Backup/restore full database only
• Point in time recovery is not important
Scenario Setup

• LIFReporting: OLAP database to

feed SQL Server Analysis Services
– Large (400GB)
– Mainly bulk transactions loaded on weekends
• indexing, text files, XML
– Not Mission Critical
– Backup and restore goals:
• ___________________________
• ___________________________
Scenario Setup

• LIFReporting: OLAP database to

feed SQL Server Analysis Services
– Large (400GB)
– Mainly bulk transactions loaded on weekends
• indexing, text files, XML
– Not Mission Critical
– Backup and restore goals:
• Minimize backup size
• No need for point in time or point of failure recovery
Coming up…

Restoring Databases
Overview

Backup Your Databases

Presented by Scott Whigham

What We’re Going to Cover

Restoring Databases
Overview

Backup Your Databases

• The first thing to know is what you can

back up
– Entire database (all files - data and log)
• Called a “Full” backup
– Log only
• Called a “Transaction Log” backup
– Only the data that has changed since the last Full
backup
• Called a “Differential” backup
– Filegroups
Dispelling Myths

• Dispelling myths
– You do not need to take a database offline to back
it up
– Backups will include open transactions
– All backups include the transaction log
– You cannot just backup a table by default
• “All or nothing”
• One exception: if that table is on a separate filegroup
What We’re Going to Cover

Restoring Databases
Overview

Backup Your Databases

• The next thing to know is what Recovery

Models are
• A database’s recovery model determines
– What you can backup (and subsequently restore)
– How the backup process works
– How often the transaction log is cleared out
Recovery Models

• There are three types of recovery models

– Simple
– Full
– Bulk Logged
• Each has specific scenarios for use
• Can switch between them instantly
Recovery Models

Simple Bulk Full

Can backup transaction log?

Transaction log is “cleared out” automatically?

Transaction log grows until manually cleared out?

Backs up in-progress transactions?

Backs up bulk transactions?

Completely logs bulk transactions?

Supports point in time recovery?

Simple Recovery Model

• The Simple recovery model:

– Automatically clears committed transactions from
the log
• By default, this happens about 1x per minute
• Prevents the log from filling up and auto-growing
– Cannot backup the transaction log directly
Simple Recovery Model

• The Simple recovery model is

appropriate when:
– You do not need “Point in time” recovery
– You want to minimize disk space
– The default for the master, msdb, and tempdb
– Perfect for static, test and development databases
Scenario

• Which of our databases is appropriate for

using the Simple recovery model?
Scenario

• Which of our databases is appropriate for

using the Simple recovery model?
– LIFUtility because it is static and we do not
need point in time recovery
Full Recovery Model

• The Full recovery model:

– Allows you to restore to a specific point in time or
to the point of failure
• “I need to restore everything up until 12:15:35 - that’s
when we know that Scott ran that nasty UPDATE
statement that messed everything up!”

– For this reason, most production databases are

Full recovery databases
• Least risk of losing work!
Full Recovery Model

• The reason that you can restore to a

point in time is that you can restore the
log
– You can only restore to point in time or point of
failure from a transaction log backup, not from a
Full or Differential
Scenario

• Which of our databases is appropriate for

using the Full recovery model?
Scenario

• Which of our databases is appropriate for

using the Full recovery model?
– LIFWeb because it changes constantly and we do
not want to lose any work
In the next video…

Restoring Databases
Overview

Backup Your Databases

Presented by Scott Whigham

In this video…

Restoring Databases
Overview

Backup Your Databases

• The Bulk Logged recovery model:

– Is identical to Full recovery model except when
dealing with bulk operations
Recovery Models

Simple Bulk Full

Can backup transaction log?

Transaction log is “cleared out” automatically?

Transaction log grows until manually cleared out?

Backs up in-progress transactions?

Backs up bulk transactions?

Completely logs bulk transactions?

Supports point in time recovery?

Bulk Operations in SQL Server
2008

• Certain statements and tools are

considered bulk operations
– CREATE INDEX and ALTER INDEX
– SELECT INTO
– BULK INSERT
– OPENROWSET()
– bcp
Bulk Operations in SQL Server
2008

• Bulk operations can be

– Fully logged - transaction is logged first and then
written to the data file
– Minimally logged - minimal information is written
to the log first and then entire transaction is
written directly to data file
Bulk Operations in SQL Server
2008

• In the Full recovery model, ALL

transactions are fully logged
– This means that your bulk
imports/loads/operations are incurring potentially
unnecessary overhead
Bulk Operations in SQL Server
2008

• In the Bulk Logged recovery model, bulk

operations are minimally logged
– No performance overhead associated with logging
means faster performance
• So if Bulk Logged is faster for bulk
operations, why don’t we always use it?
Bulk Logged Recovery Model

• The Bulk Logged recovery model, while

optimized for bulk operations, has a
serious “gotcha”
Simple Bulk Full
Backs up in-progress transactions?

Backs up bulk transactions?

Completely logs bulk transactions?

Supports point in time recovery? * *

The “Gotcha”

• You cannot backup the log if:

1. You are using Bulk Logged recovery model
2. … and the data file is missing
3. … and bulk operations have occurred since the
last backup
Bulk Logged Recovery Model

• Let me recap:
– Bulk Logged and Full recovery models are identical
provided no bulk operations have occurred since
the last backup
– Bulk Logged recovery model may prevent you
from backing up your log
Bulk Logged Recovery Model

• Why? You need to know the architecture

of the transaction log!
– Let’s do that in the next video…
In the next video…

Restoring Databases
Overview

Backup Your Databases

Presented by Scott Whigham

In this video…

Restoring Databases
Overview

Backup Your Databases

• SQL Server uses “write ahead logging”

The Transaction Log, Part 1

• SQL Server allocates space an extent at a

time
– An extent is a collection of eight 8kb pages
The Transaction Log, Part 1

• When you have minimally-logged

transactions, the only thing written to
the log is the extents that were affected
– Detailed row information is not written
The Transaction Log, Part 1

• Demo of a minimally logged transaction

Bulk Logged Recovery Model

• Name two advantages of using the Bulk

Logged recovery model
– _________________________
– _________________________
Bulk Logged Recovery Model

• Name two advantages of using the Bulk

Logged recovery model
– Faster bulk operations/loads
– Minimize log space
– Same protection as Full recovery model unless
bulk operations have occurred
The Transaction Log, Part 1

• However… you do have to pay the price

for the upload at some point
– Detailed row information is not written during
writes to the log thus minimizing overhead and
log space
– Detailed row information is written at log backup!
• Expect your transaction log backups after a bulk
operation to be large and time-consuming
Scenario

• Which of our databases is appropriate for

using the Bulk Logged recovery model?
Scenario

• Which of our databases is appropriate for

using the Bulk Logged recovery model?
– LIFReporting because is loaded primarily
using bulk operations
– However, we likely will use Full recovery model
most of the time and switch to Bulk Logged when
using bulk operations
• Remember that we can switch between them as
needed
Switching Between Recovery
Models

• You can switch between recovery models

as needed
– It is common to use FULL as your production
model and switch to BULK LOGGED only during
bulk operations
– If you switch to SIMPLE, backup the log first
– If you switch from SIMPLE, requires FULL or DIFF
to actually take effect
In the next video… Demo!

Restoring Databases
Overview

Backup Your Databases

Presented by Scott Whigham

In this video…

Restoring Databases
Overview

Backup Your Databases

• Let’s walk through a few backup

strategies using each recovery model
• One caveat: we are not discussing the
“how to” or the “why” of the restore yet
The Basics of Restoring
Databases

• However you need to know a few basics:

– You must always start with a FULL backup
– You may only restore a single DIFFERENTIAL
• Remember that a DIFFERENTIAL contains all changes
since the last FULL backup
• You do not need to restore any log backups taken
before your DIFFERENTIAL
The Basics of Restoring
Databases

• Basics of restoring LOG backups:

– Logs must be restored in sequence
– You cannot skip logs during the restore
– You cannot skip transactions during a restore
– It is possible to restore only part of the last log file
you restore
• Achieves “point in time” and/or “point of failure”
recovery
The Basics of Restoring
Databases

• Basics of restores:
– The final backup you restore will, by default, take
the database through the RECOVERY process and
bring the database ONLINE
• You decide which is the final backup file in your
Transact-SQL code
– Any open transactions in the database will be
rolled back during the RECOVERY process
The Basics of Restoring
Databases

• One final wrinkle:

– In the FULL and BULK LOGGED recovery model,
you can back up the transaction log even if the
data file is corrupt/suspect/missing
• The only exception is when using BULK LOGGED
recovery model and a bulk operation has occurred
since the last backup
– This is how to do “point of failure” recovery!
The Basics of Restoring
Databases

• Reminder: we will discuss all of this in

detail later in the chapter
The Basics of Restoring
Databases

• Example restore:
– FULL backup: from Monday: 0800
– LOG backups: Monday: 0900, 1000, 1100
– DIFF backup: Monday 1200
– LOG backups: Monday: 1300, 1400, 1500
The Basics of Restoring
Databases

• Example restore (cont.):

– At 1430, user “Steve” notifies you that a recently
applied application hotfix has “messed up the
whole database”
• You: “Okay, Steve - when was the hotfix applied?”
• Steve: “We’re not exactly sure - sometime around
12:30”
– You and your team decide to restore up through
1220 (i.e. “point in time” restore)
The Basics of Restoring
Databases

• Example restore (cont.):

– What is your strategy to restore up through 1220?
• Step 1: _____________________________
• Step 2: _____________________________
• Step 3: _____________________________
The Basics of Restoring
Databases

• Example restore (cont.):

– What is your strategy to restore up through 1220?
• Step 1: Restore the most recent FULL
• Step 2: Since the DIFF occurred before the stop time of
1220, restore the most recent DIFFERENTIAL
• Step 3: Restore the 1300 LOG backup but tell SQL
Server to STOP AT 1220
The Basics of Restoring
Databases

• Example restore (cont.):

– Since your last transaction in the restored
database occurred at 1220, what happened to all
transactions after 1220? ___________________
– What happened to any open transactions that
were open as of 1220? _____________________
The Basics of Restoring
Databases

• Example restore (cont.):

– Since your last transaction in the restored
database occurred at 1220, what happened to all
transactions after 1220? Never occurred so “lost”
– What happened to any open transactions that
were open as of 1220? Rolled back in RECOVERY
Confused?

• It’s okay if you did not fully understand

the scenario
• We will thoroughly review restores
including how to STOP AT a specific time
later in this chapter
SQL Server Backup and Recovery

Presented by Scott Whigham

73
In this video…

Restoring Databases
Overview

Backup Your Databases

• Let’s walk through backup strategies and

restore scenarios
• How do we determine the optimal
backup strategy? What factors do we
have to consider? ________________________________
________________________________
________________________________
________________________________
________________________________
________________________________
Determining your backup
strategy

• Factors to consider:
1. Size of database
2. Time it takes for each backup type to complete
3. How much “drag” backups place on the system
4. How much disk space our backups consume
5. Where to put the backups?
6. How much “loss” is acceptable
7. How much downtime is acceptable
Factors to consider

1. Size of database
– Large databases are problematic:
• Backup time can be hours and hours
– Therefore the restore time can be hours and hours
• Backup file sizes are huge
– In SQL Server 2008 Enterprise Edition, backup files can be
compressed (more on this later)
• Since the backups are so massive, they have an impact
on system performance
– Smaller and mid-size databases do not have as
much to worry about
Factors to consider

2. Time it takes for each backup type to

complete
– Some sites have downtime - they work business
hours and therefore full system backups can occur
during “off” hours with no impact
– Many sites require maintenance windows to
perform full system backups
• Large database backups often do not “fit” your
window!
Factors to consider

3. How much “drag” backups place on

the system
– A rule of thumb for most scenarios/databases:
• FULL backups often have the most performance impact
• DIFFERENTIAL backups have the next-most
performance impact
• LOG files, if taken often, will have the least impact
– This does not cover all situations
Factors to consider

4. How much disk space our backups

consume
– By default, SQL Server will do no compression on
backups
• Large databases means large backups
• A SQL Server backup only contains the data, not the
“empty” pages
– If you have a 100GB database with only 10GB of data, your
FULL backup will be ~10GB
– SQL Server 2008 Enterprise has the option to
compress your backups (more on this later)
Factors to consider

5. Where to put the backups

– You can backup to:
• Disk - local and remote
• Tape - local only
– Disks are fast and tapes are slow
– Often the strategy is:
• Backup to local or network disk
• Copy disk copy to tape
• Move/rotate tape offsite
• Delete disk backup according to a schedule
Factors to consider

5. Where to put the backups (cont.)

– Backing up across a network often adds overhead
• If time is a problem, backup local and do a network file
copy later
– Do not store backups on same disks as data or log
files
• For performance reasons
• For recovery reasons (more on this later)
Factors to consider

6. How much “loss” is acceptable

– Strange factor, eh?
– All backup strategies want to minimize data loss
• Impossible to completely prevent the possibility that
data loss can occur
• Saying that “Data loss is impossible” is akin to saying,
“My network is so secure no could ever hack into it”
– One technique for minimizing data loss is taking
frequent backups
• Some sites take LOG backups every 10 minutes
Factors to consider

6. How much “loss” is acceptable (cont.)

– Backups are not the only strategy in play
– High Availability solutions such as Database
Mirroring, Log Shipping, and Replication are
options we will discuss in a future chapter
Factors to consider

7. How much downtime is acceptable

– All backup strategies want to minimize downtime
• Just like with data loss, it is impossible to completely
prevent the possibility that downtime can occur
– High availability solutions (including clustering)
offer protection against downtime
Factors to consider

7. How much downtime is acceptable (cont.)

– If you do have to completely restore a database, “It
takes as long as it takes”
• A 1TB FULL backup is going to take a long time to restore…
– There are strategies that minimize restore time:
• Frequent DIFFERENTIAL backups minimize the number of
LOG backups that have to be restored, for example
• Certain software packages minimize backup and restore
times
• SQL Server 2008 Enterprise Edition includes a feature called
Fast Recovery
Factors to consider

7. How much downtime is acceptable (cont.)

– SQL Server 2008 Enterprise Edition includes a
feature called Fast Recovery
• This allows users to access the database before the
restore has rolled back uncommitted transactions (i.e.
before the Undo phase of the restore has completed)
Determining your backup
strategy

• The challenge is:

“How do we create a backup strategy that

protects us from data loss while also ensuring
minimal downtime during a restore?”
Determining your backup
strategy

• For a great article on specifically how the

restore process works, visit
http://msdn.microsoft.com/library/ms191455.aspx

• Article: “Understanding How Restore and

Backups Work in SQL Server”
SQL Server Backup and Recovery

Presented by Scott Whigham

90
In this video…

Restoring Databases
Overview

Backup Your Databases

• Remember our three databases:

– LIFWeb: Manages online website
• Small-to-medium size (100GB)
• Full recovery model
– LIFUtility: Internal support
• Very small (100MB)
• Simple recovery model
– LIFReporting: OLAP database to feed SQL Server
Analysis Services
• Large (400GB)
• Full recovery model and switch to Bulk Logged when using
bulk operations
Example #1

Backup Strategy:
• Full backups on Saturdays at 2300

Database: LIFUtility
Recovery model: SIMPLE

• If a problem occurs on Friday at 1200,

can you back up the log so that you can
achieve “point of failure” recovery?
Explain your answer
– ______________________________________________
Example #1

Backup Strategy:
• Full backups on Saturdays at 2300

Database: LIFUtility
Recovery model: SIMPLE

• If a problem occurs on Friday at 1200,

can you back up the log so that you can
achieve “point of failure” recovery?
Explain your answer
– No - Simple recovery model does not allow log backups
Example #2

Backup Strategy:
• Full backups on Saturdays at 2300

Database: LIFUtility
Recovery model: SIMPLE

• Since you cannot backup the log, what is

your restore sequence?
– ______________________________________________
Example #2

Backup Strategy:
• Full backups on Saturdays at 2300

Database: LIFUtility
Recovery model: SIMPLE

• Since you cannot backup the log, what is

your restore sequence?
– Restore the FULL backup from Saturday
– Any data added or modified after Saturday night’s backup
will be lost
Backup Strategy

• Are there any situations in which this is

acceptable?
– Read-only databases
– Databases whose updates occur on Saturday
mornings only
– Test databases
– “Junk” databases
Backup Strategy

• What are some strategies to employ if

that much potential data loss is not
acceptable?
– More frequent backups
– Changing the recovery model
– Adding high availability options
Backup Strategy

• What are some other strategies to

employ if that much potential data loss is
not acceptable? (cont.)
– More frequent backups
– Changing the recovery model
– Adding high availability options
Example #3

Backup Strategy:
• Full backups on Saturdays at 2300
• Differential backup Wednesday at
2300
Database: LIFUtility
Recovery model: SIMPLE

• How does adding in differential backups

each night change your restore
sequence?
– ______________________________________________
Example #3

Backup Strategy:
• Full backups on Saturdays at 2300
• Differential backup Wednesday at
2300
Database: LIFUtility
Recovery model: SIMPLE

• How does adding in differential backups

each night change your restore
sequence?
– Step 1: Restore the FULL from Saturday
– Step 2: Restore Wednesday night’s DIFFERENTIAL
– Any data added or modified after Wednesday night’s
backup will be lost
In the next video…

• What are some other strategies to

employ if that much potential data loss is
not acceptable? (cont.)
– More frequent backups
– Changing the recovery model
– Adding high availability options
SQL Server Backup and Recovery

Presented by Scott Whigham

103
In this video…

Restoring Databases
Overview

Backup Your Databases

• What are some other strategies to

employ if that much potential data loss is
not acceptable? (cont.)
– More frequent backups
– Changing the recovery model
– Adding high availability options
Simple Recovery Model

• Simple recovery model has a huge “hole”:

– You cannot perform a “point of failure” restore
– Why?
• You cannot backup the transaction log
• You cannot restore only part of a FULL or DIFFERENTIAL
• You can restore only part of a LOG
Crash Procedure for Simple
Recovery Model

• Your restore sequence in Simple recovery

model is:
• Step 1: Restore your most recent FULL backup
• Step 2: Restore your most recent DIFFERENTIAL (if
available)
• Any changes after this will be lost
Simple Recovery Model

• Let’s take a look at what the Pros and

Cons are when we change from Simple to
Full recovery model
Example #1

Backup Strategy:
• Full backups on Saturdays at 2300
• Differential backups each day at
2300
Database: LIFUtility
Recovery model: FULL

• In this scenario, a “mistake” is identified

at 1200 on Friday and tracked back to a
hotfix installation at 1130 on Friday. How
does changing the recovery model
change your restore sequence?
– ______________________________________________
Full Recovery Model

• Remember that the full recovery model

allows you to backup your transaction log
– This is critical to remember during a crisis
– Do not make the mistake of “forging ahead” with
a restore before taking a backup!
Full Recovery Model

• Also remember that you can restore only

part of your last transaction log backup
– We can stop at 1129 to ensure minimal data loss!
Example #1

Backup Strategy:
• Full backups on Saturdays at 2300
• Differential backups each day at
2300
Database: LIFUtility
Recovery model: FULL

• Step 1: Backup the current log

• Step 2: Restore Saturday’s FULL
• Step 3: Restore Thursday’s DIFF
• Step 4: Restore the log but tell it to stop at 1129
• All changes after 1129 will be lost
• Any open transactions as of 1129 will be rolled
back
Backup Strategy

• Question #1:
– What would happen if we accidently
forgot to take the log backup in Step
1?
• We would lose all changes since the DIFF
Backup Strategy

• Question #2:
– What would happen if the disk(s)
holding the data file crashed during
the backup of the log?
• Remember that we can still backup the
log because changes are written to the
log first, and then to the data file
– This is a primary function of the transaction
log
Backup Strategy

• Question #3:
– What would happen if the disk(s)
holding the transaction log crashed
during the backup of the log?
• We would lose all changes since the DIFF
Be Careful!

• Question 3 highlights a real problem:

– If you do not backup the log frequently, you are at
risk of losing all data since the last backup
• How do we mitigate this problem?
– More frequent backups
– Redundant disks
In the next video…

• We’ll cover more strategies and issues for

the FULL recovery model
SQL Server Backup and Recovery

Presented by Scott Whigham

118
In this video…

Restoring Databases
Overview

Backup Your Databases

• Let’s take a look at a final example

– This is a more likely scenario for a database with
active changes (like LIFWeb)
Example #1

Backup Strategy:
• Full backups on Saturdays at 2300
• Differentials each day at 2300
• Log backups each hour
Database: LIFWeb
Recovery model: FULL

• Same scenario: a “mistake” is identified

at 1200 on Friday and tracked back to a
hotfix installation at 1130 on Friday. What
is your restore sequence?
– ______________________________________________
Example #1

Backup Strategy:
• Full backups on Saturdays at 2300
• Differentials each day at 2300
• Log backups each hour
Database: LIFWeb
Recovery model: FULL

• Step 1: Backup the log

• Step 2: Restore Saturday’s FULL
• Step 3: Restore Thursday’s DIFF
• Step 4: Restore all log backups that have
occurred since Thursday’s DIFF and stop
at 1129 in the log backup from Step 1
Reminders

• You only restore the most recent

DIFFERENTIAL
– This is critical to understand for performance
reasons
• Restoring 300+ log files takes a long time whereas
restore a single DIFF backup can be quite fast
Reminders (cont.)

• You will likely have a large number of log

files
– Do not lose them - you cannot skip logs during a
restore!
– Be cautious about who (or what) you allow to take
log backups and manage the files
– Keep redundant copies
• Backup to disk and then copy to tape
Remember our strategy:

Backup Strategy:
• Full backups on Saturdays at 2300
• Differentials each day at 2300
• Log backups each hour
Database: LIFWeb
Recovery model: FULL

Day Type Filename

Saturday FULL LIFWeb_Full_20100306.bak

Sunday - LOG LIFWeb_Log_20100307_0000.bak

Sunday - LOG LIFWeb_Log_20100307_0100.bak

Sunday - LOG LIFWeb_Log_20100307_0200.bak

(log backups each hour = 23 log backup files per day)

Sunday - DIFF LIFWeb_Diff_20100307.bak

Differentials

• It is possible to only use FULL

and LOG backups
– If you lose your DIFF backups, you
can simply use the LOGs instead
Differentials

• Each DIFF contains all changes

since the last FULL backup
– Prepare that your DIFFs will take
longer and longer (and be larger
and larger) as you get farther away
from the FULL backup
• Saturday: FULL
• Sunday: Diff (100MB)
• Monday: Diff (200MB)
Differentials

• Example of a 1GB/day delta:

Day Type Size in in GB
Saturday FULL 300
Sunday DIFF 1
Monday DIFF 2
Tuesday DIFF 3
Wednesday FULL 304
Thursday DIFF 1
Friday DIFF 2
Crash Procedure for Full
Recovery Model

• Restore sequence for Full recovery model:

• Step 1: Backup your current transaction log
• Step 2: Restore your most recent FULL backup
• Step 3: Restore your most recent DIFFERENTIAL (if available)
• Step 4: Restore all transaction log backups taken since the
last FULL or DIFFERENTIAL in sequence
– If you follow these steps, you will restore to “point of
failure”
In the next video…

• How changing to BULK LOGGED recovery

model affects your risk
SQL Server Backup and Recovery

Presented by Scott Whigham

131
In this video…

Restoring Databases
Overview

Backup Your Databases

• Okay - the final one: Bulk Logged

– This is a more likely scenario for a database with
bulk operations like LIFReporting
– Remember that BULK LOGGED is identical to FULL
except when bulk operations occur
Example #1