Introduction to Backup and RestoreΒΆ
The architecture of the server farm follows tha assumption, that hosts and applications can alway be rebuild and therefore don't have to be backed up. Only the customer data (files and databases) can not be rebuild and therefore need to be backed up.
There is a first level of backup which is provided by each ISP that provides hosting facilities and while those backups are available, a host can always be rebuild including the customer data from those backups - often available as images.
However, the strategy of putting all eggs into one basket is fairly dangerous. As we saw recently, hosting companies can become insolvent and if that happens without prior notice, not only are the live hosts inaccessible at that point, the same is the case for the backups: both is gone and that forever.
What had to be learned from this incident and was built into this server farm from day one is the need for off-site backups. This is what we describe in this chapter as well as how to restore the data from those backups when needed again.
To make sure we have the right things in mind, here is again a simple overview that determines what needs to be backed up. The different components of a live host are:
- Hardware: provided by the ISP and reproducable/replaceable
- OS: installed from third party sources
- Services: Apache, MySQL, PHP, modules, firewall, logging and many many more. All of them are installed from third party sources
- Applications: e.g. Drupal, installed from drupal.org
- Customer development: installed from a Git repository which is hosted elsewehere
- Database tables and records: they need to be backed up
- Customer files: e.g. images, pdfs and other uploaded files. THey also need to be backed up
That means, our backup strategy focuses on the latter two only: databse content and customer files. Everything else is going to be available from other sources at any time.