Restoring an Arch Linux installation from CrashPlan
Update: Sadly, this won’t work anymore, due to CrashPlan substantially increasing their list of globally-blacklisted file paths. If you know of a suitable alternative to CrashPlan for affordable Linux live full system backup, please do let me know!
I couldn’t find any information on this, so after working it all out, I thought I’d write up the process for others. I’ve been meaning to start a blog for years — here goes!
Backstory
CrashPlan say that their software is not intended to be used for backing up a full operating system; only your personal files. A few years ago, I decided to try them out for this regardless, backing up the full Arch Linux operating system on my home server in addition to the family’s personal files it serves.
Fast-forward to a few weeks ago when I rebooted the machine… and it didn’t come back online! I had to move it out of its home of the workshop in the garage, upstairs to my desk and screens to determine the problem.
Note that in a somewhat unrelated matter, as far as I am aware, Linux still does not properly support the integrated graphics on the ASRock AD2700-ITX motherboard that I used to build this machine in about 2012. That is, HDMI does not work, and VGA requires a kernel parameter to be added. So every time I want to boot the Arch Linux installer, I have to press Tab on its boot screen to edit the kernel parameters, and add video=VGA-1:1024x768.
Back to the problem at hand. During the Linux boot process, it would fail at the fsck step, and DRDY ERR messages were being logged. The OS hard drive was cactus. Again.
The first/last time this happened a few years ago was in fact the point that I switched it to Arch Linux (from Zentyal) on a replacement hard drive. Both of these hard drives had been decommissioned ones from other computers, and subsequently survived only a relatively short time in the server, so I wasn’t going to be making that mistake again. The new drive this time would be an actually new drive.
Backup configuration
In setting up CrashPlan to backup the OS, I had selected all root files/folders, except:
/dev/
/lost+found/
/media/
/mnt/
/proc/
/run/
/tmp/I had also unnecessarily included /swapfile, so I didn’t end up needing to recreate that post-restore. The data that swap holds is frequently changing and not useful to backup, plus setting up a new swap file/partition is pretty easy, so I would recommend against including this in your backup.
Restore procedure
Set up the new disk
This is pretty basic. Attach the drive to a booting Linux machine, then follow effectively this:
$ sudo fdisk -l # to find which device ID to use
$ sudo gdisk # to create a GPT table and a partition interactively
$ sudo mkfs.ext4 /dev/sdX1 # to format the partition as ext4Restore from CrashPlan
Using the CrashPlan Desktop application on one of my computers that would normally have been backing up to my home server, I initiated a restore (from the CrashPlan Australia cloud) to the new disk of all the root files/folders for that machine, except the ones listed above (/media/ was shown because it was also backing up some content on the mounted data disks).
So with about 110 GB to download (90 GB of that being Plex’s cache… why did I bother with that when we don’t even use it!?) the download/restore process took around 10 hours. Sadly it didn’t use even 10% of our 100 Mbps download capacity (Telstra Cable, hehe).
Reinstall GRUB
Attempting to boot the server from this freshly-restored drive was unsuccessful. It just flashed an underscore at the top-left of the screen and did nothing.
I did some Googling, and discovered that GRUB needed to be reinstalled.
I chroot-ed from the Arch Linux installer to do this. I think it was in doing this that I was prompted to create each initially-empty root folder.
There was a problem with the GRUB installation, being that I had initiated the disk with GPT, and GRUB warned that installation into the GPT was not well supported. Not wanting to take the risk with this, and not wanting to create a separate boot partition, I figured out how to convert the parition table into MBR (because GRUB can install into this) without losing the data that was on the parititons:
root@archiso ~ # fdisk -l
root@archiso ~ # sgdisk -m /dev/sdX # Convert GPT to MBR
root@archiso ~ # mount /dev/sdX1 /mnt
root@archiso ~ # arch-chroot /mnt
[root@archiso /]# grub-install /dev/sdX
[root@archiso /]# grub-mkconfig -o /boot/grub/grub.cfgI also upgraded/reinstalled the kernel for good measure: pacman -Syu linux.
Fix Pacman
If I recall correctly, this is the point that the system started booting. Unfortunately, Pacman was logging a whole bunch of these errors: error: duplicated database entry ‘nano'.
I found a thread on the Arch Linux forums that indicated the errors were caused by having multiple versions of packages in /var/lib/pacman/local, and included a script that could be used to remove these. It needed a minor adjustment for my system however, to account for a extra file in that directory, ALPM_DB_VERSION, so here’s my amended version.
The last thing Pacman was complaining about was heaps of <filename> exists in filesystem errors, preventing a system upgrade. As far as I remember, the solution to this was to run pkg=nano; pacman -S — force $pkg; pacman -S $pkg for each one.
Sign into CrashPlan Desktop
The final step is to launch the CrashPlan Desktop client application and sign in again to resume backup operations (see the official documentation for how to manage CrashPlan remotely if necessary).
When I launched the client and saw a login prompt, I was worried that CrashPlan had excluded its own configuration from the backup. Luckily, after sign-in there was an option to adopt one of my previous computers, which worked like a charm, requiring no further reconfiguration.
That’s it! (I think =P) So yeah, it is actually possible, and not that hard in the end. Anyway, good luck restoring an OS from CrashPlan yourself if you’re in the unfortunate position of needing to!
I did this a few days ago, so forgive me for any details I have forgotten / remembered incorrectly. Please let me know via comment/email/Twitter whether this works for you, or what you did differently for another distro or configuration! =)
