After a recent hard disk failure happily resulted in zero data loss, we ponder on the vital role of backups.
Bad things happen, they are unavoidable. Whether it's human error or physical degradation, we can help you to manage your resources so that a problem does not turn into a catastrophe.
It's not enough to say, well, I think we have backups running, you need to have a working backup system that can cater for all eventualities.
What is your problem?
It's important when planning a backup strategy to think about what you are backing up for, what are the scenarios that you are looking to protect against.
Theft - complete loss or destruction of equipment
Hard disk failure
Accidental deletion - roll back to a previous working state
Systems not functioning - roll back to last known working state
Let's take the example of our test server, housed in our office, what could go wrong with it? It could be stolen - the hard disc is encrypted so all the data is safe, but we would need to be able to replace all the data from an off-site source. Hence, all of our server data, is backed up to an encrypted cloud backup service. Encrypted backups are also saved to an external hard disc in the office, which means that we can restore data faster than downloading from the cloud.
Backup & Migrate
That's great for the files, the codebase, but what about the databases? Websites function as a combination of files, the codebase, and a database, sometimes two databases. Fortunately, Drupal has a fantastic system for backing up and migrating databases, which forms an integral part of our workflow. Every website we build has a scheduled backup running and makes an automatic backup of the database at least once a day. Sometimes during the development process this can be as much as once an hour - if the development goes awry, we can easily roll back to our last working backup. We can also back up a database at the push of a button, if we think something is risky, we make a backup just in case, if it goes wrong, we can easily roll it back.
Backups are saved as files on the server and are therefore backed up using the same processes as the codebase. This means that our development sites could be back up and restored to their last working state quickly and easily. Not a process we want to happen, but it has proved that our systems work!
Hooray for Git!
The same database backup also runs on our live servers meaning every website we create has at least a daily database backup running. The codebase, however, is handled in a slightly different way. All of our website development happens on our local server, any new code is installed and tested on a local (office based) version, not visible to the world. This allows us to break things without breaking our clients' websites. Once new code has passed our tests, we commit it to a version control system called, rather unfortunately, "Git", this is then uploaded to a secure cloud-based system. From the cloud we finally push the new code to the live server.
Using this workflow allows us to save snapshots of the codebase every time we make a change. We can easily roll back to previous versions - and see clearly what changes have been made. It's an awesome system and gives us the freedom to make changes without worrying, even if your new code breaks something, that you can get back to where you came from.
Our Drupal 8 Workflow Rocks
The combination of Drupal's awesome backup system and using Git version control means that not only can we track changes and move backwards and forwards in development time, but every step of the process is backed up to systems in our office and in the cloud. No matter what happens, flood, theft or catastrophic hard disc failure, we have the robust systems in place to recover all of our files and our data.