Backups for non-DBAs the Why…not the How Kevin “I’m not Bob” Hill SQL Server DBA Twitter: @Kevin3NF (homework – follow me) www.DallasDBAs.com/Blog

Who am I, and why do you care? Finance degree, UNT 1991 7 years as a Financial Analyst Database development and admin experience back to 1994 Have managed over 5000 SQL Server instances Owned 3NF Consulting (2001 – 2008) Owner DallasDBAs.com Sr. DBA/team leader Dad, Husband, Grandfather and Cycling enthusiast

While you are sitting here…

Your server room is on fire! Fire suppression failed Fire extinguishers deployed manually, 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?

Business Impact What is the impact in dollars of the server you just lost? Or the data on it? What about losing the 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

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-prod environments Job Security Service Level Agreements/Regulatory requirements Targeted threats (hackers, ransomware)

Targeted Threats Hackers, using known exploits and zombie computers Social Engineering Stolen laptops Employees that will click any link or open unexpected attachments (WannaCry?) Disgruntled employee (the biggest threat on this list)

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-prod or any number of other terms Test/UAT Development Dev servers, TFS, Source control, etc.

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

Which databases? System User Read-only

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

SQL Server recovery models Now we’re getting really specific… Full Simple Bulk-Logged

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

“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

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

Automation Backups should be happening automatically Why pay a DBA to manually do something SQL Server will do for you? 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.

High Availability/Disaster Recovery HA – The ability to be back online automatically(?) in a very short timeframe when there is a failure…generally measured in seconds, maybe minutes. Clustering Availability Groups DR – The ability to recover from an unplanned outage Database Server Building HA and DR go hand in hand, but are NOT the same thing. They complement each other when set up correctly.

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…

Used with permission from Brent Ozar Unlimited:

Story Time with Uncle Kevin Jobs.com, 2000: Someone boogered up the User table Spoiler – it was a Jr. DBA named Kevin… CCC, 2007 Someone deleted 1 row, caused a major outage It was the customer record that generated half their revenue Every US based airline….or so it seems Luggage system downstream effects Amazon Web Services S3 storage Maintenance allowed too many servers to go offline, system took down websites all over the East Coast.

Thanks for coming! If you remember nothing else: RPO RTO Backups are everyone’s responsibility No Single points of failure! Test your backups for validity Create and Test your DR plan Ringing Phone sound created by Mike Koenig/SoundBible.com