Chapter Four

SQL Backup and Recovery

What is Backup?
 Copies the data or log records from a SQL Server database or its transaction log to a backup device,
such as a disk, to create a data backup or log backup.
 A copy of SQL Server data that can be used to restore and recover the data after a failure. A backup of
SQL Server data is created at the level of a database or one or more of its files or file groups.
 Table-level backups cannot be created. In addition to data backups, the full recovery model requires
creating backups of the transaction log.
Backup device
 A disk or tape device to which SQL Server backups are written and from which they can be restored.
 Backup media one or more tapes or disk files to which one or more backup have been written.
 A set of data files or file groups (a file backup).
 Database backup A backup of a database. Full database backups represent the whole database at the time the backup
finished.
 Differential database backups contain only changes made to the database since its most recent full database backup
stored.
 Differential backup A data backup that is based on the latest full backup of a complete or partial database or a set of
data files or file groups (the differential base) and that contains only the data that has changed since that base.
 Full backup A data backup that contains all the data in a specific database or set of file groups or files.
 Log backup A backup of transaction logs that includes all log records that were not backed up in a previous log
backup. (Full recovery model) recover To return a database to a stable and consistent state.
 Recovery A phase of database startup or of a restore with recovery that brings the database into a transaction-consistent
state.
Recovery mod
• A database property that controls transaction log maintenance on a database. Three recovery models exist:
simple, full, and bulk-logged.
• The recovery model of database determines its backup and restores requirements.
• Restore A multi-phase process that copies all the data and log pages from a specified SQL Server backup
to a specified database, and then rolls forward all the transactions that are logged in the backup by applying
logged changes to bring the data forward in time
Introduction to Backup and Restore Strategies
• Backing up and restoring data must be customized to a particular environment and must work with the
available resources.
• A reliable use of backup and restore for recovery requires a backup and restore strategy.
• A well-designed backup and restore strategy maximizes data availability and minimizes data loss, while
considering your particular business requirements
Impact of the Recovery Model on Backup and Restore
 Backup and restore operations occur within the context of a recovery model.
 Typically a database uses either the simple recovery model or the full recovery model.
 The full recovery model can be supplemented by switching to the bulk-logged recovery model before bulk
operations.
1. Introduction
Transaction - The execution of a program that performs an administrative function by accessing a shared
database, usually on behalf of an on-line user.
Transaction Processing – The technology for building large-scale systems that run transactions
Examples

 Reserve an airline seat.  Verify a credit card sale.

 Buy an airline ticket  Place an order at an
 Get cash from an ATM. E-commerce web site
 Download a video clip  Fire a missile
What Makes Transaction Processing (TP) Hard? • Availability - system must be up all the time
• Atomicity - no partial results • Reliability - system should rarely fail
• Isolation – appears to run transactions serially • Response time - within 1-2 seconds
• Durability – results aren’t lost by a failure • Throughput - thousands of transactions/second

1|P a g e Complied by Muhe Abdureman Advanced Database ETU Adama 2021

 • Scalability - start small, ramp up to Internet-scale • Configurability - for above requirements + low cost
• Distribution - of users and data

Focusing on Recovery
 All database reads/writes are within a transaction
 Transactions have the “ACID” properties
 Atomicity - all or nothing
 Consistency - preserves database integrity
 Isolation - execute as if they were run alone
 Durability - results aren’t lost by a failure
 Recovery subsystem guarantees A & D
 Concurrency control guarantees I
 Application program guarantees C
2. DB Recovery Model
 A database may become inconsistent because of a
 transaction failure (abort)
 database system failure (possibly caused by OS crash)
 media crash (disk-resident data is corrupted)
 The recovery system ensures the database contains exactly those updates produced by committed
transactions. i.e. atomicity and durability, despite failures
Assumptions
 Two-phase locking
 Set a lock before accessing a data item
 Get all locks before releasing any of them
 Implies transactions execute serializably
 Hold write locks until after a transaction commits. Implies:
 Recoverability – Transaction T1 commits after all transactions that T read from, to avoid this
 No cascading aborts – T1 doesn’t read dirty (uncommitted) data.
 Strictness – Don’t overwrite uncommitted data, so abort can be implemented by restoring before images.
 Page-level everything (for now)
– page-granularity locks
– database is a set of pages
– a transaction’s read or write operation operates on an entire page
– we’ll look at record granularity later
Stable Storage
• Write(P) overwrites all of P on the disk
• If Write is unsuccessful, the error might be detected on the next read ...
– e.g. page checksum error => page is corrupted or maybe not
• Write is the only operation that’s atomic with respect to failures and whose successful execution can be
determined by recovery procedures.
The Cache
 Cache is divided into page-sized slots.
 Each slot’s dirty bit tells if the page was updated since it was last written to disk.
 Pin count tells number of pin ops without unpins
 Fetch(P) - read P into a cache slot. Return slot address.
 Flush(P) - If P’s slot is dirty and unpinned, then write it to disk (i.e. return after the disk acks)
 Pin(P) - make P’s slot unflushable. Unpin releases it.
 Deallocate - allow P’s slot to be reused (even if dirty)
The Log
 A sequential file of records describing updates:
 address of updated page
 id of transaction that did the update
 before-image and after-image of the page
 Log records for Commit(Ti) and Abort(Ti)
 Some older systems separated before-images and after-images into separate log files.
 With record granularity operations, short-term locks, called latches, control concurrent record updates to the same
page:
 Fetch(P) read P into cache
 Pin(P) ensure P isn’t flushed
 write lock (P) for two-phase locking
 latch P get exclusive access to P
 update P update P in cache
 log the update to P append it to the log
2|P a g e Complied by Muhe Abdureman Advanced Database ETU Adama 2021
  There’s no deadlock detection for latches.

3. Recovery Manager
 Processes Commit, Abort and Restart
 Commit(T)
 Write T’s updated pages to stable storage atomically, even if the system crashes.
 Abort(T)
 Undo the effects of T’s writes
 Restart = recover from a system failure
 Abort all transactions that were not committed at the time of the failure
 Fix stable storage so it includes all committed writes and no uncommitted ones (so it can be
read by new txns)
Implementing Abort (T)
 If P was not transferred to stable storage, then deallocate its cache slot
 If it was transferred, then P’s before-image must be in stable storage (else you couldn’t undo after a system failure)
 Undo Rule - Do not flush an uncommitted update of P until P’s before-image is stable. (Ensures undo is possible.)
o Write-Ahead Log Protocol - Do not … until P’s before-image is in the log
Avoiding Undo
• Avoid the problem implied by the Undo Rule by never flushing uncommitted updates.
– Avoids stable logging of before-images
– Don’t need to undo updates after a system failure
• A recovery algorithm requires undo if an update of an uncommitted transaction can be flushed.
– Usually called a steal algorithm, because it allows a dirty cache page to be “stolen.”
Implementing Commit(T)
• Commit must be atomic. So it must be implemented by a disk write.
• Suppose T wrote P, T committed, and then the system fails. P must be in stable storage.
• Redo rule - Don’t commit a transaction until the after-images of all pages it wrote are on stable storage (in
the database or log). (Ensures redo is possible.)
• Often called the Force-At-Commit rule
Avoiding Redo
• To avoid redo, flush all of T’s updates to the stable database before it commits. (They must be in stable
storage.)
– Usually called a Force algorithm, because updates are forced to disk before commit.
– It’s easy, because you don’t need stable bookkeeping of after-images
– But it’s inefficient for hot pages.
• Conversely, a recovery algorithm requires redo if a transaction may commit before all of its updates are in
the stable database.
Avoiding Undo and Redo?
 To avoid both undo and redo
o never flush uncommitted updates (to avoid undo), and
o Flush all of T’s updates to the stable database before it commit (to avoid redo).
 Thus, it requires installing all of a transaction’s updates into the stable database in one write to disk
 It can be done, but it isn’t efficient for short transactions and record-level updates.
o We’ll show how in a moment
Implementing Restart
• To recover from a system failure
– Abort transactions that were active at the failure
– For every committed transaction, redo updates that are in the log but not the stable database
– Resume normal processing of transactions
• Idempotent operation - many executions of the operation have the same effect as one execution
• Restart must be idempotent. If it’s interrupted by a failure, then it re-executes from the beginning.
• Restart contributes to unavailability. So make it fast!
4. Log-based Recovery
 Logging is the most popular mechanism for implementing recovery algorithms.
 Write, Commit, and Abort produce log records
 The recovery manager implements
 Commit - by writing a commit record to the log and flushing the log (satisfies the Redo Rule)
 Abort - by using the transaction’s log records to restore before-images

3|P a g e Complied by Muhe Abdureman Advanced Database ETU Adama 2021

  Restart - by scanning the log and undoing and redoing operations as necessary
 Logging replaces random DB I/O by sequential log I/O. Good for TP & Restart performance.
Implementing Commit
 Every commit requires a log flush.
 If you can do K log flushes per second, then K is your maximum transaction throughput
 Group Commit Optimization - when processing commit, if the last log page isn’t full, delay the flush
to give it time to fill
 If there are multiple data managers on a system, then each data mgr must flush its log to commit
o If each data mgr isn’t using its log’s update bandwidth, then a shared log saves log flushes
o A good idea, but rarely supported commercially
Implementing Restart (rev 1)
 Assume undo and redo are required
 Scan the log backwards, starting at the end.
o How do you find the end?
 Construct a commit list and page list during the scan (assuming page level logging)
 Commit(T) record => add T to commit list
 Update record for P by T
o if P is not in the page list then
 add P to the page list
 if T is in the commit list, then redo the update, else undo the update
Checkpoints
 Problem - Prevent Restart from scanning back to the start of the log
 A checkpoint is a procedure to limit the amount of work for Restart
 Commit-consistent checkpointing
 Stop accepting new update, commit, and abort operations
 make list of [active transaction, pointer to last log record]
 flush all dirty pages
 append a checkpoint record to log, which includes the list
 resume normal processing
 Database and log are now mutually consistent

Restart Algorithm (rev 2)

 No need to redo records before last checkpoint, so
o Starting with the last checkpoint, scan forward in the log.
o Redo all update records. Process all aborts.
Maintain list of active transactions (initialized to content of checkpoint record).
o After you’re done scanning, abort all active transactions
 Restart time is proportional to the amount of log after the last checkpoint.
 Reduce restart time by checkpointing frequently.
 Thus, checkpointing must be cheap.
Fuzzy Checkpointing
 Make checkpoints cheap by avoiding synchronized flushing of dirty cache at checkpoint time.
 stop accepting new update, commit, and abort operations
 make a list of all dirty pages in cache
 make list of [active transaction, pointer to last log record]
 append a checkpoint record to log, which includes the list
 resume normal processing
 initiate low priority flush of all dirty pages
 Don’t checkpoint again until all of the last checkpoint’s dirty pages are flushed
 Restart begins at second-to-last (penultimate) checkpoint.
 Checkpoint frequency depends on disk bandwidth
Operation Logging
 Further reduce log size by logging description of an update, not the entire before/after image.
o Only log after-image of an insertion
o Only log fields being updated
 Now Restart can’t blindly redo.
o E.g., it must not insert a record twice

4|P a g e Complied by Muhe Abdureman Advanced Database ETU Adama 2021

 Logging B-Tree Operations
• To split a page
– log records deleted from the first page (for undo)
– log records inserted to the second page (for redo)
– they’re the same records, so long them once!
Shared Disk System
• Two processes cache page P and write-lock different records in P
• Only one process at a time can have write privilege for P
• Use a global lock manager
• After write locking P, refresh the cached copy from disk if another process recently updated it.
• Use a version number on the page and in the lock
• Before unlock(P), process flushes the page to server. Unlock operation includes the new version
number.
User-level Optimizations
• If checkpoint frequency is controllable, then run some experiments
• Partition DB across more disks to reduce restart time (if Restart is multithreaded)
• Increase resources (e.g. cache) available to restart program.
5. Media Failures
 A media failure is the loss of some of stable storage.
 Most disks have MTBF over 10 years
 Still, if you have 10 disks ...
 So shadowed disks are important
o Writes go to both copies. Handshake between Writes to avoid common failure modes (e.g. power failure)
o Service each read from one copy
 To bring up a new shadow
o Copy tracks from good disk to new disk, one at a time
o A Write goes to both disks if the track has been copied
o A read goes to the good disk, until the track is copied
RAID
• Patterson, Gibson, & Katz, SIGMOD 1988
• RAID - redundant array of inexpensive disks
– Use an array of N disks in parallel
– A stripe is an array of the ith block from each disk and which can survive a single-disk failure.
Where to Use Disk Redundancy?
• Preferable for both the DB and log But at least for the log
– in an undo algorithm, it’s the only place that has certain before images
– in a redo algorithm, it’s the only place that has certain after images
• If you don’t shadow the log, it’s a single point of failure
Archiving
 An archive is a database snapshot used for media recovery.
o Load the archive and redo the log
 To take an archive snapshot
o write a start-archive record to the log
o copy the DB to an archive medium
o write an end-archive record to the log
(or simply mark the archive as complete)
 To archive the log, use 2 pairs of shadowed disks.
 Optimization - only archive committed pages and purge undo information from log before archiving
o Each page update sets the bit.
o Archive only copies pages with the bit set, and clears it.
 To reduce media recovery time
o rebuild archive from incremental copies
o partition log to enable fast recovery of a few corrupted pages

5|P a g e Complied by Muhe Abdureman Advanced Database ETU Adama 2021

To back up a database
1. After connecting to the appropriate instance of the Microsoft SQL Server Database Engine, in Object Explorer, click
the server name to expand the server tree.
2. Expand Databases, and depending on the database, either select a user database or expand System Databases and select
a system database.
3. Right-click the database, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.
4. In the Database list box, verify the database name. You can optionally select a different database from the list.
5. You can perform a database backup for any recovery model (FULL, BULK_LOGGED, or SIMPLE).
6. In the Backup type list box, select Full. Note that after creating a full database backup, you can create a differential
database backup; for more information, see SQL Server Management Studio Tutorial.
7. Optionally, you can select Copy Only Backup to create a copy-only backup. A copy-only backup is a SQL Server
backup that is independent of the sequence of conventional SQL Server backups.
8. For Backup component, click Database.
9. Either accepts the default backup set names suggested in the Name text box, or enter a different name for the backup
set.
10. Optionally, in the Description text box, enter a description of the backup set.
11. Specify when the backup set will expire and can be overwritten without explicitly
12. In the Reliability section, optionally check:
o Verify backup when finished.
o Perform checksum before writing to media, and, optionally, Continue on checksum error.
13. If you are backing up to a tape drive (as specified in the Destination section of the General page), the Unload the tape
after backup option is active
14. SQL Server 2008 Enterprise and later supports backup compression.
Benefits of File Backups
File backups offer the following advantages over database backups:
• Using file backups can increase the speed of recovery by letting you restore only damaged files, without restoring the
rest of the database. For example,
 If a database consists of several files that are located on different disks and one disk fails, only the file on the
failed disk has to be restored.
• The damaged file can be quickly restored, and recovery is faster than it would be for an entire database.
• File backups increase flexibility in scheduling and media handling over full database backups, which for very large
databases can become unmanageable.
• The increased flexibility of file or file group backups is also useful for large databases that contain data that has varying
update characteristics.
Disadvantages of File Backups
 The primary disadvantage of file backups compared to full database backups is the additional administrative complexity.
 Backups can be a time-consuming task that might outweigh the space requirements of full database backups.
 A media failure can make a complete database unrecoverable if a damaged file lacks a backup.
Overview of File Backups
 A full file backup backs up all the data in one or more files or file groups.
 Backing up a read-only file or file group is the same for every recovery model.
 the full recovery model, a complete set of full file backups and is the equivalent of a full database backup.
 Only one file backup operation can occur at a time.
Differential Backups
 Backup and restore topic is relevant for all SQL Server databases.
 A differential backup is based on the most recent, previous full data backup.
 A differential backup captures only the data that has changed since that full backup.
 The full backup upon which a differential backup is based is known as the base of the differential.
 Full backups, except for copy-only backups, can serve as the base for a series of differential backups

6|P a g e Complied by Muhe Abdureman Advanced Database ETU Adama 2021