Disaster Recovery is everyone’s job! Kevin Hill Twitter: @Kevin3NF Kevin@DallasDBAs.com www.DallasDBAs.com

While you are sitting here…

Your server room is on fire! Fire suppression failed. Fire extinguishers deployed manually, the fire is out. The most important database server in your company melted. Its dripping on the storage array. How long until you are back online? Really? Got proof? Phone sound by Mike Koenig

Business Impact What is the impact in dollars of the server you just lost? Or the data on it? What about losing the server room? What if the building just went toasty? We’ll stop there and assume the city is still intact. . . The more you need to protect, the more you have to put in place to protect it

“Single point of failure…” 4 of the most dreaded words to any IT worker Hardware Location People Redundancy is expensive, until your systems are down

TLAs Memorize these! RPO – Recovery Point Objective Data Loss tolerance, usually measured in minutes. RTO – Recovery Time Objective Downtime tolerance usually measured in minutes/hours.

What is a backup? Simply put, a backup is a copy of something in case the original is damaged, corrupted, lost, stolen or otherwise no longer useful. Its an insurance policy. It is the first step in a Disaster Recovery/Business continuity solution. It is NOT a Performance or High Availability solution. It is a preventer of CLMs and RGEs.

Why backup? Protect customer data. Protect the business. Ensure peace of mind for the Customer, the CEO and the rank and file. Refresh the non-production environments. Job Security. Service Level Agreements/Regulatory requirements. Targeted threats (hackers, ransomware, disgruntled employees)

What needs to be backed up? Databases of course. . . Paper copies of legal documents. 3-part forms (You take the pink one. . .). Digital copies of spreadsheets, contracts, etc. Its not just about the database (but a lot of it is!). Other information stores (think emails, websites. . .).

What databases should you back up? Production This should be a no-brainer. . .except in that one place. . . Staging This could be pre-production or any number of other terms. Test/UAT Development Dev servers, TFS, Source control, etc.

Which databases? System User Read-only? Master Model MSDB Sales HR Shipping Read-only?

SQL Server backup types Full backup—all of the data Differential—everything since the last full backup Transaction Log—everything since the last log. . .gives you the ability to restore to a point in time

SQL Server recovery models Full Allows for point-in-time recovery IF… Simple Point-in-time is not possible Only Full and Differential backups Bulk-Logged Special Snowflake recovery model

Backup Frequency It Depends! RPO RTO Tolerance for Data Loss Frequency of data changes Load on the server

Where will you store them? Local server Different server Tape, with offsite Different data center Different city Cloud Storage

Retention Considerations Backups Files (digital/paper) Regulatory “Life of the deal” SLAs

Automation Backups should be happening automatically Built-in SQL Server/Windows: Maintenance Plans (boo, hiss…) Central Management Server Powershell scripts 3rd party tools: “Ola scripts” Red Gate Minion

So you backed it all up… now what? If you don’t test your backups, you don’t have a DR plan. . .you have a DR Hope. Some really smart guy, years ago. Not me.

Would you like some “9s” with that? 9s are expensive. . .the more you want, the more you pay. 99% = 3.65 days of downtime per year 99.9% = 8.76 hours per year of downtime 99.99% = 52.5 minutes 99.999% = 5.25 minutes. This is going to be a very expensive investment in redundant everything, across multiple geographic regions with automatic failover. . .

Twitter: @Kevin3NF – stalk me  Thanks for coming and PLEASE fill out a speaker evaluation form…help me get better at this for the next group! Kevin Hill Twitter: @Kevin3NF – stalk me  Kevin@DallasDBAs.com www.DallasDBAs.com

Lets Do a Backup! Future reference: Basic ad-hoc backup via SSMS