Understanding Database Backup Strategies by Pinal Dave

by Oct 25, 2014

Categories

Tags

Administration agent-based monitoring Agentless Monitoring alert responses alert thresholds alerting Alerts Amazon Aurora Amazon EC2 Amazon RDS Amazon RDS / Aurora Amazon RDS for SQL Server Amazon Redshift Amazon S3 Amazon Web Services (AWS) Analytics application monitoring Aqua Data Studio automation availability Azure Azure SQL Database azure sql managed instance Azure VM backup Backup and recovery backup and restore backup compression backup status Backup Strategy backups big data Blocking bug fixes business architecture business data objects business intelligence business process modeling business process models capacity planning change management cloud cloud database cloud database monitoring cloud infrastructure cloud migration cloud providers Cloud Readiness Cloud Services cloud storage cloud virtual machine cloud VM clusters code completion collaboration compliance compliance audit compliance audits compliance manager compliance reporting conference configuration connect to database cpu Cross Platform custom counters Custom Views customer survey customer testimonials Dark Theme dashboards data analysis Data Analytics data architect data architecture data breaches Data Collector data governance data lakes data lineage data management data model data modeler data modeling data models data privacy data protection data security data security measures data sources data visualization data warehouse database database administration database administrator database automation database backup database backups database capacity database changes database community database connection database design database developer database developers database development database diversity Database Engine Tuning Advisor database fragmentation database GUI database IDE database indexes database inventory management database locks database management database migration database monitoring database navigation database optimization database performance Database Permissions database platforms database profiling database queries database recovery database replication database restore database schema database security database support database synchronization database tools database transactions database tuning database-as-a-service databases DB Change Manager DB Optimizer DB PowerStudio DB2 DBA DBaaS DBArtisan dBase DBMS DDL Debugging defragmentation Demo diagnostic manager diagnostics dimensional modeling disaster recovery Download drills embedded database Encryption End-user Experience entity-relationship model ER/Studio ER/Studio Data Architect ER/Studio Enterprise Team Edition events execution plans free tools galera cluster GDPR Getting Started Git GitHub Google Cloud Hadoop Healthcare high availability HIPAA Hive hybrid clouds Hyper-V IDERA IDERA ACE Index Analyzer index optimization infrastructure as a service (IaaS) infrastructure monitoring installation Integrated Development Environment interbase Inventory Manager IT infrastructure Java JD Edwards JSON licensing load test load testing logical data model macOS macros managed cloud database managed cloud databases MariaDB memory memorystorage memoryusage metadata metric baselines metric thresholds Microsoft Azure Microsoft Azure SQL Database Microsoft PowerShell Microsoft SQL Server Microsoft Windows MongoDB monitoring Monitoring Tools Monyog multiple platforms MySQL news newsletter NoSQL Notifications odbc optimization Oracle PeopleSoft performance Performance Dashboards performance metrics performance monitoring performance schema performance tuning personally identifiable information physical data model Platform platform as a service (PaaS) PostgreSQL Precise Precise for Databases Precise for Oracle Precise for SQL Server Precise Management Database (PMDB) product updates Project Migration public clouds Query Analyzer query builder query monitor query optimization query performance Query Store query tool query tuning query-level waits Rapid SQL rdbms real time monitoring Real User Monitoring recovery regulations relational databases Releases Reporting Reports repository Restore reverse engineering Roadmap sample SAP Scalability Security Policy Security Practices server monitoring Server performance server-level waits Service Level Agreement SkySQL slow query SNMP snowflake source control SQL SQL Admin Toolset SQL CM SQL code SQL coding SQL Compliance Manager SQL Defrag Manager sql development SQL Diagnostic Manager SQL Diagnostic Manager for MySQL SQL Diagnostic Manager for SQL Server SQL Diagnostic Manager Pro SQL DM SQL Doctor SQL Enterprise Job Manager SQl IM SQL Inventory Manager SQL Management Suite SQL Monitoring SQL Performance SQL Quality SQL query SQL Query Tuner SQL Safe Backup SQL script SQL Secure SQL Security Suite SQL Server sql server alert SQL Server Migration SQL Server Performance SQL Server Recommendations SQL Server Security SQL statement history SQL tuning SQL Virtual Database sqlmemory sqlserver SQLyog Storage Storage Performance structured data Subversion Support tempdb tempdb data temporal data Tips and Tricks troubleshooting universal data models universal mapping unstructured data Uptime Infrastructure Monitor user experience user permissions Virtual Machine (VM) web services webinar What-if analysis WindowsPowerShell

Backup is one of the driest topics and it seems to be something non-negotiable for a DBA role. If we look into the fine prints of why someone should take a backup, then it is fundamentally for business continuity and to recover from disaster. The last mile of defense or these backups act like your safety net when everything goes wrong for you. There are multiple strategies organizations use when working with backups. Though this blog post talks about the backup strategy, we would like to bring out that the restore strategies are equally important. If you don’t have an effective restore strategy, then the backups is of no value. The idea here is to answer some simple questions as we build our backup strategies:

Know your What?

The basic building block of any effective backup is to know what we are going to backup. This involves multiple strategies – for mission critical databases which the organization depends we will have aggressive plans and for databases which are lesser critical we will have a different plan. There is no one size fits all option. Databases are tough and sometimes tedious in the recovery process, so we need to be cognisant of how we do them.

Know your Where?

The basic trait of an effective backup is to protect us from all kinds of possible failures that can happen for our database as well as our backups. We have seen organizations take this matter seriously and have multi-factor backup strategies that make it interesting for a process to be in place. There are DBA’s who make backups from DB to Files to Tape or from DB to local files to FTP remote site or DB to files to Cloud backup or DB to Tape to remote storage server or it can also be from DB to SAN to shared storage etc. All these are valid and possible strategies that DBA’s use and there is no right or wrong answer. It is completely organization dependent and their SLAs for RTO and RPO. Though Local storage gives cheaper alternatives and can help in recovery process faster, it can also become a single point of failure if the whole site goes down because of natural disaster.

Know your When?

For systems that need to be 24 x 7 x 365, it is important to know the database access patterns before any backup can be taken. There are two fundamental question to be answered in this “When” timeframe. Those are – What is the frequency at which I need to take a backup and the second question is – What is the time I need to schedule this backup.

The frequency question can be answered easily if we understand what would be the data loss if a disaster struck just minutes before the next backup. How much data can we afford to loose? How long would it take to bring database online and how much time will it take to recover lost data? All these are business challenges that one needs to answer before taking a call on frequency.

As far as the second question is concerned – we would want to run the backups when there is minimal load on the system. Backups do consume resources on the servers and there can sometimes be visible performance degradation in the application response when backups run. Normally backups are run in scheduled pattern of maintenance windows by DBA’s every day or in a pattern. Having said that, whenever business starts in the morning – the busiest time is in the first couple of hours when people are trying to login and start their day. So we need to make sure if there are any backups run as part of maintenance automated scripts, they must finish well before the day could start.

Know your AddOns?

In this era, there are a number of capabilities the platform can give and it is important for us to know which of these are under production. There can be different resource needs if we use any of these techniques like Compression or Encryption. In SQL Server world, it is one of the given tasks that the backups needs to use the compression techniques. It minimizes the IO needs and the backup for most cases completes faster when compared to backups taken normally.

We have seen that organizations sometimes have to protect their data and resort to backup encryption techniques too. In this case, it is critical and most important to keep the encryption key also safe and available on the DR site. If we fail to take a backup of the same, then the backups can be void because we will not be able to recover the same if the keys are lost.

Do you test it?

All your backups make sense only when we are able to restore the same in hour of disaster. There is no point in taking a backup and not testing them from time-to-time. Databases like SQL Server have an option to validate the backup file once it is written to disk. It is advisable to test them in periodic fashion and always try to create a backup of your backup. We have seen DBA’s cautious because it is better to invest the extra ounce of overhead than being sorry when disaster strikes.

Conclusion

As we sign off, we are sure we could bring out some of the basic fundamental building blocks of working with backups. Though these are not written on stone, we assume that as seasoned DBA’s you are well on top of your backup strategies. If you have not planned for the same, we hope this blog will get your started in that thinking process. It is a journey which any DBA needs to refine over a period of time and look for new capabilities that the platform can offer to enhance the experience of how backups can be taken.

     

About Pinal Dave
Technology Evangelist & Founder of SQL Authority

Pinal Dave works as a Technology Evangelist (Database and BI) with Microsoft India. He has written over 2000 articles on the subject on his blog at http://blog.sqlauthority.com. During his career he has worked both in India and the US, mostly working with SQL Server Technology – right from version 6.5 to its latest form. Pinal has worked on many performance tuning and optimization projects for high transactional systems. He has been a regular speaker at many international events like TechEd, SQL PASS, MSDN, TechNet and countless user groups.