Encrypted Volumes: Linux Edition

Having your data encrypted at rest is crucial for a secure application, especially when you are reporting to a governing body for IT security standards in the Healthcare or Financial markets. Our VPC networking ensures all private network traffic is fully encrypted per customer network, which ensures your data is encrypted over the wire between VMs. Having encrypted volumes will add an extra layer of security to ensure even a somehow compromised volume is rendered unreadable.

We’re going to review encrypting your Cloud-A SSD volume on both a Redhat based, and Debian based Linux distribution using the dm-crypt package — the gold standard for modern Linux disk encryption. dm-crypt is a kernel level transparent disk encryption system, only worrying about block level encryption without ever interpreting data itself. This gives dm-crypt the availability to encrypt any block device, from root disks and attached volumes, to even swap space.

Create your SSD Volume

Head to your Cloud-A dashboard, and create a new Volume under “Servers -> Volumes”. We’ll create a 120GB volume named “Encrypted Disk 1?.

Screenshot - 11172014 - 02:10:52 PM

Now that we have the drive in place, we’ll attach it to a server to configure the disk encryption.

Screenshot - 11172014 - 02:11:51 PM
Screenshot - 11172014 - 02:14:27 PM

Linux Setup: Ubuntu 14.04 & Fedora 20

Our Ubuntu and Fedora images ship with the necessary tools to do encryption out of the box, we’re going to use the cryptsetup package to create the encrypted block device, create a password, and make it available to mount via the mapper.

sudo cryptsetup -y luksFormat /dev/vdb

Cryptsetup will prompt you to overwrite the block device, and be irreparable. Type “YES” in all caps to confirm. You’ll next be asked to provide a password for decrypting your data, make sure you choose a strong password and store it somewhere safe.

If you lose your password, you will in effect have lost all of your data.

Now we can use cryptsetup luksOpen to open the encrypted disk, and have the device mapper make it available. When you run this command, you’ll need to provide the password you entered in the last step.

sudo cryptsetup luksOpen /dev/vdb encrypted_vol

Next, we’re able to interact with the disk per usual at the /dev/mapper/encrypted_vol location created in the last step. Since the encryption is done transparently, you don’t need to do anything special from here on out to keep your data encrypted and safe. We’ll create a simple journaled Ext4 filesystem, and mount it to /data for the application server to use.

sudo mkfs.ext4 -j /dev/mapper/encrypted_vol
sudo mkdir /data
sudo mount /dev/mapper/encrypted_vol /data

Your disk is ready. You can check that it’s mounted and how much space is available using df -h.

Filesystem                 Size  Used Avail Use% Mounted on
/dev/vda1                   60G   22G   38G  36% /
/dev/mapper/encrypted_vol  118G   18M  112G   1% /data

You can now configure your database data directory, or application user data to point to your new encrypted /data directory to store your sensitive data.

Next Steps

When you are done with the volume, you can close it by unmounting and using luksClose to remove the mapping and deauthenticate the mount point so it cannot be accessed until re-authenticating.

sudo umount /data
sudo luksClose encrypted_vol

And to re-authenticate in the future on this, or any other VM you simply need to use luksOpen with your decryption password and mount to your desired location.

sudo cryptsetup luksOpen /dev/vdb encrypted_vol
sudo mount /dev/mapper/encrypted_vol /data

This should help you get on your way to a more secure installation of your application with securely storing your application data on a high performance SSD volume. At any time, you can use the Volume Live Snapshot function in the dashboard to capture a snapshot of this volume to maintain encrypted backups that you can restore to a new volume at any time.

Encrypted disks are not the only security measure you should be taking into account when deploying your infrastructure, but it is a crucial step in the right direction for every security conscious deployment scenario.


Today’s post is not to be confused with our post from back in May titled: “Backups With Snapshots” in fact, think of this as an extension of it. Snapshots provide you with a point in time image of your server which gives you system redundancy as you can easily and quickly spin up a new instance based on any of your saved snapshots.  With all of that said, there are a few things to consider when using snapshots of your server as your sole backup process.


The server that is being snapshotted will be paused temporarily during the snapshot process. While this pause time can be minimal, it might not be ideal for a server providing mission critical services. Because a snapshot of an server instance includes the whole system (operating system and data) the process can take between 1 and 10 minutes to complete depending on the total consumed disk space of the server instance before your server is resumed.


There is a cost associated with storing server snapshots. Server snapshots cost $0.15 per GB per month, billed for as long as the snapshot exists. You will only be charged for the compressed size of your snapshot — not the provisioned disk size.

Solution: Volume Snapshots

If the downtime and cost of server snapshots is not ideal for your application, the answer might just be using volumes and volume snapshots.

With this method we recommend that users keep their operating system on the original disk space that is included with the instance and use volumes to store their data. This allows you to take snapshots of your volume for backups of critical data, rather than the entire instance, and avoid the downtime associated with server snapshots.

In the case of a server instance requiring restoration, your recovery is as easy as deleting the server instance, launching a new server instance, and mounting the last successful volume snapshot to it.

Another effective use case is when data is accidentally deleted by a user. You have the ability to mount a previous volume snapshot to a temporary server instance, recover the deleted data and migrate it back to the production server.

If you wanted to go a step further, you can continue to store a single snapshot of your standard image, so in a case of a server issue, you will be able to launch a new instance based on your image with all of your system preferences and server roles intact.

The nicest thing about volume snapshots? They are free! Cloud-A does not charge for the storage of any volume snapshots, making them a cost effective backup solution.

Snapshot Schedule

Since there is no cost to storing volume snapshots with Cloud-A, you can store as many old volume snapshots as you would like. As the snapshots begin to pile up, properly labeling them will become increasingly important so that you know which snapshot is which.

The frequency of how often you snapshot your volumes is dependant on your organization’s tolerance for data loss and/or downtime. An organization with zero tolerance for downtime might require a daily snapshot of their server volume to provide them with several point in time instances of that volume. A less mission critical server volume, like a test environment, or an organization with a greater tolerance for downtime, may only require weekly snapshots.

Next Steps

We have partners and customers who are using a number of different backup methods with our infrastructure today. This really speaks to the flexibility Cloud-A’s Infrastructure-as-a-service offering. At the end of the day, the best backup processes are the ones that are recoverable and volume snapshots provide you with a cost effective, recoverable backup solution. We urge you to test it out for yourself!

Volumes 101


We are often asked about whether or not you can attach additional storage onto instances. Occasionally the base disk size just won’t do, or you have special storage requirements. The answer is Volumes. You can think of Volumes like portable hard drives you can add to your server. The data remains on the volume even as you connect it to various servers (one at a time). A common use case is to attach a Volume for consolidated backups for multiple servers.

Volumes are ideal for adding additional storage for existing servers without having to pay for additional compute resources. So you can spin up a small VM and use volumes to supplement your storage requirements.

For example, provisioning a 512MB VM with 10GB of disk and using volumes to make up the next (20GB) tier’s disk of 30GB would only cost an additional $5 (20GB * $0.25). You aren’t charged for incoming traffic or the amount of I/O you do. You are simply charged for the amount of storage you have. This is measured by GBs of provisioned storage and charged at $0.25 / GB / month, or ~$0.0003 / GB / hr. This can enable huge cost savings by only provisioning exactly what you need.


Have a Cloud-A account (don’t have one yet?), and at least one instance spun up. You can follow the start of this post for how to get started spinning up a Windows instance on our platform.

Creating a Volume

To create a volume, visit the Volumes page on your dashboard, and click on the “Create Volume” button.


In the modal window, enter a Volume Name, optional Description, select the Type (Regular) and your desired Size in GB. We’ll just make a small 2GB Volume for this demo. After hitting “Create Volume”, you’ll see a “Creating Volume” message while it is being provisioned.

Once you have your Volume created you need to Attach it to the desired Instance. Click Edit Attachments to open the Manage Volume Attachments window. Under Attachments you will see any Instances the volume is currently attached to. (It should be blank now).


Open the Attach to Instance dropdown and select the instance you wish to connect the volume to, then “Attach Volume”.

Just like that, your Volume is attached to your instance, and available to be formatted & mounted in the OS.

Formatting & Mounting Your Volume

Before you can make use of your volume in your operating system of choice, you’ll need to format the disk and mount it so you can start using it for storage. Below you’ll find some basic instructions for Linux and Windows instances that will get your disk mounted and ready.

Linux Servers

For linux servers (ubuntu 12.04 is used in the example below), it’s a quick process using fdisk, mkfs and mount.

$ ssh ubuntu@<my-instance-ip>
$ sudo -i
$ fdisk /dev/vdb
  # create new partition (n), 
  # primary (1), 
  # answer yes to start and end blocks to use entire disk.
$ mkfs.ext4 /dev/vdb1
$ mkdir /mount
$ mount /dev/vdb1 /mount

If you would like the Volume to be mounted on boot (permanently attached). You can add an entry in your /etc/fstab that looks something like the following.

/dev/vdb1    /mount   ext4    defaults     0        2

Windows Servers

For Windows servers (Windows Server 2008 R2 is used in the example), You can do it all from the console. If you’re still on the Volumes screen, you can click the link to the server, and then click the “Console” tab to get to it quickly.

Once logged in and set up, click on Server Manager – on bottom left next to the Start button. Then click on Storage and then Disk Management.


Right click the Volume you added (labelled Disk 1), and select New Simple Volume. That will launch a Wizard to format the new disk. Following the prompts and using the default values will be fine. Once it finishes formatting (this may take a few moments), you’re done!


If you flip back to your dashboard, you should see that the Status is “In-Use”. Success!

Volume FAQ

  1. What is the max number of volumes that can be connected to any one server? As many as you like, it is bottlenecked by the OS that you’re connecting it to.
  2. What are the smallest / largest size volumes? We have customers with volumes sizes from 1GB through to 10TB.
  3. How are volumes metered? Usage is added up at the end of the month, and calculated based on $0.25/gb/month. Point in time snapshots are taken of usage, and added up for each second of use. i.e. day 1 you’re using 1GB, for the time of that day, you’re charged that much, day 30 you’re using 1TB, only the last day are you charged the 1TB amount for usage.
  4. Are Volumes slow storage? No, Volumes are very fast! – SSD Backed storage, the same stuff that gives you blazing fast IO on your VMs.

Ready to give it a try?

Get started with a $10 credit

Create my account!