Retrospect Blog

Migrate to the cloud

Migrate to the cloud 778

Now that Retrospect supports Backblaze’s B2 service, it is a good time to talk about staging options that you can add to your existing backup strategy. Doing so adds both redundancy as well as offsite security. Additionally, if you have been using an old tape format that you aren’t comfortable with in a disaster recovery scenario, migrating your tape sets to Backblaze B2 or other cloud providers is easy to do with Retrospect.

Migration

Why migrate backup sets to different media? There are a lot of good reasons. Perhaps your tape device is old and you are not sure you will be able to find a reasonable replacement if there is a disaster. Perhaps you know hard drives (and all other media) have a life expectancy and do not last forever. Perhaps you are looking on the positive side, at the convenience and flexibility of backing up to the cloud. Whatever your reasons, Retrospect makes it easy to migrate existing backups to Backblaze B2 as well as other cloud providers.

For my home backups, my prior offsite strategy had been to swap the currently used disk set out with one at the office. Retrospect is now a pure work-from-home company and so I needed a different solution. Enter Backblaze B2. Backblaze has been offering a personal, cloud-based, backup solution for over a decade with Time Machine elegance. Last year they bottled their infrastructure into an API other developers can use. At half a cent per gigabyte stored it is incredibly affordable offsite backup storage.

The first step is to set up a Backblaze B2 account.

Once you have a B2 account and a Retrospect set pointing to it, you can now seed your cloud set with backups from your existing set.

Retrospect has two transfer script types for accomplishing this seeding:

Copy Media Set

(Called Transfer Backup Set in Windows). This is best for cloning one set to another. Every backup is copied to the destination cloud set. (Although you can use selectors to thin these out, as explained below.)

Copy Backup

(Called Transfer Snapshots in Windows). This is best for only copying the backups you care most about. The default option copies the last backup of each source in the backup set. This script type is a great tool for Staging as well, but is also a fine solution for seeding your backups online if you do not need a long history of backups in the cloud.

In either case, pick your existing set as your source and your cloud set as a destination and run it. Other backups can continue to run while the upload is going, even to your existing local set. You will not be able to do backups to the cloud set until the transfer finishes.

As I was confident in my existing redundancy, I went with using Copy Backups. It was also easy to transition to my staging policy, which we cover in the next section.

Seeding using local drives
An alternative to seeding over the network is to use either Backblaze’s Fireball (currently in beta) or Amazon’s Snowball option. In both cases, the cloud service provider mails you a hard drive array that can store 40 to 80 Terabytes. You then use Retrospect’s "Local Storage" option when you create the cloud set. Seed this 'Local' cloud set using either of the two script types above. As these are local, the transfer is very fast. Then mail back the device to the cloud service provider who will then transfer your data to the cloud. As a final step, edit the cloud member and repoint it to your cloud credentials. For very large sets, this can be both faster as well as less expensive.

Staging

Staging shrinks the amount of time Retrospect needs to talk to each endpoint but, at the same time, provides you with the safety of redundant copies. As cloud sets are offsite, they make for a complete Disaster Recovery plan. To stage backups, create a Copy Backup script (called Transfer Snapshots on Windows). The source will be your local, primary, backup set and the destination will be your cloud set. When choosing the source, the default option to "Copy most recent backups for each source" will copy the most recent backup to the cloud.

Set up a schedule to run as often as you can. For my home backup environment, I went with once a week.

There are several options to reduce the space used in the cloud. When you set up your staging script, you can turn on software compression. Retrospect also uses matching to not copy files already in the destination cloud set. Finally, Retrospect respects any files backed up with Block Level Incremental Backups.

Keep what you want with Selector Rules

You can further prune out what Retrospect copies up to the cloud by using Retrospect’s selectors. (Also known as Rules on the Mac.) Choose User Files and Settings to only keep the data your users create. You won’t be able to restore the system for these machines, but you will have the critical files. As mentioned in Audit your backups, a middle ground is to have two scripts, one that copies the full system with only the All Files Except Cache Files once a month or even less often and another script that can run much more frequently that only copies the user’s data with User Files and Settings. You can copy a selector and tweak it to better fit your or your customer’s environment.

For my home backup environment, I do full system transfers once every three months and transfers of the latest user files every weekend.

In conclusion

Offsite cloud storage is a great partner to fast local backups to make a complete disaster-proof backup plan, and Retrospect has a ton of features that leverage the best of both of these worlds.

Bio

Bio jg

JG Heithcock

JG Heithcock is CEO of Retrospect, Inc. and has eighteen years experience in the storage and backup industry.