Given my recent troubles with Spideroak, I took another look at the market for a decent cloud storage service. Each of Sync.com, Hightail, and Tresorit came under scrutiny.
Although it’s early days for a review, I am seeing good things from Tresorit so far. Aside from the fact that they googlebomb searches for Spideroak strongly (“Considering Spideroak? Try Tresorit instead!”), they have a number of attractive features over Spideroak.
Crucially – and the main reason I am considering moving away from Spideroak – they have a decent mobile app. Spideroak have no support at all for uploads on iOS, which I find frustrating as it means that any emails I receive with attachments that need filing away, have to be left in my inbox untouched for later review on my laptop, rather than saving it to the right folder on my synced drive, and filing the email as done.
Although I still use a laptop heavily enough to do this, working on mobile devices is supposed to be a ‘thing’ now – there are fully capable mobile MS Office apps on iOS, and yet if we want to save those back to our PC, we can’t do it with Spideroak.
In contrast, Tresorit has a clean, modern design app, with many swipe gestures as well as the important “Open in…” action support to allow any app to send files for storage and sync in Tresorit. It also allows file renaming and moving in the app – something that Spideroak also doesn’t allow.
In addition to this, Tresorit supports collaboration/sharing with other Tresorit users – again, something Spideroak doesn’t. The desktop app is similarly clean, where Spideroak’s is a bit clunky and utilitarian.
Both services support sending one-time URLs for specific files – Spideroak assigns a 3-day expiry by default, whereas Tresorit assigns 30-day, but with a maximum download count and adjustable expiry to boot. Both support versioning of backed up files, backing up of folders anywhere in your directory structure (unlike Dropbox), and both with ability to include/exclude subdirectories in those selections.
One advantage to Spideroak is its ability to share synced files using a URL and password, but without needing the recipient to be a member. Tresorit sharing is granular, but requires a Tresorit account, which many casual recipients would disregard.
That aside, my thoughts are that Tresorit’s mobile app with upload will swing it. For the bulk of my PC data, I also use Crashplan+, which means I can access any and all of my files, with no storage limit, from a mobile app as read-only – as with Spideroak. Hence, since I’m already paying for Crashplan, which has far superior backup capability, and I can use Tresorit’s free tier for syncing specific folders with my partner and with my phone – I see no remaining features of Spideroak that I really need on a regular basis.
That said, I’ll fully test Tresorit, and report back here.
I’ve just attempted to restore a very old Crashplan backup from an external drive. Since this backup is a few months old, it was done before I had a custom key configured for my backups, and hence is inconsistent with Crashplan’s current configuration.
Crashplan warns repeatedly that you can only have custom keys on or off – you can’t have a mix for your account. They also warn that if you change the encryption configuration, it will wipe all previous backups and start again.
So – when I attached the old backup folder, how did Crashplan react?
Figure 1: Custom key selected
First – since Crashplan has a custom key configured for my machine, it tried using that key on my old (non-custom-key) backup, and failed. Evidently it realised that the encryption method had changed, so it apparently renamed the old backup with an OLDKEY suffix before it did anything else.
Figure 2: The OLDKEY suffix for the old backup folder
Then – it started a new backup on the backup file!
This is one problem with Crashplan – you can’t attach an old backup as just for restoration. You attach a folder, and then Crashplan will use that for both restoration and future backups! When you attach a folder as a destination (which you need to do even if only to restore from), then Crashplan will add it to all the backup sets (if you have more than one), and start a new backup to it.
So – my PC saw that there was a backup there already under the same UID, but it didn’t have the key. It renamed that folder, then started a new, blank backup.
I now need to figure out what to do here. I can’t remove the custom key from the UI with uninstalling or resetting the configuration. And if I do THAT, it may wipe all other backups where I do have the custom key, including my cloud backup.
I’ve emailed Crashplan support, so let’s see what I can do here.
Losers – more problems with Crashplan restore
I’m having some more issues with restoring from a Crashplan backup.
I recently restored a VM that had become unstable from a local backup; the restore seemed to work fine, but then the VM complained of access problems to a file, or a file missing. After some troubleshooting, I decided just to restore from a different date.
However, now the restore isn’t working at all. I get a lot of “Unknown problem for …”
The interesting thing is, the network traffic is showing it IS downloading it all from the backup to my local machine; it just isn’t actually persisting any data to disk.
The app logs in C:\ProgramData\CrashPlan\log show a lot of warnings, one per file, with each containing:
. . . . BACKUP DATA IGNORED! Restore BackupHandler is null!! backupData=BackupData[BackupB
So – that’s something I have a case open with them.
Winners – Crashplan’s thoughtful design for file restore
In the meantime, I thought I’d try and find another backup I can restore from, and this is another example of where Crashplan shines.
I do occasional (monthly) backups of my backups – I basically do a simple file sync of everything on my NAS to some external Hard Drives, so that if something happens, I have a fallback copy. This external drive therefore includes all my NAS-based crashplan backups.
Since Crashplan supports attaching local archives, this means I was simply able to attach that USB drive directly to my laptop – not the NAS – browse to the Crashplan folder for my laptop’s backup – and attach it directly within the app. Again, the developers have got the little details right here; I need to identify which folder is the one for my laptop, and by selecting it but not attaching it, Crashplan gives me that information without having to fully load it.
Once attached, it has to sync all the block information, which means fully reading the data, taking time, but hopefully at the end of this, I’ll be able to restore the older backup directly from there.
It’s great that Crashplan supports alternate approaches like this. I have always run backups to a Computer over the network, as on the destinations list, but I can copy those files to a USB drive, attach it directly to my PC, and then restore from the Folder – it’s a different destination, but the file storage is exactly the same, so I can switch between those in order to access my data. A lesser product would have insisted that I re-copy the files back onto the NAS, and then access the data that way… but not Crashplan.
I use Word 2013 on-and-off for occasional posts to WordPress, simply because it uses nothing on my PC that isn’t already installed. However, trying this recently, I got an immediate error: “Word cannot register your account”.
The help page it directs you to no longer exists, and the response is so immediate it suggests a communication error or something more fundamental than a failed login.
It turns out to be the case – but there’s an easy fix.
Quite simply, when configuring your account settings, change the http to https.
Then fill in your URL, username and password as normal.
This appears to have been a change by Microsoft for enhanced security, but they haven’t been able to update the templates to reflect this. Of course, they should maintain and update the help page under “More information”, but hey, no-one’s perfect.