CoCreative Solutions

Overview of DR and HA

How Microsoft SQL Server caters to

Disaster Recovery (DR) High Availability (HA)

Paul Paiva CoCreative Solutions

, LLC

www.CoCreativeSolutions.com PaulP@CoCreativeSolutions.com

http://paulpaivasql.blogspot.com

April 19, 2011

CoCreative Solutions

DR vs. HA

Disaster Recovery
If there is a natural or human-induced disaster, can we recover?

High Availability
How much downtime is acceptable? What is the customers SLA?

CoCreative Solutions

3 Recovery Models

Backups can be configured with three different recovery models

Simple Full Bulk-logged

See: Database Properties, Options tab

CoCreative Solutions

DR 3 Backup Models
1. Simple
Advantages
No need for log backups. Easier to manage, less files.

Disadvantages
Can recover only to the last backup.

Appropriate if
There is a way to manually re-enter data to point of failure. Data changes infrequently.

CoCreative Solutions

DR Backup Models

2. Full
Can recover to the last transaction log
Point-in-time restore is possible.
to last Time, Mark, or Log Sequence Number (LSN)

Backup Transaction Logs periodically

Hourly, every 15 minutes, etc.

CoCreative Solutions

DR Backup Models

Differential
Only backups portions of database/file that have changed since the last full backup. Advantages
File sizes are smaller No need to apply all the transaction logs.

CoCreative Solutions

Point-in-Time Restore

From SQL Server BOL

CoCreative Solutions

DR Backup Models

3. Bulk Logged
Can recover to the last transaction log
Point-in-time is not supported

CoCreative Solutions

Backup Syntax

CoCreative Solutions
Script a Simple Backup for All Databases

CoCreative Solutions

Other Backup Options

Copy_Only
Does not interrupt the sequence of transaction log backups

Compression
SQL 2008, enterprise edition SQL 2008 R2, all editions

File or Filegroup only

Useful when only one or more tables need to be safeguarded.

Snapshots

CoCreative Solutions

High Availability

How much downtime is acceptable?

CoCreative Solutions

HA - Methods

Replication
Peer-to-Peer (transactional) Publisher/Subscriber model Allows only certain objects to be replicated Object schema must be identical Schema changes require system to be quiesced. Some overhead: distributor needs to be configured and maintained. Data conflicts can be introduced and need to be resolved.

CoCreative Solutions

HA - Methods

Failover Clustering
for whole SQL Instance (all databases are safeguarded) Nodes need to be in close proximity to each other Auto failover Does not protect against disk failure
Nodes share the same disk. Disk files on RAID

Arguably the best method for most stringent requirements

Most expensive, most work involved to configure, more hardware required.

CoCreative Solutions

HA - Methods

Database Mirroring
One database is safeguarded (at-a-time) Consists of a Principal and Mirror database Synchronous
Safest the mirror is always in synch. Auto-failover is possible by using a 3rd machine, a Witness

Asynchronous
allows faster speeds, however some latency may develop

CoCreative Solutions

HA - Methods

Log Shipping
One database (at-a-time) is safeguarded Very simple, easiest to maintain Primary and backups can be separated by far distances.

CoCreative Solutions

Fallback Server

A human-introduced error will immediately propagate to the other cluster nodes or mirror nodes. Remedy: Lagging Fallback Server
Configure a fallback server to receive transactional logs Make it lag the production database

CoCreative Solutions

Summary

DR
As a rule, use FULL backup model Store copy of back ups off site

HA
Clustering (high cost)
auto failover

Mirroring (per database)

auto failover

Log Shipping (per database)

Can be configured to have a lag

Replication (per object)

CoCreative Solutions

Introduction to

DR and HA Thanks for your time and attention! Questions?

Paul Paiva CoCreative Solutions

, LLC

www.CoCreativeSolutions.com PaulP@CoCreativeSolutions.com http://paulpaivasql.blogspot.com April 19, 2011