Blog & Events

How to Backup DevOps?

Jul 5, 2018, 11:00 AM by Trenton Baker

devops cycle

Backups are about protecting data, applications, and systems that are important to the organization. In operations environments, it’s easy to provide backups: pick the workload that needs hyper-availability and back it up. Operations environments are relatively static – in that, the systems and applications used remain relatively consistent, with only the data changing daily.

Enterprise vs SMB devops Adoption

The DevOps Difference:

  • It’s On-Demand – Developers spin up VMs as needed, test new code, and delete the VM when done.
  • It’s Automated – Because developers need to focus on testing code and not the building of the environment in which to test the code, DevOps is all about leveraging automation to create, configure, and secure the dev environment.
  • It’s Complex – Your dev team may be testing their next-generation application that uses highly complex architectures, such as a write-anywhere non-relational database (which is nearly impossible to backup in a consistent state due to the architecture.
  • It’s Temporary – The environment exists to address the current needs of its users. Developer needs vary based on the code they’re currently working on. So, today’s environment may be completely different from tomorrow’s.

How do you backup a DevOps environment?

When it comes to the very temporal uses of the DevOps environment, the simple answer is you don’t. Well, at least not the temporary VMs used for code testing. Where IT needs to help DevOps with backups mostly revolves around protecting the DevOps infrastructure that Development uses to create their testing environment.

DevOps has a ton of VM infrastructure, automation scripts, CICD platforms, and even more making up the work environment. THAT needs protection, as it does remain relatively consistent with some daily changes. (sound familiar?)


Steps to backup DevOps:

  1. Work with Operations to define the environment – DevOps is a whole new world for IT. So, have those living in it define the systems, applications, and data that make up the environment infrastructure for DevOps.
  2. Define DevOps Recovery Requirements – Just as in designing your backup strategy for production, start with the needs of the business (in this case, DevOps). Speak with both Development and Operations to get both their perspectives on what’s essential (to define workload criticality tiers), how quickly recovery needs to take place (to define recovery objectives), and to go over specifics such as dependencies, hardware requirements, etc. This will provide context around what recovery needs to look like, allowing you to work backward to a backup strategy that can deliver at the time of recovery.
  3. Build out a Backup Strategy – based on the detail collected in the previous step, develop a backup plan. Keep in mind that operations may want to be responsible for the backup, recovery, or both, so, part of the strategy should include who will do the work, as well as what is being backed up. We all know this isn’t going to be as simple as three steps, but, at a high level, the work doesn’t get much more complex than this. The real trick to backing up DevOps is understanding exactly what needs to be backed up.

We all know this isn’t going to be as simple as three steps, but, at a high level, the work doesn’t get much more complex than this. The real trick to backing up DevOps is understanding exactly what needs to be backed up.


Disaster recovery environments as a DevOps workspace

The objective of DevOps is that developers test their apps in a copy of the production environment in which their code will run. Often virtual machines and container solutions like Docker running on individual laptops or desktops is the go-to test bed. Unfortunately, this type of containerized microservice does not entirely simulate the capacity constraints of a real-world production environment.

Some IT departments are further embracing DevOps on a deeper level. Developers are requesting access to the hot spare disaster recovery environment to mitigate the laptop or desktop constraints. Generally, midsize and larger organizations will have cloud-based backup infrastructures.

These cloud-based DR backups are almost exact carbon copies of the environments running critical production workloads and are available in case workloads need to be ported over in the event of a service disruption or a disaster.

If you think about it, there is a ready-made sandbox of valuable production data in your backups and replicas, just sitting idle and collecting dust. Is there a way for DevOps to take advantage of this hot spare DR workspace for testing and planning while also remaining available for its original DR purpose?

Disaster recovery environments as a DevOps workspace

Leveraged Data for DevOps

You can leverage backups and replicas to mitigate application deployment risks by testing in a secure and trusted, production-like environment. The KeepItSafe cloud allows organizations to create new instances and accelerate time-to-market innovations by leveraging an isolated, virtual sandbox for rapid application development and testing. Tools like Veeam DataLabs™ will provide a method for DevOps to dynamically spin up instances of the production environment as they design new features. This capability enables use cases beyond typical data protection scenarios, such as DevTest, DevOps, and DevSecOps, including security, forensics, and GDPR, HIPAA, and FINRA compliance testing.

For example use Veeam Backup & Replication™ to create isolated virtual environments to perform application-item recovery and validate VM backups and replicas. DataLabs will allow you to boot VMs directly within a backup or replica into a secure, isolated virtual environment without the need for provisioning storage capacity or a spare host. Veeam DataLabs features:

  • On-Demand Sandbox™ — Purpose-built to create isolated test environments.
  • On-Demand Sandbox for Storage Snapshots: Designed to leverage snapshots via Universal Storage APIs

The idea here is to have the idle capacity and resources doing something useful while not completely missing the purpose of its existence. With hypervisors and containers, a VM can be spun up and down in a matter of seconds along with the rest of the SDx (software-defined everything) environment. In most cases the data is already accessible to the environment, allowing for real-world testing on real data without long copying times. Should an emergent event occur, you can quickly shut down the virtual machines — and have your hot spares back to retain maximum production environment IT resiliency.

Expect more from your backup storage and disaster recovery (DR) resources. Your data is invaluable, KeepItSafe.


Readers of this blog post are also interested in this webinar:

The Role of the MSP in the Multi-Cloud

Get Your FREE
Market Analysis Brief!


Disaster Recovery Planning

Download a free Planning Guide

“Storage Switzerland details DR Planning from Good to Great”