back up subsets of tables and databases. In conjunction with the MySQL binary log, users can perform point-in-time recovery. MySQL Enterprise Backup is part of the MySQL Enterprise subscription. For more details, see Section 30.2, “MySQL Enterprise Backup Overview” . 

## Cold Backups 

If you can shut down the MySQL server, you can make a physical backup that consists of all files used by InnoDB  to manage its tables. Use the following procedure: 

1. Perform a slow shutdown of the MySQL server and make sure that it stops without errors. 

## Logical Backups Using mysqldump 

2. Copy all InnoDB  data files ( ibdata  files and .ibd  files) into a safe place. 

3. Copy all InnoDB  log files ( ib_logfile  files) to a safe place. 

4. Copy your my.cnf  configuration file or files to a safe place. 

In addition to physical backups, it is recommended that you regularly create logical backups by dumping your tables using mysqldump . A binary file might be corrupted without you noticing it. Dumped tables are stored into text files that are human-readable, so spotting table corruption becomes easier. Also, because the format is simpler, the chance for serious data corruption is smaller. mysqldump  also has a --single- transaction  option for making a consistent snapshot without locking out other clients. See Section 7.3.1, “Establishing a Backup Policy” . 

Replication works with InnoDB  tables, so you can use MySQL replication capabilities to keep a copy of your database at database sites requiring high availability. See Section 15.19, “InnoDB and MySQL Replication” . 

## 15.18.2 InnoDB Recovery 

## Point-in-Time Recovery 

This section describes InnoDB  recovery. Topics include: 

•Point-in-Time Recovery 

•Recovery from Data Corruption or Disk Failure 

•InnoDB Crash Recovery 

•Tablespace Discovery During Crash Recovery 

To recover an InnoDB  database to the present from the time at which the physical backup was made, you must run MySQL server with binary logging enabled, even before taking the backup. To achieve point-in- time recovery after restoring a backup, you can apply changes from the binary log that occurred after the backup was made. See Section 7.5, “Point-in-Time (Incremental) Recovery” . 

## Recovery from Data Corruption or Disk Failure 

If your database becomes corrupted or disk failure occurs, you must perform the recovery using a backup. In the case of corruption, first find a backup that is not corrupted. After restoring the base backup, do a point-in-time recovery from the binary log files using mysqlbinlog  and mysql  to restore the changes that occurred after the backup was made. 

