Spideroak and Crashplan – restoring from backup
So, I have a tricky situation at the moment, where my laptop completely died. The two SSDs ground to a halt, and refused to boot or read. Over half a day of swapping drives in laptops, and attempting various recovery tools, has been fruitless, and I’m left to restore from backup.
Now, this is where it gets interesting. I have one main backup tool – Crashplan, which backs up to another PC in my office, and also most files (not large VMs) to the Crashplan cloud. I also use Spideroak for syncing my main documents between PCs, and it also serves as a backup of those files since it supports versioning.
While I love Crashplan’s ‘time machine’ approach, it has failed me: the full local backup appears to have disappeared from the UI, despite the encrypted files still apparently being on the other PC, and the cloud backup was only 20% complete. Hence while I wait for Crashplan support to explain what has happened and hopefully recover my backup, I’m restoring essential files from Spideroak.
These are my observations on Spideroak when push comes to shove:
- It’s there! Crashplan failed me, but those files that Spideroak did backup, are in the cloud and being restored. Phew!
- Be sure to set your computer up as a new computer, rather than adopting your original computer record, when restoring from Spideroak. If you ‘adopt the previous computer’, it will see the complete lack of files on your shiny new drive, and assumed you deleted all your data deliberately – and so will delete your backups too! This necessary ‘workaround’ to be able to restore is proof that Spideroak was not originally designed for backup; luckily you get a big warning box that hopefully you read before accidentally wiping your backups
- Restore is slow. I run on 100Mbps Cable, and although I had an original burst at 10Mbps download, it soon settled at 1Mbps. That’s 100kB a second, which for my 50GB of backed up data, will take 6 days to restore. If I had used the full 1TB, it would take 3 months to restore!
- You can’t pause the restore. Again this demonstrates that Spideroak is not really a backup solution, because of the pain this causes along with the following issues.
- If you have to shut your laptop down, or quit the application, it will completely lose the current restore progress, and anything in the queue. You would therefore have to manually work out which folders remain to be restored.
- It is impossible to manually select the files that have not yet been restored because:
- Files are not necessarily restored in any order – not necessarily one subfolder at a time, and not necessarily in alphabetical order. Hence you can’t assume “OK, I see the last folder partially restored was “O”, so I’ll just delete that one and then re-download all folders “O”-“Z” to finish my restore.”
- While you could possibly use folder size as an indication of whether all files inside have been restored, there’s no way of seeing folder size in the Spideroak UI
- You can’t simply ‘overwrite’ a partially-restored folder when restoring back to original locations, because all subfiles that exist will be restored again with a (1) suffix to avoid overwriting the file already there.
- All downloads happen sequentially; this means if you’ve queued up 50GB for download over a week, you can’t quickly download one file that you desparately need now, as when you select it, it’ll add it to the back of the queue!
- There is no way to prioritise files to download as above… unless:
- You use the Web UI in parallel to download specific files via a web browser! That is a way to skip the download queue
- If you try to be clever like me, and download large 3-4GB files using multiple parallel streams using DownEmAll in Firefox, then don’t. It seems that it will work – it does download in parallel, and I got much faster speeds of 10Mbps this way – but the file couldn’t reconstruct when completed.
- Rather than log into the Web UI, a quick way to grab a file is to use the Spideroak UI to generate a temporary download URL for the file you need, then click that link – this starts downloading the file immediately, without your needing to log into the Web UI and navigate to the file separately. It does introduce that risk of having to use the Web UI, which is not true zero-knowledge, of course.
- Support are quite responsive, if only on US time; I got a reply to my email in 4 hours!
So – what all this means, is that whereas with Crashplan – when it works – you can simply choose the date you want to roll back to, select all the files, and hit “restore” from your local backup – with Spideroak, it’s a chaotic mess of partially downloaded directories, files with (1)…(2)… suffixes, and being bound to leave your PC plugged in and running for days, or weeks, while it slowly, ever so slowly, restores your files.
However – it also demonstrates the importance of your 2+1 (onsite and offsite) backups – using different products and methods – rather than use one product for all of them, and then have that product completely fail.
EDIT: The Spideroak client has, after a few hours at 1Mbps, suddenly stepped up to around 40Mbps download… hopefully this means that the speed can vary, for some unknown reasons, and has now picked up again. I am slightly wary since the file progress status itself hasn’t changed, and I’ve seen similar ‘phantom downloads’ (massive download volumes for no actual files downloaded) from Spideroak before, when it confuses its sync state.