When thinking about disaster recovery and protecting backup data, we always want to have more than one source of being able to restore our production systems. There is an industry suggested standard of the 3–2–1 rule that says we ideally have three copies of our data on two different mediums, and one offsite copy of that backup data. This rule of thumb that is used often helps us to appreciate that we want to diversify our backup sources so that we don’t have all of our recovery options relying on one source, medium, or backup location. This is extremely important to consider when thinking about building our disaster recovery plans and thinking through how to design our backup strategy. We want to dive a bit deeper into the offsite backup aspect of our backup solution as it is critically important. What are some disaster recovery scenarios that make having offsite backups important? What are some technologies that we can use for offsite backup? How do we implement offsite backup?
Disaster Recovery Reasons to Having Offsite Backup
When we think about normal disaster recovery scenarios, the typical disaster of losing an environment in a location due to hardware failure or perhaps unintentional data loss may come to mind. However, when we think about the perhaps rarer occurrence of losing a site due to a natural disaster or even a widespread Ransomware event, being unprepared for these types of disaster scenarios can literally damage a company to the point of losing or even going out of business due to the financial and/or brand reputation impact. Businesses today must prepare for any disaster recovery scenario including losing an entire physical location.
There are technologies that allow us to be resilient in the event of a site failure. Thinking about the 3–2–1 rule, we need to have multiple copies of our data (first of the 3–2–1 rule). In NAKIVO Backup & Replication v7.1 we can create backup copy and replication jobs which allow us to create a secondary copy of our data. With NAKIVO as well we can also place a copy of our backups in the cloud which is yet another failsafe for multiple copies of data.
Backup Copy Job
With a Backup Copy job, this data can be stored locally on another backup server in the same site. However, to realize the full benefit of a backup copy, ideally, we would want this copy to reside in another location connected via the network either LAN or WAN bases technologies. This way we have a copy of our backup data that is offsite which satisfies the last of the 3–2–1 rule. Backup copy jobs are easily setup using the NAKIVO Backup & Replication v7.1 interface.
First, we select the VM for which we want to setup a backup copy job.
Next, is the important detail of the backup copy job configuration when we are thinking about setting up an offsite backup location for our VM — where is the data located? Below we are choosing the DR Repo which in the environment below, is an offsite backup repository.
Also, with NAKIVO Backup & Replication we can choose to run the backup copy job immediately following a successful run of our primary backup job from production. This ensures that we always have the latest backup restore point copied over to our offsite repository.
We can select our retention period for the backup copy. The default as you can see below is to keep an exact copy of the source backup restore points. If we select this option, the recovery points retention of the source backup will be applied. If unselected, it keeps the restore points based on its own retention policy. So it is either synchronous or asynchronous retention points.
Finally, we can enable other options such as Network acceleration and Encryption which aid in both performance and the security of our data copied to the offsite backup repository.
Once our backup copy job runs and creates an identical copy of our backup data to an offsite backup repository, we now have diversified our backup data between sites.
We can’t talk about site resiliency and offsite backups without talking about replication. Replication allows us to create a standby replica VM to the virtual machine running in production. In a best practice scenario, the standby replica VM can/should be offsite so that we have site failure resiliency. If we lose an entire site, we can failover to the standby replica VM that is already provisioned in the offsite DR facility. Let’s look at how easy it is to set up a replication job in NAKIVO Backup & Replication v7.1.
First, we select the VM that we want to replicate.
As far as the Destination, again, the key for us in thinking about offsite backups and resiliency is making sure our destination VMware environment and datastore is positioned in a separate site.
We can schedule the replica VM to be created/updated after another job runs, such as the primary backup job.
With the retention on a replica VM, this is accomplished via snapshots at the points in time the replication process runs. We can specify how many snapshots/retention points we want to keep.
Finally, we can choose a number of options to control the performance and security of the replication job such as network acceleration and in-flight encryption. Here we also name our resulting replica VM, set email options, and execute any pre and post job scripts.
The replica VM is created in the offsite VMware vSphere cluster that is located in our DR facility.
Offsite Backup to Cloud
One of the deterrents for many enterprise environments with offsite backup copies or offsite replica VMs is the hardware, infrastructure, and facilities fiscal investment it takes to make those mechanisms possible. With that in mind, one of the powerful features in NAKIVO Backup & Replication v7.1 is the ability to backup to the cloud. With cloud backups, you don’t have the investment in the hardware, facilities, and other infrastructures as all of these are taken care of by the cloud provider. Additionally, your backup space demands can change as you need them to. With the click of a button you can provision more space. With NAKIVO’s forever incremental backups, global deduplication, and network acceleration, space is delivered and utilized in the cloud as efficiently as possible.
To aid in the cloud provisioning process, NAKIVO offers cloud instances of NAKIVO Backup & Replication appliances in AWS that allow for quickly provisioning an instance of NAKIVO Backup & Replication in the cloud.
Administrators have the same powerful feature set for cloud backups with NAKIVO as they have running it on premise. Cloud repositories can be encrypted with AES 256 bit encryption for secure data at rest. AWS EC2 firewall rules can be utilized as well for additional security so that only allowed remote IP’s can access your cloud datastore. Additionally, in-flight encryption can be selected in the options of the backup job or backup copy job being transferred to the cloud repository so that data is secure over the wire as well.
NAKIVO Backup & Replication allows for cloud diversity as well. It can also be integrated into Microsoft’s Azure cloud environment. This can be accomplished by either deploying a Transporter in Azure with a supported operating system and then using assigned local storage in Azure, or using Azure file storage over SMB file copies to a file share that is located in Azure via a Windows transporter service.
The first method allows for having both a cloud transporter and repository housed in Azure. In the second configuration, we are still utilizing an on-premise transporter and copying backup files to the file share that is provisioned to your cloud account.
Again, the end result is that we have offsite backups stored in the cloud which greatly improves resiliency from a DR perspective and protects us from data loss due to a site-wide failure.
We have looked at the well-known 3–2–1 backup rule that states we need to have at least (1) copy of our backups located offsite. Offsite backups help to protect us from a site-wide failure resulting in both production data loss but also potentially backup system data loss. NAKIVO Backup and Replication provides many mechanisms that help us to accomplish getting our production backup data offsite. Utilizing backup copies, we can ship a copy of our backup data, to an offsite backup repository. Using replication, we can create replica VMs in an offsite DR facility or other VMware vSphere environment. Finally, due to its strong cloud integration, NAKIVO Backup & Replication is able to seamlessly allow us to house backup data in the cloud — either AWS or Azure. The key for organizations is that we need to diversify where we have our backups and have multiple copies of backups and production systems. By doing this, we will be resilient, protected, and have extremely low RTO’s which will ensure business objectives.