7.3.2. Using Backups for Recovery
Now, suppose that we have a catastrophic crash on Wednesday at 8 a.m. that requires recovery from
backups. To recover, first we restore the last full backup we have (the one from Sunday 1 p.m.). The
full backup file is just a set of SQL statements, so restoring it is very easy:
shell>
mysql < backup_sunday_1_PM.sql
At this point, the data is restored to its state as of Sunday 1 p.m.. To restore the changes made since
then, we must use the incremental backups; that is, the
bin.000008
process their contents like this:
shell>
mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql
We now have recovered the data to its state as of Tuesday 1 p.m., but still are missing the changes
from that date to the date of the crash. To not lose them, we would have needed to have the MySQL
server store its MySQL binary logs into a safe location (RAID disks, SAN, ...) different from the place
where it stores its data files, so that these logs were not on the destroyed disk. (That is, we can start
the server with a
the one on which the data directory resides. That way, the logs are safe even if the device containing
the directory is lost.) If we had done this, we would have the
subsequent files) at hand, and we could apply them using
most recent data changes with no loss up to the moment of the crash:
shell>
mysqlbinlog gbichot2-bin.000009 ... | mysql
For more information about using
Time (Incremental) Recovery Using the Binary
7.3.3. Backup Strategy Summary
In case of an operating system crash or power failure,
But to make sure that you can sleep well, observe the following guidelines:
• Always run the MySQL server with the
bin=log_name
drive on which the data directory is located. If you have such safe media, this technique can also be
good for disk load balancing (which results in a performance improvement).
• Make periodic full backups, using the
"Establishing a Backup
• Make periodic incremental backups by flushing the logs with
logs.
7.4. Using
mysqldump
This section describes how to use
dump file can be used in several ways:
• As a backup to enable data recovery in case of data loss.
• As a source of data for setting up replication slaves.
• As a source of data for experimentation:
Using Backups for Recovery
description for the
verified before deleting the MySQL binary logs. See
Syntax".
BINARY LOGS
binary log files. Fetch the files if necessary from where they were backed up, and then
[1467]
option that specifies a location on a different physical device from
--log-bin
mysqlbinlog
[1467], where the log file name is located on some safe media different from the
Policy", that makes an online, nonblocking backup.
for Backups
mysqldump
PURGE BINARY LOGS
gbichot2-bin.000007
gbichot2-bin.000009
mysqlbinlog
to process binary log files, see
Log".
InnoDB
[1467]
--log-bin
command shown earlier in
mysqldump
to produce dump files, and how to reload dump files. A
625
statement explains what should be
Section 13.4.1.1,
and
and
mysql
Section 7.5, "Point-in-
itself does all the job of recovering data.
option, or even
--log-
Section 7.3.1,
or
FLUSH LOGS
mysqladmin flush-
"PURGE
gbichot2-
file (and any
to restore the
Need help?
Do you have a question about the 5.0 and is the answer not in the manual?
Questions and answers