Your DevOps team continuously makes changes to configurations, adds new software, and creates cloud volumes. Are these rapid changes reflected in your backups? If not, an outage could lead to days or weeks of lost work. Using an advanced data center infrastructure management (DCIM) application, you can record changes at a faster rate and make sure your inventory keeps up with the pace of your development.
What are the challenges involving DevOps and backups?
Continuous development has gained wide adoption, with approximately 86% of organizations subscribing to this methodology, with varying degrees of success. The entire organization needs to keep pace with DevOps in order for the methodology to work, including QA and disaster recovery (DR). Yet 46% of DevOps adopters say that resistance to change is holding them back.
DevOps and backups can clash in a number of ways. First, there’s the possibility that a new release is flawed in some way. DevOps teams often take a “fail fast” approach in which they write new features quickly and then use multiple testing iterations to refine their code until it no longer fails. If QA can’t conduct their testing fast enough, then either the pace of development slows down or buggy code makes it into the production environment. This in turn increases the likelihood of unplanned downtime followed by a restore from backup.
In addition, as we’ve already discussed, changes made as part of the DevOps process needs to make it into backup and recovery. This means creating some kind of continuous backup system as opposed to weekly full backups. Changing the way that an organization backs up and restores data may seem like a big obstacle to overcome, but the fact is that the tools often used by DevOps teams can also improve and streamline the disaster recovery process.
Applying the DevOps philosophy to disaster recovery
Right now, disaster recovery plans often become obsolete as soon as they’re introduced. They’re created as part of an operational readiness check during implementation, but 58% of organizations test these plans once a year or less. This is hardly in the spirit of testing with DevOps, which emphasizes constant testing along many avenues of approach.
By contrast, DevOps tools make it much easier to provision and test disaster recovery volumes. Tools like Chef and Puppet are designed to automatically configure virtual machines and deploy them to any environment including clouds, data centers, and endpoints. The same tools that allow developers to rapidly deploy code under DevOps can also be used to rapidly provision and deploy recovery volumes.
For example, a good approach is to run an automated backup right before deploying into production. Tools such as Duplicity can be integrated with the CI/CD pipeline to create a snapshot of an application right before a new version deploys. This specifically captures incremental changes to the application, including new configurations and data files. This makes it easy, at least in theory, to roll back a new update quickly in case anything goes wrong.
Simply applying DevOps tools to the problem isn’t a guarantee of success, however. Certain environments, such as some non-relational databases, make it very difficult to capture consistent backups. Other times, human error persists. DevOps tools won’t help you if you forget to backup certain volumes or test backups at regular intervals.
DR plans tend to fall further and further out of date as work on the application progresses. During recovery, it’s very possible that the database will encounter a conflict because it specifies an application with a lower version number. DevOps tools can’t solve this problem on their own. Even though DevOps makes it faster and easier to deploy applications from backup, organizations still need a way to reconcile outdated DR plans with the realities of their existing applications.
Bridging the gap between DevOps and backups with advanced DCIM
Device42 contains several integrations with important DevOps tools. This makes it an important bridge between DevOps and disaster recovery, because you can use it to automatically record changes in your application environment. This helps you to understand when your disaster recovery plans are out of date.
For example, Device42 integrates with Jenkins to create a new software object with versioning every time you execute a build job. As far as backups are concerned, this means you can compare the version number of the application you’re snapshotting to the version number of the application you’ve just deployed into production. If those don’t reconcile, then it’s time to update your plans once again.
Device42 makes it easier for you to compile information about your applications in a single place and then compare it to your backup plans. This enables you to update your readiness for disaster recovery in an increasingly fast-pace development environment. To learn more about how Device42 can help your DevOps be robust, download our 30-day free demo today.