Backing Up and Restoring Databases - Learning MySQL and MariaDB - page 370

conservation_status
habitat_codes
The next three columns of Table14-3 are related to testing and practicing restoring data.
Once a month, we will try to restore the databases made in the full backups. You could
test this by restoring each database to a test server. Then you can execute queries on the
live and the test server to compare the results. Just keep in mind that the data will be a
little different on the live server.
The other backup dump files are based on tables. These tables change often or are large
and critical to our bird-watchers site. So we'll test restoring tables from these dump files
twice a month. For all of the backups, we'll try twice a month to restore individual rows.
This is the type of restoration we will be most likely to do. It's important that we know
how to restore very specific data from all of our dump files. With this much practice,
restoring a minor loss of data when needed won't be much trouble for us.
The last column in the table has to do with retention: how long we will retain the dump
files. Our plan is to keep the dump files for the full backups for two months and the ones
for specific tables only one month. You might not want to keep them that long, or maybe
you will want to keep them longer. Some people copy dump files to CDs for each month
and then store them for years.
Tables 14-2 and 14-3 basically represent our backup policy. One table lists what we will
back up, when, and where. The other lists when we will verify that the backups are per-
formed successfully, when we will perform restoration drills, and how long we will retain
the backups. There are other factors you could put into a backup policy and much more
detail. However, this should give you a sense of one way you might develop a backup
policy.