Since 2000, ServerCentral has evaluated countless technologies to identify the best possible solutions and business practices to help our customers and partners address all of the critical elements of their IT infrastructure.
Now more than ever, questions about backup, replication and disaster recovery are top of mind.
Whether it’s supporting one company’s need to provide high-availability, always-on solutions or helping another company determine the right level of continuity for their business, we’re having these conversations on a daily basis.
In these conversations, we always present our view of backup and disaster recovery within a larger context—that of a business continuity continuum.
Single-Site Backup <> Multi-Site Backup <> Replication <> Disaster Recovery
Do we have the only view on BC/DR? No. We don’t expect to.
What we do have is a tremendous amount of experience developed from a group of customers with whom we work on a daily basis to develop the best solutions for their ever changing needs.
Here’s how we typically approach these conversations.
We begin with a two-part question: What are your RTO & RPO objectives?
When we speak about Recovery Time Objectives (RTO), we’re typically speaking about the time required for the resumption of core IT activities after an issue has occurred.
When we speak about Recovery Point Objectives (RPO), we’re typically speaking about data-driven applications, where the data and the application process must stay in sync (eCommerce, for instance). In most instances, RPOs are assigned to applications that have direct revenue impact.
We ask these as two separate questions because the application and process requirements significantly differ with RTO and RPO.
Which services are easy to prepare for and manage? Anything virtualized/clustered/software with support for failure scenarios such as email, for example.
Which services are difficult to prepare for and manage? Old/End-of-Life software, homegrown or legacy apps not coded for redundancy. Physical servers with older OSs which may have certain BIOS requirements, RAM requirements, with drivers for older hard drives interfaces (ATA or SCSI which may not be easily available, for example).
Single and Multi-Site Backups
When single-site or multi-site backup is presented as the critical requirement, it’s important to note how applications, data, and VMs are backed up now. This seems obvious—and it is—but it’s also very important. In many instances the backup processes for applications vary wildly by application and by organization. Within some multi-site organizations, the process will vary significantly by location.
Where you back up is as important as what you’re backing up.
Some companies backup locally, on-site. Others backup to tapes which are then stored offsite. While these are both strong starts, they fail to capitalize on managed solutions that are easily configured to deliver automated backups to a high-availability target at a high-availability data center. Supported by solutions from CommVault and Veeam, these types of solutions provide backups of data, applications and VMs while offering the ability to quickly restore with live data from high-availability facilities in the event of an emergency.
Typically, big companies are associated with big DR, while small companies are associated with smaller requirements like backup. In our experience, this isn’t true.
The RTO and RPO for your services will be unique to your business, dependent fully upon the revenue and operational implications of downtime. These values will dictate just how big your small backup requirements will be.
Once backup questions are answered, the next step is typically replication. Replication can mean many things: having multiple SANs in sync, keeping copies of images or file server backups available in multiple locations, and so on. Many companies address backup and replication in one step—but many don’t.
The critical aspect of replication is that it is happening in multiple high-availability data centers on high-availability/high-performance infrastructure.
As we continue talking about replication, we’re also talking about the need to accelerate the movement of data. Compression, deduplication, etc. all become critical pieces of the puzzle.
Deduplication specifically helps in three places:
- On the backup client which prevents sending the data to the backup server twice;
- On the storage platform, to optimize the use of disk space; and
- By optimizing caching on reads.
For example, if a company’s servers use a common OS or a base image, they only need one copy in cache to optimize the resource and expedite recovery.
Equally critical to the underlying storage infrastructure is the network infrastructure. We touched on this above regarding de-duplication, but it is worth highlighting in a bit more detail as it is often overlooked as a critical success factor in BC/DR strategies.
As you can see here, there are very serious ramifications between a 1 Gbe and a 10 Gbe network connection when it comes to a restore operation.
|NOTE:||These are best-case scenarios for a local transfer. This means public, network-based transfers are going to see significant degradation in performance.|
Something to think about when you’re discussing your BC/DR strategy.
When we begin speaking about disaster recovery, in almost all cases, it is a much larger conversation. There are significant operational, compliance, and financial implications. There are some powerful solutions on the market from companies like Zerto that provide a foundation for near active-active configurations, but they depend heavily upon the virtualization configurations.
To make a very long story short, this is where the right people from your company and ServerCentral need to get to a whiteboard.
A worthwhile trick for disaster recovery:
If you know ServerCentral, you know we’re always happy to share what we learn. In this particular instance, we have a very nice trick many of our customers use to address the bandwidth issue:
Configure VM restores directly to a DR infrastructure.
With hypervisors ready to go at a DR site, simply boot the backup images and you’re back in business. These can be dedicated or shared compute and storage resources depending upon the requirements.
It’s easy to get deep into the technology and architectures when discussing business continuity. However, it’s important to ground everything on the importance of each service to your business. What is the cost of having each service down? What are acceptable recovery timeframes for each service?
It is only when these baselines are set and recognized across your organization that the decision on how to back up, replicate, and/or restore your services can be fully made.
The good news? The technology today is available to make these DR processes much less painful than they were a few years ago.
Additionally, as more organizations write redundant, scalable software designed for cloud environments, and as more governments mandate DR testing for banks and other critical infrastructure, this technology is going to be pushed forward for everyone.
When it’s time for you to start your BC/DR conversation, no matter where you are on the continuum, we’ll be here.