Showing posts with label TimeMachine. Show all posts
Showing posts with label TimeMachine. Show all posts


CrashPlan limitations

After a few weeks using CrashPlan PRO for small business (not the free tier!) I tried contacting support to ask how to do some underexplained things, and/or to open some bug reports/feature requests. Like:
  • How to know which were the last backed-up files? or, when was a file last backed up? (maybe some useless-but-frequently-updated file is slowing down backups of bigger and more important files?)
  • The app defines backup sets, but they don't seem to correspond to "restore sets". How to restore a particular set?
Support's answers were pretty underwhelming, bordering on canned-responses; but I found that Code42, the makers of CrashPlan, have an API to access the backup data. So I browsed a bit to see whether it'd be easy to do myself what I wanted.


TimeMachine encryption performance: Synology's vs. Mac OS X's

A quick experiment to see what is faster to encrypt a TimeMachine network volume: using Synology's folder encryption or OS X's automatic TM encryption.

Copying a directory with 1200 files and directories in it (source files and compilation products), about 125 MB in total:
Unencrypted: 86 sec
Synology's encryption: 90 sec
OS X's encryption: 10 sec

So, not much to discuss about it: OS X's encryption wins.

  • This was done by the verily scientific method of trying a couple of times and counting seconds aloud. At the beginning I was thinking about doing it in some scripted, repeatable, strict way to control for things like caching and blah blah. But, a 1:9 difference? That's convincing enough for me, kthxbai.
  • I simulated OS X's TM encryption by creating an encrypted disk image (AES 256 bit, sparsebundle) in an unencrypted folder in the Synology's server. This might not be the same than the real TM encryption, since that seems to be done by FileVault 2, but should be close enough. It certainly looks the same from the outside, judging by a verily scientific cursory look.
  • Probably the huge difference comes from the Synology server receiving just a bulk write of the pre-condensed small writes in OS X's side. Yet, that means a lot of work in OS X (right? caching all of the filesystem activity and encryption itself). But it was so quick that I didn't even realize. That's ironic in a way: I was rather expecting that Synology's server-side encryption would offload the work from the OS X client. Well, forget about that - I prefer such a burst (that I didn't even notice over the normal system activity) than seeing the TM updates languishing for what feels like hours.
  • The Synology server (DS412+) is using a SHR1 volume over 3 disks. Connection via WiFi, max substained speed about 9 MB/s.
  • The Synology OS version is DSM 4.3. OS X is Mavericks (10.9.0). Server folders mounted via the AFP protocol (which depending on who you listen to might be not the best option, with SMB2 being the new official recommendation, but that's what TimeMachine uses anyway).
  • Synology's terribly slow file indexing is disabled, so that's not the cause of the slowness. Just to confirm if it could be as bad as expected, I enabled it and repeated the unencrypted copy, and after 100 sec it was still half-way through the copy - so, yes, it really is so bad.  I just cancelled it.
  • An added convenience for using OS X's encryption: the Synology encrypted folder has to be hand-mounted (in the server) after every reboot (unless you use the point-defeating, password-remembering automounting). The OS X encryption is client-side, so you only need to turn on the server and can then forget about it.
  • Just for completeness' sake, I also tried copying the set of files to an unencrypted disk image in an encrypted and unencrypted Synology folder. The results were 20 sec for the encrypted folder, 10 sec again for the unencrypted one. So, looks like Synology's encryption plainly adds about a 2x penalty, and OS X's is pretty much transparent.
Given all of this, looks like even if Time Machine was not implemented as disk images, it would be very convenient to (try to) force it to use one, even if not caring for encryption!