Database Reference
In-Depth Information
make backups of them each day as well. For some people, full backups every day is easi-
est and preferred. But if you have very large databases and security and performance con-
cerns, full backups might not be the best choice. For this example, I want you to see al-
ternative ways in which you might organize a backup schedule.
For the fictitious bird-watchers website, our database contains many members in Europe
and the United States. Because bird-watching is a hobby for most people, most of our
traffic will be in the evenings. The times here are all Greenwich Mean Time and in the
morning. When it's 8:00 a.m. in London, the time of our first backup, it will be midnight
in San Francisco. Put another way, when it's late at night for our members that are the fur-
thest West, with the exception of a few we might have in the Pacific, we begin making our
backups. This should be a slow traffic time for our databases.
We will keep all backups on site and on two separate servers. We'll use
cron
to copy the
dump file automatically to the second server across our internal network. Additionally, we
will copy the weekly, full backups to a cloud server like DropBox or Google Drive in case
there is a fire or some other catastrophe destroying our servers in the same building.
Now that we have a plan about what and when we will backup, we need a plan to check
those backups to make sure they are being performed correctly (see
Table14-3
). This will
include not only looking to see whether the files are there, but trying to restore them. This
has the added advantage of giving us practice restoring databases. As mentioned several
times already, when there is an urgent situation in which you need to restore data, you
need to be ready and know what to do. It's difficult to become proficient in restoring data
during a crisis.
