It’s important to have a backup strategy to ensure you’re backing up the data you need, so that in the event of a recovery – whether from a server crash or other disaster – you can restore the data as quickly as possible.
We’ve identified four things you may want to consider when deciding what does and doesn’t need to be backed up.
1. Operating system – At Internap, we use operating system images pre-built and ready to go, to redeploy to a server at the drop of a hat. Using our portal and API, you can redeploy a server on demand in as little as seven minutes by deploying standardized operating system image. You don’t need to back up your operating system, because we’ve got that covered.
2. Operating system configuration files – You may want to back these up, as well as the applications you installed on your operating system, such as the web server or database service. A better way might be to use a configuration management system to deploy those applications, or deploy those configuration changes after you’ve installed the server. At Internap, we use a system called Chef, which is very common in the industry, and allows you to always ensure your server is configured the same every time, whether you’re restoring from a server crash or deploying new servers because you need additional capacity. So it’s not necessary to back up your operating system configuration in your applications.
3. Customer application code – This might be the actual content of your website, your Drupal application, or whatever is powering your site. If you use a deployment workflow, backing up your application may not be necessary, because you already keep a master copy in source control if you’re using a deployment workflow like this. For example, your developers, who are working independently, are pushing code in to a source control management system. You’re pushing out to test environments regularly and tracking changes. Later, when pushing to a staging environment, you’re testing preferably with live data and as close to your production environment as possible. Once you’re satisfied that everything works exactly as expected, you then push from that master copy into production. Where the dynamic content comes in, is when users are uploading into your production system. This could be as website visitors who are uploading files or posting comments to forums, or a web master or site administrator who is developing content within a content management system after you’ve deployed the application.
4. App & user data – Finally, you have the user data that comes with your application. This is the content generated after you’ve deployed it. This might be the files that users or site visitors upload, or content that your site administrator or webmaster has written within a content management system content generated after you’ve deployed it.
Once you’ve figured out exactly what needs to be backed up, you can choose the best method to protect your data. Whether you’re using simple scripts utilities or continuous data protection software, you can check against these four elements to see what you need to back up, and how and when, so that when it’s time to recover from a disaster or server crash, you can do it as quickly as possible.
