Prevent Recovery Amnesia - Forget The Backups
•Descargar como PPTX, PDF•
0 recomendaciones•337 vistas
Do you suffer from Recovery Amnesia? You have a complete strategy to backup your SQL environment; but what about the recovery? Is that even part of your strategy? Through this introductory session we will review the various aspects & myths of backups in SQL Server. We will pin down how developing a recovery strategy to meet business requirements is, in fact, more important than just a good backup strategy. Fonts used for proper display: Ostrich Sans Bold Cicle
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (12)
Destacado
Similar a Prevent Recovery Amnesia - Forget The Backups
Similar a Prevent Recovery Amnesia - Forget The Backups (20)
Último
Último (20)
Prevent Recovery Amnesia - Forget The Backups
- 1. Prevent Recovery Amnesia Forget The Backups
- 4. RTO Amount of time which data or hardware is desired to be restored after data corruption or hardware failure Usually referred to in 9’s • 5 9’s = 99.999 % up time • Just over 5 minutes of allowable downtime per year (means maintenance) • 4 9s = 52.5 minutes • 3 9s = 8.75 hrs • 5 9s between 9-5 different than 5 9s 24/7
- 5. RPO Point in time that data can be restored from. • Minutes • Hours • Days • Weeks Basically – How much work can be lost?
- 6. SLA RPO & RTO together = Service Level Agreement • Need to know for each database you are responsible for • Press business managers / owners for business driven decisions on what acceptable values are • MUST consider the business implications of downtime and data loss
- 8. Recovery Strategy Backups are worthless • If can’t restore to meet business requirements Most critical of DBA duties Practice, practice, practice Practice different scenarios • Point in time • Corrupt page Don’t forget the Keys!
- 9. Keys & Offsite Storage Backup certificates and keys • First thing done on any server • If lost, data could be too Keys to backup • Service Master Key • Database Master Key • Symmetric, Asymmetric & Certificates Offsite storage • Necessary evil • Mitigate the risks
- 10. Backup Models
- 11. Simple No log backup Auto reclaims Changes since most recent backup unprotected Only recover to end of backup
- 12. Full Requires log backups No work lost due to lost or damaged data file Restore to an arbitrary point in time Normally no loss of data, but slight risk
- 13. Bulk Logged Special purpose Reduce log space No point in time recovery supported Temporary use for bulk operations
- 14. Demo Log • Growth • Free space
- 15. Backup Scope
- 16. Database • Entire database • Includes • Schema • Data contents • Transaction log to restore from scratch • Simplest way to restore • Lot of disk space • Lot of time
- 17. Partial Alternative to database backups for VLDB Good for read-only data Includes • Primary filegroup • All read/write filegroups • Specified read-only filegroups
- 18. File Individual files and / or filegroups Compliment partial backups Usually included in complex backup models
- 19. Backup Types
- 20. Full All data within the backup scope Entire contents of files and filegroups Does not truncate transaction log • Simple recovery model only Base for other backup types
- 21. Differential Only what changed since last full backup Faster Must restore full backup first
- 22. Log Transaction log Must have full backup first Not an option with simple recovery mode Truncates log by writing committed transaction to disk
- 23. Tail Log Captures log records not yet backed up Keeps log chain intact Required to recover to latest point in time Not all scenarios require
- 24. Demo Restore • Point in time
- 25. Compression
- 26. Compression Saves space & I/O Heavy impact on CPU Set at server level • Time of backup Compression ratio • Msdb.dbo.backupset • Backup_size / compressed_backup_size
- 27. Encryption
- 28. Encryption New for SQL 2014 Encrypt while backing up Requires Database Master Key • Certificate • Asymmetric key (EKM only) If using TDE • Use different certificates & keys to increase security
- 29. More for 2014
- 30. New backup Features SQL Server Backup to URL • SQL 2012 SP1 CU2 • T-SQL, PowerShell, SMO • 2014 adds SSMS SQL Server Managed Backup to Windows Azure • Database or Instance level • Recommended for SQL Server instance on Azure VMs Encryption for Backups
- 31. Backup Myths
- 32. Myths Backup operations cause blocking Concurrent transaction backup can’t be done when full/differential in progress Backups always test page checksums Backups read through the buffer pool Full or differential backups clear the log Backups perform consistency checks If the backup works, so will the restore
- 33. Myths Tail of log backups are always possible Use snapshots instead of backups Log backups are the size of the log Cannot backup a corrupt database Log backups always clear the log No need to backup the system databases Always plan a good backup strategy Always plan a good recovery strategy!
- 34. Keep In Touch • @CBELLDBA • chris@WaterOxConsulting.com • www.WaterOxConsulting.com
Notas del editor
- Backup blocking No. Backup operations do not take locks on user objects. Backups do cause a really heavy read load on the I/O subsystem so it might *look* like the workload is being blocked, but it isn't really. It's just being slowed down. There's a special case where a backup that has to pick up bulk-logged extents will take a file lock which could block a checkpoint operation – but DML is never blocked. Concurrent No, this changed in SQL Server 2005. Checksums No. It only does it when you use the WITH CHECKSUM option – which you should Buffer pool No. The backup subsystem opens its own channels to the database files to avoid the performance hit of having to read everything into SQL Server's memory and back out to the backup device (and also effectively flushing the buffer pool in the process). If you ask the for page-checksum checking, it uses it's own small portion of memory. Clear the log No. A log backup includes all the log since the last log backup – nothing can change that – no matter whether that log was also backed up by a full or differential backup. In the FULL or BULK_LOGGED recovery models, the *only* thing that clears the log is a log backup. Consistence checks A la DBCC CHECKDB - No. Nothing else to say. Backup works so will restore No. Please don't fall into this trap. You must regularly validate your backups to give yourself a high level of confidence that they will work if a disaster occurs.
- Tail always possible No. A tail-of-the-log backup is one that backs up all the log generated since the last log backup, in an exceptional situation. If the data files are damaged, you can still do a tail-of-the-log backup EXCEPT if the un-backed-up log contains a minimally-logged operation. That would require reading data extents – which cannot be done if the data files are damaged. For this reason, the BULK_LOGGED recovery model should not be used on databases that have 24×7 user transactions. Snapshots No. A database snapshot is only usable while the database on which it is based is usable and online. If the source database is corrupted, the database snapshot most likely is too. If the source database goes suspect, so does the database snapshot. Also, having multiple database snapshots (equating to multiple log backups) incurs an increasing performance drain – as every page that changes in the source database may need to be synchronously written to all existing snapshots before it can be written to the source database data files, and all existing database snapshots will grow as more pages are pushed into them. Log backup size of log No. The log has to accomodate the space necessary to roll back active transactions, the amount of space returned by DBCC SQLPERF (LOGSPACE) on a busy system doesn't accurately refect the amount of log records in the log. This blog spot explains: Search Engine Q&A #25: Why isn't my log backup the same size as my log? And apart from that, a log backup is just all the log generated since the last log backup – not the whole log file usually – and if it happens to be, the first part of the explanation comes into play. Cannot backup corrupt db No. In most cases you can use the WITH CONTINUE_AFTER_ERROR option to back up the corrupt database. If that fails (maybe because of a damaged boot page or file-header page), there are no other options apart from OS-level file backups. Log backup always clears the log No. If there's no concurrent data backup running, a log backup will always *try* to clear the log, and only succeed in clearing the inactive portion of the log – the log that's only considered 'required' by SQL Server because it hasn't yet been backed up. If anything else is holding the log 'required', it cannot be cleared, even though it has been backed up. Subsequent log backups will check again and again until the time comes when that portion of the log can be cleared. The TechNet Magazine article Understanding Logging and Recovery in SQL Server I wrote last year explains a lot more about how the log works. System dbs No. You should always back up the system databases. Master contains all the security info, what databases exist – msdb contains all the SSIS packages, Agent jobs, backup history – model contains the configuration for new databases. Don't fall into the trap of only backing up user databases otherwise you'll be in a world of hurt if you have to do a bare-metal install Good backup strategy No. Now you're thinking 'Huh?'… You should plan a restore strategy. Use the business requirements and technical limitations to figure out what you need to be able to restore in what time, and then use that to figure out what backups you need to take to allow those restores to happen.