<Insert Picture Here>

MySQL Enterprise Backup

MySQL Enterprise Backup

Fast, Consistent, Online Backups

The preceding is intended to outline our general

product direction. It is intended for information

purposes only, and may not be incorporated into any

contract. It is not a commitment to deliver any

material, code, or functionality, and should not be

relied upon in making purchasing decisions.

The development, release, and timing of any

features or functionality described for Oracle’s

products remains at the sole discretion of Oracle.

Agenda

• Database Backup Overview

• MySQL Enterprise Backup: Features & Benefits

• Database Backup Types: Comparison

• MySQL Enterprise Backup: How it Works

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

Low

Chang

e

Hig

h C

hange

Change F

requency

Value of Data

F: Daily

I: Hourly

F: Weekly

I: Daily

F: Weekly

I: Daily

F: Monthly

I: Weekly

F: Monthly

F: Daily

I: Hourly

A: Replication, Backup on Slave

F: Daily

I: Hourly

A: Binlog Backups: 5 min

F: Full

I: Incremental

A: Additional

Backup Strategies Comparison

Method Backup Factors Recovery Factors

Method 1:

Full Backups

• Longest Backup Times

• Largest Storage Space

• Save space with compression

• Easy to Recover

• Fastest Restore Times

Method 2:

Full + Incremental

Backup

• Shortest Backup Time

• Reduced Storage Requirements

• Requires 1X production storage

for copy

• Finer-grained Recovery

• Slower Restore Times

• First Restore Full Backup

• Then Restore Incrementals

Method 3:

Full + Incremental +

Log Backup

• Added Storage Requirements

• Requires more than 1X

production storage for copy

• Finest-grained Recovery

• Slowest Restore Times

• First Restore Full Backup

• Then Restore Incrementals

• Then Apply Logs

Method 4:

Offload Backups Slave

Replication

• Used with 1 of the above

• Frees Master for more workload

• Requires 1X production hardware

and storage for standby database

• Fast failover to standby

• Backups are last resort, in

event of double site failure

or need to perform PITR

MySQL Enterprise Backup Features & Benefits

MySQL Server Features

0%

5%

10%

15%

20%

25%

30%

35%

40%

How would you rank the following upcoming MySQL capabilities in terms of importance? Results "Extremely Important"

- Online Backup is the #1 most requested feature for MySQL Enterprise Customers

MySQL Backup Concerns

0%

5%

10%

15%

20%

25%

30%

35%

40%

Backup and/or

Recovery takes too

long

Backup method has too much impact on

MySQL server

Backups aren't

automated

Backups are not Online or

Hot

I don't have a MySQL backup solution

Recovery method

produces inconsistent

data

The MySQL backup

solution I have works

fine

Backups fail or are

incomplete

Backup failure goes unnoticed

What concerns you most about your current MySQL backup solution?

- Backup & Recovery Performance is the #1 Concern

MySQL Enterprise Backup

• Online Backup for InnoDB

• Support for MyISAM (Read-only)

• High Performance Backup & Restore

• Compressed Backup

• Full Backup

• Incremental Backup

• Partial Backups

• Point in Time Recovery

• Unlimited Database Size

• Cross-Platform

– Windows, Linux, Unix

Benefits

• Online “Hot” Backup (Non-blocking)

– Reads and Writes to InnoDB

– Reads for MyISAM tables

• High Performance

– Backup: >3x faster than mysqldump (export)

– Restore: >10x than mysqldump recovery

• Consistent Backups

– Point in Time Recovery

• Compression

– Multi-level compression

– Save 70% or more of the storage required

Benefits

• Reliable

– Proven for 7+ Years

• Scalable for Large Databases

– No Database Size Limitations

• Easy to automate

– Easily integrate within various scheduling systems

– Examples: cron, OSB scheduler, others

MySQL Enterprise Backup 3.5: New Features

• Incremental backup

• Support of InnoDB Barracuda file format

• Backup of compressed tables

• Backup of partition files

• Backup of in-memory database

• with --exec-when-locked option

• Adds mysql system tables to keep backup status,

progress, and history

High Performance Backups

0

5

10

15

20

25

30

26GB - 8 Tables 32GB - 33 Tables

Min

ute

s

Backup Target

Backup

mysqldump

MySQL Enterprise Backup

Backups are up to 3.5x Faster than MySQL Dump

High Performance Restore

0

20

40

60

80

100

120

140

26GB - 8 Tables 32GB - 33 tables

Min

ute

s

Restore Target

Restore

mysqldump

MySQL Enterprise Backup

Restore is up to 16x Faster than MySQL Dump

- mysqldump performance is non-linear (more table/indexes impacts performance)

- MySQL Enterprise performance is near linear

Backup Compression Storage Savings

0

5

10

15

20

25

30

35

22 GB - sysbench db

26GB - 8 Tables 32GB - 33 tables

GB

Backup Compression

Uncompressed

Compressed

Backup size reduced from 65% up to 93%

Database Backup Types Advantages & Disadvantages

MySQL Backup Tools

• Hot Backup (online)

– MySQL Enterprise Backup

• Export/Import (portable copies – a logical backup)

– mysqldump

• Standby Copy (hot swap)

• MySQL Replication

• Cold Backup (offline)

– Simple File Copies when server is shutdown

• File System Volume Managers (snapshots)

– LVM for example - create snapshot copy

mysqldump

• Advantages

– Good for small databases or tables

– Good assurance that database files are not corrupt

– Logical Backup – thus flexible and portable

• Disadvantages

– Very slow restore times

– Uses database processing cycles and resources

– Not Online (requires Transaction or Locks on Tables in the

database)

– Not Incremental (requires a Full Backup every time)

– Not Consistent (unless transaction is used)

MySQL Replication

• Advantages

– Rolling “snapshot”

– Quick Recovery - via failover

– Non-Blocking

– Works well in conjunction with other backup options

• Disadvantages

– Only latest “Point in Time” (point it time keeps moving forward)

– Not historical

– Not for archival purposes

– Doesn’t protect from “oops”

LVM Snapshots

• Advantages

– Quick

– Feature of Linux

– Good to use in conjunction with backups

• Disadvantages

– It’s a snapshot

– Still need to make a backup copy – which is “full” in size

– Performance degrades with each concurrent snapshot

– Snapshots need to be released

– Cross File System Limitations

MySQL Enterprise Backup

• Advantages

– Physical Backup so Fast – esp. restores

– Flexible - many options

– Archival

– Scalable

– Consistent

– Supported

• Disadvantages

• Requires some planning

MySQL Backup Types: Comparison

mysqldump LVM Snapshots MySQL

Replication

MySQL Enterprise

Backup

Full Backup

✔ ✔ ✔ ✔

Incremental

Backups ✖ ✔ ✖ ✔

Partial Backups ✔ ✖ ✖ ✔

Compression

Support ✖ ✖ ✖ ✔

Allows updates ✖ ✖ ✔ ✔

Point in Time -

Consistent ✖ ✔ ✔ ✔

Backup Speed Poor Good Very Good Very Good

Recovery Speed Very Poor Good Very Good Very Good

Partial Restore ✔ ✖ ✖ ✔

Corruption

Detection ✔ ✖ ✖ ✔

Meets Regulatory

Archive Req. ✔ ✖ ✖ ✔

Supports DDL ✔ ✖ ✖ ✔

MySQL Enterprise Backup How it Works

MySQL Enterprise Backup

Media Manager (like Oracle Secure Backup)

Database

Quickly

Accessible

Disk Storage

Tape Archive

Intrinsic knowledge of database file formats

• Block Validation

• Tablespace/Data file recovery

• Unused Block Compression

• Consistent Recovery

• File Compression

• MySQL Enterprise Backup CLI

• MySQL Enterprise Monitor

• Oracle Secure Backup

MySQL Enterprise Backup: Terms

• mysqlbackup : backup executable which includes InnoDB, MyISAM

and other MySQL Data. mysqlbackup is a compatible replacement for

the innobackup post 3.5.1 and includes additional features and

capabilites

• ibbackup: finer grained raw innodb backup executable for innodb

files alone

• binlog: contains database changes – eg DDL and DML

• LSN: Log Sequence Number – the unique monotonically increasing

id for each change in the binlog

• Ibdata: system tablespace files

• .ibd: single table space file

How it Works: Backup for InnoDB

• Step 1: Backing Up InnoDB Data Files

– Copies and compresses InnoDB data files

• System Database (ibdata) & Single-table Tablespaces (.ibd)

– Produces “Fuzzy Backup

• Backup of data files doesn’t correspond to any specific log

sequence number (LSN)

• Different database pages are copied at varying times

MEB Backup Files

MySQL Database Files

1. InnoDB Tables & Indexes

ibbackup

How it Works: Backing Up InnoDB Data Files

InnoDB data file

compressed data file

data L

S

N data

L

S

N data

L

S

N data

L

S

N data

L

S

N data

L

S

N data

L

S

N

Newest LSN Oldest LSN

data L

S

N data

L

S

N data

L

S

N data

L

S

N data

L

S

N data

L

S

N data

L

S

N

• Backup files size is reduced by 70%

– Omits unused storage in each block, empty pages

• Produces “Fuzzy Backup”

• Notes earliest and latest Log Sequence Number (LSN)

How it Works: Backup for InnoDB

• Step 2: Backing up InnoDB Log Files

– Copies Log Records accumulated during data file copy

– All redo records with LSNs during data file copy

MEB Backup Files

MySQL Database Files

ibbackup

1. InnoDB Tables & Indexes

2. Log Files

How it Works: Backing up InnoDB Log Files

• Copies portion of the log file that contains all required redo information

• Covers the time from beginning to end of data backup

• Recovers all data blocks modified after copied to compressed data file

Log File

ibbackup_logfile

Log file w/relevant redo L S N

L S N

Newest LSN Oldest LSN

Last needed redo info

Earliest needed redo info

redo info

L

S

N

redo info

L

S

N

redo info

L

S

N

redo info

L

S

N

redo info

L

S

N

redo info

L

S

N

Full & Partial Backups

• Backup contains all tables in

system tablespace

– Plus those separate tables that

match the pattern

• When using “file per table”,

you can backup a subset of

InnoDB tables

– Tables included in the backup

are specified with regular

expressions

– Use the -- include option

Multiple tables &

indexes in the

system tablespace

(ibdata files)

Table A

Table B

Table C

One table &

indexes per file

(.ibd files)

Table D

Table E

Table F

Full Backup

Partial Backup

mysqlbackup (innobackup) Examples

• Full Backup mysqlbackup --user=dba --password=xyz --compress /etc/my.cnf /backups

• Incremental Backup

– The backup only contains changed data mysqlbackup --incremental --lsn 2261747124 /etc/my.cnf /incr-backup

• Partial

– The backup contains tables in test database that match the .ib.* regular

expression. mysqlbackup --include 'test\.ib.*' /etc/my.cnf /backups

How mysqlbackup Works

Hot Backup Files

MySQL Database Files

InnoDB Tables & Indexes

mysqlbackup

MyISAM

Tables & Indexes,

.frm, & .mrg files

SQL

MySQL Command-line

Client

SQL: “FLUSH TABLES

WITH READ LOCK”

MySQL

Server Flush, Lock

Tips: InnoDB and MyISAM Backup

• InnoDB tables are fully accessible during backup

– Insert, Update & Delete

• MyISAM tables cannot be updated during backup

– Uses FLUSH TABLES WITH READ LOCK near the end of the

backup

• Works best if …

– Wait for insert/update/delete transactions during MyISAM backup

– Do not run long SELECT queries during the backup

– MyISAM tables are small, thus copied quickly

Tips: “Raw Backup” Files

Compressed copy of

InnoDB data file(s)

ibbackup_logfile

Copy of MyISAM, frm, .mrg files

Raw Backup Files

• The “raw backup” files from backup phase cannot be

directly consumed by MySQL

• These files can be copied to media

• The database must be “restored” first

• Use mysqlbackup to restore database before use

How it Works: Restoring a Database

InnoDB data files

1. Uncompresses InnoDB files to data dir

2. Recreates InnoDB Log files

3. Applies log, so InnoDB files are consistent

4. Restores MyISAM and other files

MySQL data dir

ibbackup_logfile

log files

Compressed copy of

InnoDB data file(s)

Copy of MyISAM, frm, .mrg files

MyISAM, .frm, .mrg

files

Restoring a Database Con’t…

• MEB restore rolls forward data files to a common

point in time (the time at the end of backup)

• After restore, MEB Backup prints the location in the

binlog for the next SQL operation that executed after

the backup completed

• Note: the restore phase need not run on database

server host

– You can perform recovery on any machine, and copy

recovered files to your database server host

Backup and Roll forward “Log” Recovery

• Also known as log archiving or log backups

• Add executing mysqlbinlog to copy logs to your full

and incremental backup schedules

• Restore Full and Incremental as previously described

• Roll forward using binlog from the final lsn to the lsn

for the desired recovery point in time

Roll Forward Backup and Recovery

• Log Backup

– Use mysqlbinlog to make a continuous backup of the binary

log

– mysqlbinlog --read-from-remote-server --host=host_name --

raw --stop-never binlog.000999

• Restore

– If data loss occurs (for example, if the server crashes), restore

the most recent MEB backup

– Edit output file to truncate at desired point

– Note end lsn and use for roll forward start position

• mysqlbinlog --start-position=27284 binlog.001002

binlog.001003 binlog.001004 | mysql --host=host_name -u

root -p

Summary MySQL Enterprise Backup

•Offers best performance for backup

•Offers best performance for restore

•Adds minimal load to MySQL server

•No impact on application (online backup)

•Easily integratable into you environment

Additional Resources

• Product Information http://www.mysql.com/products/enterprise/backup.html

• Documentation http://dev.mysql.com/doc/mysql-enterprise-backup/3.5/en/index.html

• Backup Forum http://forums.mysql.com/list.php?28

• Download (30 Day Trial) http://edelivery.oracle.com/

Q U E S T I O N S A N S W E R S