In one of the environments I was managing, the problem was simple - the archive space was running out and the management was tired in re-inventing the wheel every couple of years by basically re-building their archiving storage system. They wanted to switch to tape…

…without most of the costs associated with “going tape”. They refused to purchase additional equipment (tape drives, racks, libraries etc.) and demanded that the storage previously used by backups (NAS) was returned to production environment asap. Crazy? Yep.

Anyway, I did not get a chance to see how this story ended as I’ve switched jobs and became a mostly VMware/Linux guy I am today. Having that said, last week I’ve decided to come back to this problem (as a thinking exercise) and try figuring out what would be a perfect solution in this scenario.

The answer turned out to be… virtual tape.

Cost Analysis⌗

If we look at it purely from a cost perspective, it is as follows:

  • Virtual Tape Storage (EC2) - used as the initial storage when the tape backups are uploaded before they go to Glacier - $0.025/GB/month
  • Virtual Tape Storage Archive (Glacier) - used when tapes are archived - $0.005/GB/month

On top of that, there is also the cost of the gateway appliance itself. The way this works is, you are billed for the first 100GB ($125.00) written to the gateway and anything after that is free of further charges or as Amazon puts it:

Up to a maximum of $125.00 per gateway per month. The first 100 GB per account is free.

So in summary, we have a cost of $125.00 per gateway, per month if we’d keep uploading more than 100GB monthly to AWS (which the client we’re discussing obviously did). If you add this all up, the cost of AWS VTL is just too good to be true. I was mostly surprised by how cheap the gateway itself is. If you’d be interested in the details, you can go check out their full pricing here.

Setup⌗

In this setup guide, we’re going to assume the client’s backup is based on Veeam Backup and Replication 9.5 U3 and VMware vSphere 6.7

We are also going to assume the client has already an access to AWS account.

  1. Download and configure the VTL appliance
  2. After a few minutes, if we go back to the AWS console, it should be asking for an IP address to connect to. Enter the LAN IP address of the appliance - do not worry about ports configuration, the connection will be established over HTTPS and then always initiated from within your network.
  3. After configuring a connection between the local appliance and AWS, we should finally create some tapes. As I didn’t want to invest too much into this project, I’ve created only three 100GBs tapes, but you can go higher if needed. The 100GB tape is the smallest available option.
  4. Configuring Veeam
  5. GFS Media Pools
  6. Creating GFS Tape Jobs

Having all of that done, we can just relax and wait for the backup to be saved onto our virtual tapes in the AWS:

What do you think?⌗

I must admit, when I’ve first heard about backing up archive data to cloud or “virtual tapes”, I wan’t too optimistic about it. Seeing the price of cloud storage - reasonable for anything under 1TB and straight-out crazy for anything else - I was certain that tape jobs can only happen locally.

Well, not for the first time and definitely not last, I was wrong in my predictions. Backing up to AWS seems like a reasonably priced alternative if the backup infrastructure in the environment has access to fast enough uplink. Obviously, it’s not for everyone (remote sites, huge data backups etc.), but certainly it’s perfect for clients such as the once I’ve described in the intro - desperate to off-load the upkeep of the local infrastructure and adamant about stabilizing the costs on monthly basis.

Have you ever used any virtual tapes in your backup environment? Send me your opinions @wilk_it_wizard or #sshguru