Database Backup Overview

DBA Challenge

• Core responsibility for backup and recovery

• But, its not easy
– Databases are growing exponentially
– Backup times are increasing even faster
• Your Backups impact other activities
– End Users
– DBA Maintenance
• And your storage costs are out of control
• And when bad things happen
• Needs to work
• Taking forever to recover
Database Backup: Terms

• Online Backup (aka “Hot” or “Online”)

– Backup while database is running
– Zero business interruption during backups
• Incremental Backup
– Backup of data that has changed since the last full backup.
• Partial Backup
– Backup of select tables
• Consistent Point in Time Recovery
– Restoring a database with data in a consistent state at a date
and time
• Roll Forward Recovery
– Recovery that restores a database to a specific date and time.
Most Critical Questions to Ask First

• What are my recovery requirements?

– Assess tolerance for data loss: Recovery Point Objective (RPO)
• How frequently should backups be taken?
• Is point-in-time recovery required?
– Assess tolerance for downtime: Recovery Time Objective (RTO)
• Downtime: Problem identification + recovery planning +
systems recovery
• Tiered RTO per level of granularity, e.g. database, tablespace,
table, row
– Determine backup retention policy
• Onsite, offsite, long-term
• How Does MySQL Enterprise Backup strategy fulfill
those requirements?
Backup Method 1: Full

• Well Suited for:

– Databases that can tolerate hours/days RTO
– Medium-High change between backups (e.g. over 30%)
– Environments where disk can be allocated for 1x size of database

• Backup Strategy
– Full backups with optional backup compression
– Full backup archived to tape, as needed
Backup Method 2: Full + Incremental

• Well suited for

– Databases that can tolerate no more than a few hours RTO
– Environments where disk can be allocated for 1x size of database

• Backup strategy
– Occasional Full backup, followed by more frequent incremental
– To recover - apply Full and then applying 1 or more Incremental
– Full backups archived to tape, as needed
– Incremental Backups retained on-disk, as needed
Backup Method 3: Full + Incremental + Log

• Well suited for

– Databases that can tolerate no more than a few minutes RTO
– Environments where disk can be allocated for more than1x size of
database

• Backup strategy
– Initial full backup, followed by incremental backups
– Backup Transaction Logs
– To recover - apply Full and then applying 1 or more Incremental
– Finally Roll Forward with Transaction Log to “minute” desired.
– Full backups and incrementals archived to tape, as needed
– Logs are backup up and retained on-disk, as needed
Backup Method 4: Offload Backups to Slave
(Replication)
• Well Suited for:
– Databases that require no more than several minutes of
recovery time, in event of failure
– Environments that can preferably allocate symmetric
hardware and storage for physical standby database
– Environments whose backup storage infrastructure can be
shared between master and slave database sites
• Backup Strategy
– Setup Master / Slave replication
– Slave acts as physical standby database
– Run full and incremental backup on slave
– Backup can be restored to master or slave database
– Backups can be taken at each database for optimal protection
 Determining Backup Strategy

Low Value Data High Value Data

High Change F: Daily
I: Hourly
A: Replication,
F: Weekly Backup on Slave
Change Frequency

I: Daily
F: Daily
F: Daily I: Hourly
I: Hourly A: Binlog Backups: 5 min
Low Change

F: Monthly
I: Weekly F: Full
I: Incremental
A: Additional
F: Weekly
I: Daily

F: Monthly

Value of Data
 Backup Strategies Comparison
Method Backup Factors
Method 1: • Longest Backup Times
Full Backups • Largest Storage Space
• Save space with compression
Method 2: • Shortest Backup Time
Full + Incremental • Reduced Storage Requirements
Backup • Requires 1X production storage
for copy
Method 3: • Added Storage Requirements
Full + Incremental + • Requires more than 1X
Log Backup production storage for copy
Method 4: • Used with 1 of the above
Offload Backups Slave • Frees Master for more workload
Replication • Requires 1X production hardware
and storage for standby database
Recovery Factors
• Easy to Recover
• Fastest Restore Times
• Finer-grained Recovery
• Slower Restore Times
• First Restore Full Backup
• Then Restore Incrementals
• Finest-grained Recovery
• Slowest Restore Times
• First Restore Full Backup
• Then Restore Incrementals
• Then Apply Logs
• Fast failover to standby
• Backups are last resort, in
event of double site failure
or need to perform PITR