In Part 1 of this series I described the basics for DR for a smaller organization and that included things like running in a virtualized environment and using virtualization-aware backup tools such as Altaro or Veeam. One of the main things I touched on in that post is the concept of getting your critical data shipped offsite using “backup copy” functions in the backup software. In this post I am going to demo the process of setting up and running “backup copies” using Altaro VM Backup for Hyper-V.
Firstly, I should describe the basic infrastructure that is in place. I am using Swan Lake for the demo as I am setting them up to do all of this. They have a large HP server as their Server 2012 R2 Hyper-V host that houses two Server 2012 R2 VM’s. Altaro is installed on the host server and the backup stream out of Altaro is sent to a share on another physical Windows server (whitebox) in their main building. In their second building we have another Windows machine that has the Altaro Offsite Server tools installed and this will be the target machine for the Backup Copies.
Swan Lake has a site-to-site VPN in place that we will be running the copies over but this is not a requirement. Altaro can stream the backup over regular Internet connections as it can encrypt the backup itself (yay!). Altaro does require a few ports be opened on the receiving end firewall to allow the Offsite Server to “listen” for Backup Copies (Offsite Copies in Altaro terminology).
IMPORTANT NOTE: Altaro and Veeam both offer WAN Acceleration (built into all licensed versions of Altaro; Veeam requires an “Enterprise” license) which can greatly reduce the amount of actual “data” that is pushed across your WAN link. However, you have to keep in mind that you will only have so much bandwidth available to you for your Backup Copies. It is not feasible (or possible) to copy large amounts of data across a “thin” WAN Link in a reasonable time frame. As an example, in Canada many organizations are hanging of WAN links that limit upload speed to 5Mbps or less! It doesn’t matter if the receiving end can download at 100Mbps, the limiting factor is the upload speed. You are probably going to have to run a number of tests to figure out what your actual network and time limitations are and work backwards from there.
This also leads into another discussion about how Altaro creates its backups and how you prep the Offsite side of things to receive Backup Copies.
Altaro backups are always comprised of “delta changes” once a full backup has been made. In simplistic terms, Altaro only records the “changes” in state of a given file object from backup to backup. This means that backups can be very small. As an example, if the net change to a server is only 2GB since the last backup then the next backup will be roughly that 2GB’s in some compressed form. However, if you add a net-new 50GB of data to a server being backed up that next backup will be 50GB’s in some compressed form. That means the Backup Copy will also be of a similar size. Keep this in mind as if you are making large scale changes to your servers as you may be better off to disable and remove Backup Copies, make your changes, then reseed and re-enable Backup Copies.
I mentioned “reseeding” in the last paragraph and that leads into how you prep Offsite for Backup Copies. Lets have a look at the Altaro configuration at the main site:
This is a pretty nice summary of the configuration.
1) Shows the host and VM info, this is what is being backed up.
2) Shows the primary backup location and what VM’s are being backed up to that location.
3) Shows the offsite location and the VM’s that are scheduled for Backup Copies to that location. It is orange at this point as the process has only just been initiated, there are no actual Backup Copies in existence at the offsite location at this point.
As the Offsite location ahs been configured and as I have also added VM’s to the Offsite location, Altaro will now allow me to start working with Offsite copies (the Backup Copy).
Notice the Seed to Disk button. Seeding to Disk allows me to make a special copy of the current backups that I will then transport to the Offsite location and copy into the Offsite server. This then creates a base copy that the Offsite Copy then uses as the basis for going forward with copies across the WAN. You do this so that you don’t have to push a full backup across the WAN connection.
Clicking Seed to Disk fires off a wizard that will help you create the seed copy on media of your choosing (I am using a USB disk) and it guides you through the process (not illustrated here but extremely easy to follow). As you can see, my copies are in progress. Once the copies are finished Altaro will prompt me to move the media to the offsite location and import the seed into the Offsite Server.
The Offsite Server console has a lot less information:
As you can see, there is nothing really showing at this point. There is an account configured that sets up the “receiving end” for the Offsite Copies. An account has to be set up with in the Offsite Server in order to “light up” the Offsite Locations in the main server.
Once you have the account configured you do everything else from the main Altaro server.
When the seed backups are completed you “sneaker net” the USB drive over to the offsite location, attach the USB drive to the Altaro machine and then import the seed into the location you have selected. There is an option on the Offsite server to do this, you right click on the account and select Import seed from backup:
Once you have selected the appropriate seed backup the system will present a START button and you can run the import.
Back on the main Altaro server you can then manually run an Offsite backup or schedule them as part of the regular backup schedule. Manual Offsite backups are selected from Take Offsite Copy:
Scheduling Offsite copies requires you to modify the particular schedule you use and add the Offsite Copy:
The end result will be something like this:
The regular “on premise” backup (1) ran then the offsite copies (2) of the main backup ran. Swan Lake now has their backup data automatically being copied offsite with no human intervention required to get the copy offsite. And, perhaps more importantly, their systems are completely recoverable from BOTH backup sets, on premise and offsite! And, of course, the backup files on prem and offsite can also still be copied out to some other media so that there are multiple copies of backup data in existence. The point being that you must have more than one copy of your backup data or you are not covered. This automated backup copy process ensures there is at least one additional copy of the data above and beyond what is on prem.
My next post will look at the process of recovering systems from the offsite backups which is what you would do in a disaster scenario.