Cloud storage prices are going down, so they attract a growing number of small and medium businesses. Unfortunately, business data volume rarely fits the average Internet speed. IT professionals have to develop strategies which balance RTO & RPO expectations with the bandwidth capacity. This article provides an overview of main Internet speed challenges and reveals backup best practices from CloudBerry Lab:
RTO and RPO: Business Recovery Challenges
Backup Strategy Planning
Bandwidth Utilization Improvements
Cloud Backup Models
Application-Related Backup Best Practices
Disaster Recovery
RTO and RPO: Business Recovery Challenges
In backup strategy planning we operate with the following two main criteria:
Recovery Time Objective (RTO) is the period between a failure and full recovery. For cloud backup, it fully depends on the download speed.
Recovery Point Objective (RPO) is the age of the latest backup. This time determines how often the backup process should run.
Keeping RPO and RTO periods short, you need to transfer a large amount of data to cloud storage on a regular basis. At the same time, the bandwidth speed is limited, and corporate apps concurrently consume it. August 2016 Speedtest.net report shows that the average bandwidth across U.S. is about 55Mbps. With 100% network utilization, it takes about 16 hours just to transfer a 300GB data pack. But even small businesses today have a much larger backup volume.
Even if you are ready to invest in a faster network, the Internet Service Provider (ISP) can be unable to do it technically at your location. Thus, it is worth considering the optimization strategies below.
Backup Strategy Planning
Enterprise-class backup schemes don’t depend on the bandwidth limitations as they are designed for fast intranets. The starting point of cloud backup speed optimization is data analysis. You need to prioritize crucial files, omit to upload unnecessary data and build a bandwidth-optimized backup system. Let’s see some basic principles.
Backup Components
Predicting the optimal RPO and RTO, remember that some data is invariable, so it doesn’t need updates, and some data should be highly accessible under any circumstances.
Data is generally divided into the following three main types:
System data is operating system files. It is crucial for the IT infrastructure, and each disaster recovery begins with system restoration. After initial OS configuration and app installation, system data is altered infrequently. So, the main concern is to make a full backup after server deployment and then update it with altered data only.
Applications are all executive and app’s configuration files on the server. Like system data they are modified rarely after installation, so the backup concerns are quite the same. The point is that we can easily reinstall the application, so it’s worth backing up only configuration data. For further convenience, app configuration files can merge with system backup.
Working data is user documents and working files (databases, mailboxes, etc.). It is the basic part of any business, so it should be highly available apart from other data classes. But first, you need to recover the OS and applications before users could continue their work.
In practice, data classes often merge with each other, but this consolidation should be thought-out. For instance, include data which is infrequently altered to a separate backup plan, it will help to shrink the backup window and save some data if one of the backups gets corrupted.
Onsite and Offsite Storage Rules
There is the 3-2-1 backup rule, which is recognized to be the golden mean between data durability and availability. It suggests the following:
Create at least three copies of data.
Keep these copies on two or more different media types.
Move one of the media to offsite storage.
From the bandwidth utilization perspective, that also implies data prioritization. First of all, you should backup data to local storage. Crucial data also need an additional copy in a cloud in case of massive disaster. If data on local facilities is lost, it is worth utilizing all bandwidth available since users can’t work without their files anyway.
Another cloud storage use case is a backup archive. Services like Amazon Glacier and Google Cloud Coldline offer a cold data facility at an extremely low price but with a limited retrieval procedure as compensation. In the Understanding Cold Storage article, we analyzed best practices and prices of long-term data storage.
Bandwidth Utilization Improvements
Regardless of the backup strategy, sometimes we have to transmit significant volumes of data, especially, during initial data seeding to a cloud. Let’s review cloud system features which can facilitate this process.
Data Transfer Solutions
Cloud transfer acceleration helps if your connection speed to the datacenter leaves much to be desired. For instance, Amazon S3 Transfer Acceleration can transmit data up to 6 times faster using optimized network routes between Amazon S3 storage facilities and AWS Edge Locations. Find out more in one of our recent posts.
Nevertheless, it is not a cure-all: the accelerated speed cannot exceed the bandwidth provided by ISP. For instance, with fully-utilized 55Mbps connection, it takes 10 days 6 hours 48 minutes to transfer a 5TB seed. Moreover, there is no guarantee that the acceleration service will give a significant boost to the upload speed, so you should carry out this feature testing in your network using S3 Accelerate Speedtest page.
Another solution is Offline Data Import/Export Services. For an additional fee, you can send a media device to the data center, and the staff will quickly upload its content to the cloud. Using fast-performing postal services, offline transfer is much faster than transfer via the Internet. But this option also has its cons:
A storage device can get damaged while shipped. Off course, you can get the device cost back, but this situation will be a waste of time.
Usually cloud providers don’t have a Service Level Agreement (SLA) for offline media transfer. If something goes wrong or too slow, there is no way to fix it.
You have to encrypt data with the tools and algorithms predetermined by the cloud provider.
There are advanced solutions which help overcoming the issues above. Amazon Snowball is a hardware solution for offline data transfer, which can fit up to 80TB of data per device. Snowball connects to the local network via a high-speed interface, has physical armor-case protection and strong encryption. Simply put, Amazon sends Snowball to your location and then you send it back to the cloud datacenter. Find out details on the official Snowball page.
Backup Plans Optimization
The first step to improve the backup speed is incremental copies. It saves only data blocks that were altered since the last full backup or another incremental, so it doesn’t take much time to upload.
But when it comes to recovery, incrementals must be recovered consequently to get an up-to-date data. Some customers find it effortful and time-ineffective, so CloudBerry Backup does this work transparently. In this case, time expenditure is comparable to the recovery of a solid data copy. Moreover, Synthetic Full Backup feature updates full backups on the block level and doesn’t create incremental files thus making the restoration process even more convenient.
Application-Based Backup Improvements
Some data is kept unchanged during the entire retention period (e.g., system files), while working documents are modified and substitute each other quite often. Synthetic Full Backup feature compares local data blocks with the cloud repository and then uploads only modified ones. The blocks already existing in the cloud are automatically copied to a new backup file by AWS services.
In the upshot, Synthetic Full Backup helps to reduce the upload volume up to 60%. According to lab tests, it also makes the backup process up to 20 times faster. Nevertheless, it doesn’t depreciate daily incremental backups.
If your upload rate suffers from network errors, try using multi-thread upload and adjust data chunk size. CloudBerry Backup breaks a big file into smaller pieces before uploading and then assembles back on the destination storage. Little chunks are processed quickly, so delays related to upload errors become shorter. Otherwise, large chunks increase the transmission speed, but it takes more time to continue an interrupted transfer task.
Cloud Backup Models
The cloud is just a part of a backup solution, so let’s overview its typical schemes.
Cloud-Only Backup
Small businesses and private individuals use this model because it’s straightforward and cheap. They upload and download backups directly to the cloud enjoying the following advantages:
No local storage facilities and no hardware purchase and maintenance expenses.
Easy and cheap scaling.
Backup infrastructure is simple and requires no IT staff.
Backed up servers can start as a cloud virtual machine.
It looks simple, but the cons list is much more serious:
Everything depends on the Internet. No network connection – no data available.
The bandwidth becomes a vital resource in case of disaster. You have to choose between the data recovery speed and the working process or give an unlimited bandwidth for recovering tasks thus suffering from low business application performance.
In the upshot, the pure cloud model suits best for businesses having a small amount of data. Big files recovery will stick with the low bandwidth, so consider active and standby Internet links if you are going to implement cloud-only backup.
Hybrid Cloud Backup
Hybrid backup consists of local and cloud storage combined within one solution. Typically, data is backed up on the local storage with an additional copy in the cloud. The main advantage of this model is that you wean off the Internet and make fault-vulnerable data highly available.
The pros of the hybrid backup are as follows:
Quick and bandwidth-undemanding backup.
Data backups can run more often.
You can schedule cloud transfers during off-hours.
If you use NAS* or a file server for local backups, you can install the backup app locally and make cloud transfers autonomous.
*Note: CBB now supports QNAP and Synology NAS, WD version is under development.
Data recovery is possible without Internet connection.
Still, there are some pitfalls:
You need to buy and maintain storage devices.
Scaling can become a hustle.
To save the bandwidth, some companies store only crucial data in the cloud, for example, working documents and databases. It needs a bit of adjustment and knowledge as well as effort in case of disaster recovery. Though, it helps to return to the operational condition quicker even if the local storage is lost.
3-2-1 Rule and Combined Hybrid Cloud Backup
According to the 3-2-1 rule, we have to keep at least three copies of data. But we can cheaply exceed our backup volume by using an additional archive data copy. Some cloud hosts provide the Lifecycle Policy feature, which moves data with an extended retention period from the primary cloud storage to a cheap but less accessible archive. CBB customers usually define the backup lifecycle during backup plan creation, so it doesn’t need much efforts.
The rule requires to keep backups on at least two different kinds of media. Moreover, we can divide data among two or more cloud services. If it’s possible, it is better to use fast cloud storage from an ISP for system backups and keep application data on a third-party cheap cloud.
Generally, the most reliable and safe offsite storage is a cloud. But it can be even safer using geo-replication. Top cloud providers like Amazon Web Services (AWS) and Microsoft Azure can spread your data among several datacenters worldwide, so the data becomes invulnerable to regional disasters.
With the 3-2-1 hybrid backup, we distribute data among different local and cloud storage facilities to quickly download crucial data and store old archives cheaply. Synthetic Full Backup feature and other bandwidth utilization improvements increase the method effectiveness.
Application-Related Backup Best Practices
Now, let’s see how to optimize backup of a typical business IT infrastructure.
File Server
File servers contain a lot of crucial data and are considered to be the biggest generator of the backup upload volume. But you can achieve the optimum data transfer performance in a few steps.
Divide the server disk into a few partitions: 30 – 50GB for the system and the rest part for data. Since system files mostly remain unaltered after the initial configuration, it’s a good idea to separate them from working data.
Back up the system partition on the image level, which is convenient for recovery. Make full backups monthly when the network is idle, and block-level backups every weekend. Use of CBB Synthetic Full Backup feature will diminish time consumption and save a lot of bandwidth.
Schedule backup for the data partition. Use the file-level plan with the Block-Level Backup option enabled. This will help to skip unmodified files and accelerate the upload process. Make block-level updates every night.
CBB lets limiting bandwidth usage during business hours. Even if some tasks exceed a night span, they won’t influence corporate users’ performance by a limited upload speed.
This 4 steps will help you to upload only modified data and consume the network when it’s not crucial for business, i.e. at night.
Microsoft Exchange and SQL Server
The strategy essence is very similar to file server backup. But in this case, Microsoft Exchange or SQL data should be moved off the system partition. Other steps are as follows:
Use proper CBB Edition (Exchange, SQL or Ultimate) to separate and manage database files - that will make the backup process simpler.
Uploading block-level updates daily at nights and fulls on weekends is another best practice to optimize bandwidth utilization.
Increasing server durability, use such built-in features like SQL AlwaysOn and Exchange Database Availability Groups (DAG). If the main server is down, the standby machine will resume operation in a couple of minutes.
Expenses on the additional server are repaid by an extremely short RTO and bandwidth independency. Nevertheless, such clustering doesn’t depreciate scheduled backup: data corruption and local storage failures are still possible.
User Data and General Tips
Usually user working data concentrates on the desktop and in app-related document folders, that’s why many IT specialists think that it is enough to backup these directories regularly and instruct where to save the files. In practice, users behave differently, so here are a couple of tips:
Make a backup of all disks with the filter enabled for .docx, .pdf, .xml or other files typical for your business. That will prevent from losing important documents stored in an improper destination.
Note: Don’t forget to exclude system folders and files.
Some documents remain unchanged for a long time and then are suddenly supplemented with business-crucial information. If you use hybrid cloud backup and have a central backup server, enable the real-time backup feature in CBB to update files right after modification. That will slightly increase bandwidth usage but reduce RPO to zero. To prevent access errors, make sure you forbade CBB copying of files opened in other apps.
Create an additional backup plan with the endpoint on a local drive. Since users often delete, lose or corrupt data accidentally, that will minimize bandwidth utilization for routine tasks.
Make sure that you control the situation. Disallow turning off the backup service and create a set of system recovery USB sticks depending on the server image thus making recovery tasks easier.
Virtual Machine Backup
The backup process for a virtual machine based on the strategy used before:
The backup app works irrespective of whether it is a virtual or physical machine, so it doesn’t take a hypervisor into consideration.
The block-level backup feature significantly decreases the upload time and bandwidth consumption.
Place application data on a separate virtual disk. That will exclude unnecessary system files.
As you can see, the virtual machine backup strategy differs from the physical one insignificantly. The only consideration point is system restoration. To make the recovery, just turn off the VM and overwrite its virtual disk with the one from a backup using CBB. The method is described in How to Perform Physical to Virtual Restores article.
Disaster Recovery
After creating a full set of backups, you need to be sure that you can recover systems and data effortlessly in case of any accident.
Restore to a Cloud Virtual Machine
If local servers go down, work must be continued at all costs. We often recommend recovery to a cloud VM because all needed data is already in the cloud and the VM can scale for any workload. At the same time CBB supports Amazon Elastic Compute Cloud (EC2) and Microsoft Azure virtual machines, so you can easily deploy the Pilot Light scenario – find out more in Physical to Virtual Restore article.
Use of a newly restored cloud VM is difficult without completion of the following steps:
If you create an Amazon Machine Image (AMI) file, EC2 instance will start immediately (the same with Azure VM). Otherwise, you will need to go to the Management Console and launch it manually.
Any cloud VM instance requires networking configuration to connect apps to the restored server.
User client apps must be redirected to the cloud VM. Prepare a deployment pack in order not to sweat over redirection at short notice. For instance, continuing work with the cloud-recovered Exchange you need to adjust the network configuration of the cloud instance and local network. Then you have to enable Exchange autodiscover service in Outlook instead of manual user address specification.
CBB restores data images as a VM root disk, but you also have to load application data if it’s backed up separately. For example, direct connection of S3 storage to EC2 machine is impossible by default, so you need to implement some workarounds. At the same time, you can mount Elastic Block Volume (EBS) to a VM in a couple of clicks, and it performs faster.
If you restore the server as a VM with the data stored locally or on another cloud facility, make sure you can connect it and get enough performance. Cloud-to-local data transfer also consumes the bandwidth, which is the dead end for disaster recovery.
Any oversight in cloud VM deployment takes additional time and increases RTO, so it is better to deploy Pilot Light strategy. It means that you regularly update a sleeping cloud VM with crucial server data. If the onsite server goes down, the preconfigured cloud instance can start in couple of clicks to pick up the workload.
Bootable USB Creation and System Recovery From the Cloud
A system image is the central part of server backup. CBB can download the image and create a bootable device for deployment, but it’s not fully automatic. A successful recovery after a disaster requires you to:
Have a standby computer with CBB signed up to the cloud backup storage with necessary backups.
Save machines backup prefixes and specify them in CBB configuration to access the data. Learn more in How to Continue Backup on Another Computer article.
Use an external media device having enough capacity to place the restored image.
Use CBB Bootable USB feature to make recovery media without using extra apps.
Don’t forget to update this bootable storage regularly to have a fast recovery solution with actual data.
Conclusion
Now you know how to optimize bandwidth consumption and reduce RTO and RPO for your backup infrastructure. If you have questions left or want to find out more, check the following resources:
Disaster Recovery in the Cloud: Choosing Restore Type.
Compare AWS, Microsoft Azure and Google Cloud for Backup.
Disaster Recovery to the Cloud.
Understanding Cold Storage.
CBB Help Center to figure out questions about our solution.
Featured Product
CloudBerry Backup
Windows Edition
AWS, Azure, Google support
File-level and image-based backup
Synthetic full backup
Faster uploads with multithreading
Restore to cloud VMs (Amazon EC2, Azure VM)
Download Free Trial