Re: [tlug] Recovery -- The Dead HDD Sequel

["Stephen J. Turnbull" <turnbull@example.com>]

Attila Kinali writes:
 > On Mon, 28 Nov 2011 11:20:42 +0900
 > CL <az.4tlug@example.com> wrote:
 > 
 > > The dead HDD lived for a bit, then passed away quietly. 
 > 
 > And the moral of the story is: Keep backups, of everything! Regularly!
 > 
 > Apropos, does anyone know a good backup tool for laptops?

I like the Coda file system, unless you work with > 100MB files a lot.

Basically, Coda is a full-contents caching replicable network file
system.  Full-contents means that open(2) can take a long time (thus
the size caveat, exact size that's bearable depends on your network
throughput).  Caching means that your laptop only works with full
local copies of each file, which are updated from the network
synchronously (you have to wait) on open(2) and to the network
asynchronously on close(2).  Replicable means Coda can automatically
maintain copies on multiple servers.

The main problems with Coda are (1) synchronous open can block you for
ages on large files or weak network connections (with *no* network
connection you work disconnected -- there are provisions for both
manual disconnect and auto-disconnect on detecting weak connections),
(2) poor support for merge when there is a conflict, (3) you can't
work disconnected with a file that you can see in the directory but
isn't in your cache, and (4) AFAIK doesn't work on recent Macs.

(1) is a physical YMMV kind of issue.  (2) is probably not a problem
in a backup scenario, because the laptop client will always be newer
than the servers and thus win in any conflict.  (3) depends on your
actual usage patterns; there are practical limits to the size of the
cache (around 1GB in my experience but that is limited to 32-bit
machines; my 64-bit machines don't use Coda).  If your cache is big
enough, you can pin all the files you need in the cache even if
they're not recently used.  (4) isn't a problem if your laptops aren't
Macs (the Windows client is updated regularly, I don't know if the
server runs well on Windows though).

Coda also works great with git, because there are in practice (ie, up
to SHA1 collisions) never any conflicts, even when packing objects.
This meant that in practice I could almost always safely deal with
Coda merge conflicts by reinitializing the Coda client, and then
merging via git.

I don't know if it would work as well with bzr or hg, because those
systems reuse the names of repository storage.  So I suspect you are
likely to get Coda conflicts in the repo storage, and that would be
very annoying (although recovery would be straightforward in principle
it would be tedious and thus somewhat error-prone).