1. Building Effective Backups
Ed Pollack
Database Administrator
CommerceHub

2. Agenda Ensuring Data Recovery and Security Purpose of backups
What are our options?
Mechanics & structure
Best practices
Performance
Conclusion

3. Backups: Why Do We Need Them?
Point-in-time recovery
Data forensics
Dev/QA/testing
Compliance
Corruption or lost data
Disaster recovery
Transaction log management

4. What are Our Options? SQL Server Maintenance Plans 3rd party tools
Simple, incomplete, not good for complex use cases.
3rd party tools
Manage everything for you, easy, may not meet all needs.
DYI: Script your own
More work up-front by you, but ability to customize to meet any needs.

5. Recovery Models Simple Full Bulk-Logged No TLog backups.
Tlog space is auto-managed and kept as small as needed.
No point-in-time recovery.
Full
TLog backups are needed.
Can recover to any point in time.
Bulk-Logged

6. Backup Types FULL DIFFERENTIAL TRANSACTION LOG
Complete database backup of all data & log info.
Can restore in its entirety to the point in time it was taken.
They can be BIG even when compressed.
DIFFERENTIAL
Backs up all changes since the last full backup.
TRANSACTION LOG
Backs up all change since the last full or TLog backup.

7. Backup Basics
Demo

8. The Transaction Log
Maintains a record of all changes that occur in a database.
The log will grow with each transaction until it receives a FULL or TLOG backup.
If the log file runs out of space, you cannot write to the database!
In a FULL recovery model, it needs to be managed!

9. What is a Good Backup Plan?
RPO: Recovery Point Objective
How much data loss is OK?
RTO: Recovery Time Objective
How much downtime is OK?
How long do backups take to run?
How long do restore operations take?
How much manual intervention is required?

10. Do I Back Up My System Databases?
Model (YES!)
MSDB (YES!)
Master (YES!)
TempDB (Nope!)
ReportingServices (Yes!)
ReportingServicesTempDB (Nope!)

11. The Backup Chain
Backups exist as part of a logical sequence of data change over time, starting with a FULL backup and ending with the next FULL backup.
FULLFULLFULL…
FULLDIFF, DIFF, DIFF…FULLDIFF, DIFF, DIFF…FULL…
FULLDIFFTLOG+TLOG+TLOG+TLOG…FULL…
FULLDIFFTLOG+TLOG…DIFFTLOG+TLOG…FULL…
FULLTLOG+TLOG+TLOG+TLOG…FULL…
Breaking the backup chain can invalidate backups!

12. TEST YOUR BACKUPS! TEST YOUR BACKUPS … (Seriously, I really mean it!)
(If you aren’t convinced by now…WHY!?)

13. More Options
Demo

14. Getting More Info
Demo

15. Performance
Sharding to separate storage can greatly improve speed, but increases complexity.
Compress your backups. Make it the default!
Speed is affected by memory, network, and disk I/O.
Can adjust additional settings:
BUFFERCOUNT
MAXTRANSFERSIZE
BLOCKSIZE
Research and test thoroughly before changing these!

16. Conclusion Backups are a critical component in SQL Server.
Business needs will dictate type & frequency.
Choose the correct recovery models.
Build a process that is easy to manage & reliable.
Always TEST your backups. PLEASE!

17. Questions???

18. Contact Info & Links for Ed Pollack
@EdwardPollack SQL Shack SQL Server Central Dynamic SQL: Applications, Performance, and Security SQL Saturday Albany (2017) Thank you!!!