Do You Need an On-Premises Storage Vault? Part 1: Understanding the basics

Data protection has traditionally involved an on-premises storage vault, but as data protection solutions evolve, this requirement is becoming increasingly optional. While doing away with on-premises storage vaults may help you eliminate some costs and complexity, it can open you up to risk as it removes an important layer of defense in the event of a disaster. Understanding how “cloud-first” data protection works is important to making informed decisions.

Why on-premises vaults exist

To understand the purpose of on-premises data protection vaults, we must first understand the “3-2-1” rule of data protection. This refers to maintaining three copies of your data, on two different mediums, with one copy maintained offsite. This rule is generally considered the industry-standard approach to backups.

The three copies of your data typically refer to a production copy, a copy in an on-premises data protection vault, and an offsite copy. The offsite copy is increasingly in the cloud, which makes the “at least two mediums” in the eye of the beholder.

Traditionally, the two mediums in question would be disk and tape. Whether or not the copy in the cloud is considered another medium depends on whether you want to examine why the “two mediums” clause exists.

Strictly speaking, you can have the production copy, the on-premises vault, and the cloud copy all running on disk. The point behind the two mediums is not fear of all disks failing at the same time. Instead, the point is that putting data on tape means, if malware got into your network and ruined both your production copy and your on-premises vault, the tapes are physically disconnected and unaffected. Depending on how your cloud data protection is set up, it can serve the same “air-gapped” purpose.

What’s worth noting here is the on-premises data protection vault should never be considered a separate medium from the production storage. This is because the purpose of the on-premises vault is not to provide disaster-proof data protection. Instead, on-premises data protection vaults exist to ensure that, in most cases where a restore is requested, that restore can happen almost instantly.

On-premises vaults can provide this near-instant restore capability in two ways. The first is by virtue of being on the same network as the production systems; an on-premises vault can restore data to those production systems faster than downloading that same data over what is typically a much slower internet connection.

Secondly, on-premises vaults can frequently be used to light up copies of a workload on an emergency basis, making them useful for coping with the failure of primary infrastructure. However, this capability should never be viewed as anything other than a convenience.

The ability to host a limited number of workloads on your on-premises data vault is not a disaster recovery capability. An actual disaster (such as a fire or flood) would take out the whole data center, including both the production compute capacity and the on-premises data vault. True disaster recovery capacity must exist offsite.

Another advantage of on-premises data vaults is they offer a place for workloads to back up to the point when the internet is down. This is of mixed value; the data isn’t going offsite, so it’s not disaster-proof. That said, it can and does help provide protection against failure of an individual infrastructure item, even if it can’t protect against a data-center-destroying disaster.

The flip side of this advantage is data protection solutions that back up workloads to an on-premises vault, before sending those workloads to the cloud, are also adding a delay in the process of getting those workloads offsite. This delay can be minimal, such as for solutions which utilize changed block tracking (CBT) technologies, or quite significant, such as those solutions that use the on-premises vault as a full-on cloud storage gateway (CSG).

Why on-premises vaults are optional

In general, only a small number of workloads typically need to be restored quickly with a recovery time objective (RTO) close to zero. (The RTO is a measure of the amount of time it takes to restore a workload to expected functionality; read this blog to find out how to calculate yours.)

For most workloads, if it takes a business day to pull the whole workload down from the cloud, it’s not a big problem. It’s annoying but doesn’t hugely impact the business.

Another consideration is that restoring full workloads from backups can be a rare event. There might be a request to pull an individual file out of a file server’s backups every other day, and maybe once a week someone might need to retrieve a configuration file from a virtual machine’s backup image. But with the right backup software, these restores are not only quick and simple, they can be done by the end users themselves. (SolarWinds^® Backup is designed to support this in a few different ways for ease-of-use purposes.)

In many cases, if you need to completely restore a workload from backup, it’s a disaster scenario. Either the local production copy is gone (dead SAN) or the data center is out of commission (flooding, for example). In such a scenario, you’d be using the planned disaster recovery infrastructure rather than restoring back to the on-premises location.

In today’s world, most of the time, this means bringing up a copy of the backup in the cloud, because running your own second site can be a rather expensive luxury these days.

 

Additional reading:

• What’s Your RTO/RPO and How Do You Calculate It?
• 3 Tips for Shrinking Your RTOs and RPOs
• Why Standardizing on Backup Could Help Your MSP Business

As part of your decision making, bear in mind that SolarWinds Backup offers tiered pricing based on the number of instances protected, and that pricing includes cloud storage. If you’re interested in giving it a try, you can do so here. 

Carrie Reber is senior product marketing manager for SolarWinds MSP.