We’re in an interesting time in the backup industry. With the advent of the cloud as a storage location for backups, along with virtualization, and really great compression and deduplication technologies, it can be really confusing when trying to choose the right solution. So many vendors telling you they’re way of doing backups is the way. There’s so much noise, it can be a bit deafening.
You might be asking yourself questions like:
…and the list goes on.
So rather than trying to pitch you a particular solution, let’s work backwards from your needs using a few questions to help you at least hone in on what’s important to you. That way, you’ll know what you do and don’t want as you look for the right solution. By doing this, you ignore the noise and figure out what criteria is critical to your organization when selecting a backup and recovery solution.
I would suspect most of you are thinking of an answer in terms of an application, a service, or an entire system. But it may be that, from a backup and recovery perspective, you need to be aware of how those needs get recovered – at an OS, apps, data, or entire system level – and whether a backup solution has the ability to be that granular. For example, if you want to recover your Exchange server, but the solution you use isn’t application aware, you either need to backup at an image level or at a combination of system state and file level. And the mix of the backup method chosen with what you want recovered may have implications at recovery time that may impact how quickly you can recover. (For example, recovering an image of an Exchange server won’t necessarily put the databases in a consistent state, requiring a second recovery of the databases.)
To choose the right solution, build a list of what you want to recover (systems, applications, and files) and identify a solution that provides you the ability to not just backup those data sets, but can easily recover them in as close to a single step as is possible.
Think about the “disasters” you need to protect against. They could be as simple as a critical application failing, or as complex as a chemical spill outside the building or a natural disaster, both requiring an evacuation. If you start taking that perspective, you quickly realize that one backup of a given data set won’t necessarily protect you against every disaster. Backing up that Exchange server on-premise won’t help you when there’s a fire and the entire building goes up in flames.
To choose the right solution, build a list of the disasters your organization needs to be able to recover from. Remember it can be a simple hardware failure, a loss of Internet access, or something worse making your building unusable. Then identify a solution that provides an ability to recover whether you need to recover on-premise, at a remote data center, or somewhere in the cloud.
This one is about both backup and recovery times. Backup windows need to be small to allow for frequent backup sets, so great change tracking, deduplication, and compression methods need to be employed. But more important are even shorter recovery windows (everyone wants it up and running now, don’t they?). So, thinking about what your needs are with regard to speed will isolate those backup solutions that run solely on-premise or in the cloud, as they may not be able to help you recover as quickly as you need.
To choose the right solution, take those previously defined data sets (probably cross-referenced with the “disasters” you want to protect against) and apply RTOs and RPOs to each. These alone are going to help dictate how often you’ll need to back up, whether you will be requiring the use of virtualization or not at recovery time, and whether use of the cloud needs to be a part of not just your backup storage strategy, but as an actual recovery target (more on this in a bit).
There are a few schools of thought on the debate of backing up using virtualization. For some, virtualization is a perfect fit, given its ability to quickly recover an entire system (or, as in the case of continuous recovery, always be up to date and ready to recover instantly).
To choose the right solution, think about whether you want to rely on file-based backups, bare metal recovery, or the use of VDR, V2V, Standby Images, or Continuous recovery as you identify a solution.
This somewhat goes back to what disasters you’re protecting against. If it’s a loss of location, you need a solution that backs up to the cloud (so you can recover to a remote site or in the cloud as well). If it involves a loss of Internet, you need a solution that runs on-premise so you’re not reliant on the cloud.
To choose the right solution, you need to identify the cloud’s role in your recover strategy - Is it just for storage of backups? A recovery target? A hot standby location via virtualization? – and then determine if the backup solution you want supports your ability to recover both on-premise and in the cloud as you see fit.
With so much concern around data theft and compliance, backups need to be secure. Should you employ placing cloud-based backups (whether file or image-based), you need to be concerned about the security of that data from the time it leaves the walls of your organization.
To choose the right solution, you need to be thinking about what the solution in question provides from the perspective of encryption in transit, encryption at rest (both in the cloud and on-premise), who has access to the private key, where in the world the data is physically stored, and can the data be extradited.
Instead of becoming enamored by cool features and dazzling technology, by stepping back and looking closely at what your company actually needs to accomplish with backup and recovery, you’ll have a shopping list of sorts that defines what you need in a solution. Then you can take this list out for a spin and simply match a solution up against your list and identify which one most closely meets your needs.
Also try downloading our Recovery Decision Map wall chart to help you make the decision…
Get the latest MSP tips, tricks, and ideas sent to your inbox each week.