1. Designing a Data Recovery (and Backup) Solution
by Brandie Tarvin
MCITPDBA, MCTS, MCDBA, MCSA

2. What is Recovery?
The process of restoring records, objects, databases, or servers in cases of disaster.
Disaster is not limited to natural disasters such as fire, flood, hurricane, or tornado. It can include network, hardware, and database failures.

3. But I Already have a Backup Design
What business considerations did you take into account when designing the backup?
Do you have, or understand, your SLAs?
Did your BU agree to the SLAs?
Have you rehearsed disaster recovery scenarios?
SLA – Service Level Agreement, a contract between a vendor and a customer stating expected dates and times of service. For DBAs, or any server-support tech, an SLA is between her and the database users. How much downtime can the users expect if the database fails? Was this ever discussed? What databases will be up and when?
Just because the DBA team has an SLA in events of disaster, does not mean the Business Unit agreed to said downtime. Nor does it mean they will accept the downtime when it happens. Make sure this is discussed, the BU concerns addressed, and both parties agree to the SLA before finalizing a recovery strategy.

4. Things to Consider How large is your database?
How much downtime can the business afford?
What is the cost of downtime?
How important is it to never lose a change?
How easy is it to re-create the data?
What are the critical production periods?
When is the heaviest database use (business hours)?
What hardware do you have available for recovery options?
Who will be supporting the servers / databases?
How will database data be Inserted / Updated?
Where will you be restoring from?
Database size – The larger the db, the longer regular Full backups will take. With a large database, consider options such as Filegroup backups, Partial backups, and Differential backups combined with the occasional Full backup.
Downtime – A consideration when deciding what types of backups, and Recovery Models, to use because certain backup strategies take longer to recover than others. A Full backup in Simple Recovery mode is the fastest restore because you only have one restore to do.
Cost – Is a very important consideration for the boss. When you need to get buy in for your backup and recovery strategy, couching the decision in terms of dollars will help the business unit buy into the SLA. It will also help you determine which database is most important to the company.
Never losing changes / Ease of data recreation – Very important for Recovery Model decisions. Full, Bulk-Logged, or Simple? And do you or do you not need a Transaction Log backup? Point in Time Recoveries for never losing a bit of information. Also, consider availability models here. Do you have a Mirror or Cluster? What about Log Shipping or Replication? None of these count as valid backup / recovery strategies, but they can affect your decision making process, so keep them in mind.
Critical Production Periods – Month end? Year / Quarter end? When is the database / server absolutely required to be up without any hiccups?
Heaviest database use – What are the company’s real business hours, not the ones they post but the ones where business is actually happening? (Think East Coast company with West Coast customers that have web access. What about international customers with web access?)
Hardware – RAID, SAN, NAS? Number of SAN spindles? Physical versus logical disk drives? How many drives can you split your database files across? What about the above availability models?
Support – How “simple” does the recovery have to be for the person supporting it? If the server(s) went down tomorrow, would the support staff know how to recover and in what order? Do they know enough about SQL Server to do what needs to be done?
DB Data – Is this a transactional database? A bulk-loaded database? Will the data only be coming into the database once a day or several times a minute? What devices (web entry, application entry, flat files, replication) will be used to update the database? This impacts Recovery Model and backup types.
Restoring – Network link, NAS share, tape drive, etc. It’s easier and faster to restore from a local backup than it is to pass data across a network. Always plan for local if possible. Especially given the inherent problems with network connectivity.

5. The Database Recovery Model
Full
Full, Full Differential, Transaction Log
Bulk-Logged
Simple
Full, Differential (restricted)
File / FileGroup, Partial, Copy Only & Compressed backups can be done regardless of Recovery Model
Don’t confuse Full Recovery Mode with a Full Database Backup or Full Database Restore.
Restricted on Simple Mode Differential means that it backs up the extents as opposed to the actual data (per BOL)
Full recovery fully logs every transaction. Bulk-Logged fully logs all transactions except minimally logged (BCP, Bulk Insert, OpenRowSet, etc). Minimally logged means it logs the extents allocated, not the actual data. Simple uses the transaction log to keep uncommitted transactions in, but you can’t backup the transaction log because it truncates the transactions as soon as they are recovered. Only Full Recovery Mode allows Point in Time restores. Bulk-Logged can be restored to most recent transaction log and Simple can only be restored to the last non-transaction log backup.
Full recovery mode keeps all committed transactions & rolls back all in-process ones. Logs can be backed up while full or differential backups are running. Logs all operations. Can do Point in Time restores with Full.
Bulk-Logged recovery mode does not log all transactions. It minimally logs for bulk loads (BCP, Bulk Insert, OpenRowSet, etc.) & index creation operations while fully logging other transactions. Handy for when doing a datawarehouse or other heavy write DB. What minimal logging means is that only the amount of space used for a load (the extent allocation) will be logged. The actual data changes will not be tracked. Can't do Point in Time, but can recover to last transaction log.
Simple recovery mode still uses the transaction log! All recovery modes do. However, in Simple mode, you can't recover uncommitted transactions because you can't back up the log. Nor can you shrink it, make changes to it or restore to a Point In Time. Can only recover to last non-log backup.

6. The Backup Types Full (aka Complete) Backups Differential Backups
File / Filegroup Backups
Partial Backups
Copy Only Backups
Compressed Backups (must be enabled)
Encrypted Backups (not a true type - TDE)
Transaction Log Backups
**Incremental Backups are a Windows backup type, not a SQL Server backup type. Sometimes confused with Transaction Log backups (but wrongly so).
Encrypted Backups, something discussed with SQL 2008, doesn’t really exist as it’s own backup type. You can back up to an encrypted disk / share, back up with a password, or turn on Transparent Data Encryption which encrypts all files, database and backup files. It’s important to note that both Compressed and Encrypted Backups will take extra time before the restore, but you may or may not notice the decompression or decryption process. It all depends on how your databases are set up, how big they are, and what media you are restoring from.
Note from MSDN regarding TDE: When TDE is enabled on a database, all backups are encrypted. Thus, special care must be taken to ensure that the certificate that was used to protect the DEK (see How to Enable TDE) is backed up and maintained with the database backup. If this certificate (or certificates) is lost, the data will be unreadable. Back up the certificate along with the database. Each certificate backup should have two files; both of these files should be archived (ideally separately from the database backup file for security).

7. Dealing With the Boss “I want it all!” – Say what? Email / File Server
Company Website
Phone System
Reports / Data Warehouse / Cubes
Business Impact Data
Don’t forget, there is a different between Recovery and Business Continuity. Don’t let the boss get you wrapped up in the wrong things.
“On the way to the office” – the funny story about how serious one company got about verifying their data and database restores. (The impossible request).
What other impossible, or hard to fulfill, recovery requests have been made?

8. Prioritizing List servers in order of importance
List the databases in order of importance
Include database sizes & data upload types
Assign Recovery Models
Assign Backup Types
Triple-Check the List
Experiment in Sandbox
It’s very important to experiment with recovering your database before you finalize your recovery strategy. Why? Because what you thought might be an acceptable recovery time may turn out to take longer than you realized. Or may be more complicated than you were aware of.
Don’t forget to factor the costs to this. Cost for downtime, cost for doing this “wrong,” cost for doing this right (as a comparison).

9. Don’t forget the dependencies!!
Websites can’t run without the database that backs them up. Applications too. What about app servers, web servers, middle-tier whatchamacallits, report servers, etc. How do each of these get impacted? Where is the first domino? What domino is the last?

10. Document, Document, Document
Write it all out, in order, in detail.
Have your backup proof it for errors and questions.
Don’t assume the next person in line will know the technobabble.
Get the sign-off.

11. Theory to Practice Create the jobs. Create monitor jobs / alerts.
Restore backups regularly.
Never assume things are working correctly!

12. Important Schtuff to Remember
Always start from a Full Backup
Differentials mostly useful for DWs, VLDBs, when time constraints matter
Always backup Transaction Log unless using Simple Recovery Mode
File / Filegroup backups can be useful, but restores can be complicated
Keep as many days / weeks as you need to feel comfortable with
Keep more than 1 day’s worth of backups, somewhere
Using Windows Backup Software on Database Files is NO SUBSTITUTE!
Test your backups regularly to make sure they restore correctly
Mention the 3 day or 4 day backup rule – keeping that extra on hand just in case something happens over the weekend (or a long holiday weekend).

13. References
SQL Server Books Online (subject “database backups [SQL Server]”)
MSDN.Microsoft.com (Specific Link:
Google – search on terms in presentation with “SQL Server” in front

14. My Information Webpage: http://www.brandietarvin.net
Blog:
Twitter: