(mysql.info.gz) Backup recovery

Info Catalog

(mysql.info.gz) Backup policy

(mysql.info.gz) Backup strategy example

(mysql.info.gz) Backup strategy summary

 
 5.7.2.2 Using Backups for Recovery
 ..................................
 
 Now suppose that we have a catastrophic crash on Wednesday at 8 AM that
 requires recovery from backups.  To recover, first we restore the last
 full backup we have (the one from Sunday 1 PM). 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 PM. 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 them 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 PM, but
 still are missing the changes from that date to the date of the crash.
 To not miss 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 in the destroyed disk. (That is, we can start the server
 with a `--log-bin' option that specifies a location on a different
 physical device than the one on which the data directory resides. That
 way, the logs are not lost even if the device containing the directory
 is.)  If we had done this, we would have the `gbichot2-bin.000009' at
 hand, and we could apply it to restore the most recent data changes
 with no loss how it was at the moment of the crash.
 

Info Catalog

(mysql.info.gz) Backup policy

(mysql.info.gz) Backup strategy example

(mysql.info.gz) Backup strategy summary