Table Maintenance Incremental recovery is recovery of changes made during a given time span. This is also called point-in- time recovery because it makes a server’s state current up to a given time. Point-in-time recovery is based on the binary log and typically follows a full recovery from the backup files that restores the server to its state when the backup was made. Then the data changes written in the binary log files are applied as incremental recovery to redo data modifications and bring the server up to the desired point in time. Data integrity can be compromised if tables become corrupt. For  InnoDB  tables, this is not a typical issue. For programs to check  MyISAM  tables and repair them if problems are found, see Section 7.6, “MyISAM Table Maintenance and Crash Recovery” . Backup scheduling is valuable for automating backup procedures. Compression of backup output reduces space requirements, and encryption of the output provides better security against unauthorized access of backed-up data. MySQL itself does not provide these capabilities. The MySQL Enterprise Backup product can compress  InnoDB  backups, and compression or encryption of backup output can be achieved using file system utilities. Other third-party solutions may be available. This section summarizes some general methods for making backups. Customers of MySQL Enterprise Edition can use the MySQL Enterprise Backup product to do physical backups of entire instances or selected databases, tables, or both. This product includes features for incremental and compressed backups. Backing up the physical database files makes restore much faster than logical techniques such as the  mysqldump  command.  InnoDB  tables are copied using a hot backup mechanism. (Ideally, the  InnoDB  tables should represent a substantial majority of the data.) Tables from other storage engines are copied using a warm backup mechanism. For an overview of the MySQL Enterprise Backup product, see Section 30.2, “MySQL Enterprise Backup Overview” . The  mysqldump  program can make backups. It can back up all kinds of tables. (See Section 7.4, “Using mysqldump for Backups” .) For  InnoDB  tables, it is possible to perform an online backup that takes no locks on tables using the  -- single-transaction  option to  mysqldump . See Section 7.3.1, “Establishing a Backup Policy” . MyISAM tables can be backed up by copying table files ( *.MYD ,  *.MYI  files, and associated  *.sdi  files). To get a consistent backup, stop the server or lock and flush the relevant tables: You need only a read lock; this enables other clients to continue to query the tables while you are making a copy of the files in the database directory. The flush is needed to ensure that the all active index pages are written to disk before you start the backup. See Section 13.3.6, “LOCK TABLES and UNLOCK TABLES Statements” , and Section 13.7.8.3, “FLUSH Statement” . You can also create a binary backup simply by copying the table files, as long as the server isn’t updating anything. (But note that table file copying methods do not work if your database contains  InnoDB  tables. 1615 Making Backups by Copying Table Files Making Backups with mysqldump Making a Hot Backup with MySQL Enterprise Backup 7.2 Database Backup Methods Backup Scheduling, Compression, and Encryption Table Maintenance FLUSH TABLES  tbl_list  WITH READ LOCK;