I received an e-mail today telling me that CrashPlan hadn’t backed up for the last 3 days. I have CrashPlan running in a VirtualBox jail as I blogged about here, and I very rarely check it as it just does its stuff in the background, and sends me a weekly update to say everything is fine.
So I used a Remote Desktop Connection (RDC) to check the VM and was surprised to see error messages to say it has run out of disk space. When I’d set it up I’d created a virtual disk of 20GB, which I’d assumed would be plenty, but when I investigated it appeared to be all but full. So the daunting task of increasing the size of the VirtualBox .vdi file, which I’ve done before on a Windows VM, but not one running in a Jail on my FreeNAS server.
The command to increase the size ran without problems and very quickly, and was simply a case of entering the following in the VirtualBox Jail shell:
cd /vm (which is the mount point to a dataset on FreeNAS containing all my VM files)
cd centos67-crashplan (the folder for my VM)
VBoxManage modifyhd centos67-crashplan.vdi –resize 40960 (40GB = 40×1024 = 40960MB)
I then needed to use GParted to get the partition to use the unallocated free space. I downloaded the latest version and then added the .ISO file as a virtual CD in my VirtualBox console. Once this booted, I came across my first issue. There was no unallocated space, even though the .vdi file was reporting a size of 40GB. A little Googling and I found my problem. I have a number of snapshots saved for the CrashPlan VM, which I’d taken before major updated. These stop the new space from being available, but fortunately, there’s a fairly simple solution. VirtualBox allows you to clone virtual machines, with various options to create them from the current state and without any attached snapshots. This took a little while, but once complete I could boot into GParted and increase the partition to use all of the unallocated space I’d created above.
The next step is to boot back into the new VM, which is always a little worrying after playing around with the file system. Needn’t have worried though, as it started back up without any issues. As I’m running CrashPlan in a CentOS guest, which uses a LVM (logical volume manager), there are a couple of further steps to take advantage of the resized partition. From the CentOS command line, as root, you can verify that the OS can see the resized partition by doing:
su – (and entering root password)
pvscan (shows the new space available)
df -h (shows the shows the /dev/mapper/vg_crashplan-lv_root logical volume as 18 GB)
lvextend -l +100%FREE /dev/mapper/vg_crashplan-lv_root
resize2fs -p /dev/mapper/vg_crashplan-lv_root
And that should be it! Or at least it was for me. I now have an extra 20GB to play around with, so shouldn’t be getting any e-mails about backups failing due to a lack of disk space for some time!
It’s probably worth adding a few caveats for anyone attempting this:
- First, don’t attempt this without having a backup of your data. I had snapshots of both the VirtualBox jail and the VM dataset, so could recover anything if things had gone south!
- I did this on a CentOS guest. It’s similar for other OS (for Windows you shouldn’t even need to last few steps) but you’ll probably find better instructions for your use-case online.
- It assumes you set up your VDI with Dynamically Allocated Storage. This will not work with fixed drives.
- I used version 4.3.12 of VirtualBox. Later versions may allow you to do this with snapshots attached, or an alternative to cloning is to simply remove any snapshots (I had serveral, so cloning seemed like the quickest option)
Trackbacks/Pingbacks