(mysql.info) backup-recovery
Info Catalog
(mysql.info) backup-policy
(mysql.info) backup-strategy-example
(mysql.info) backup-strategy-summary
5.10.2.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 `gbichot2-bin.000007' and `gbichot2-bin.000008'
binary log files. Fetch the files if necessary from where they were
backed up, and then 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 -log-bin option that specifies a location on a different
physical device from 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 `gbichot2-bin.000009'
file at hand, and we could apply it using `mysqlbinlog' and `mysql' to
restore the most recent data changes with no loss up to the moment of
the crash.
Info Catalog
(mysql.info) backup-policy
(mysql.info) backup-strategy-example
(mysql.info) backup-strategy-summary
automatically generated byinfo2html