[tahoe-dev] Proposed short description of tahoe-LAFS for personal backup

[Saint Germain]

On Wed, 13 Jun 2012 09:54:23 -0400, Greg Troxel <gdt at ir.bbn.com> wrote :

> 
> Saint Germain <saintger at gmail.com> writes:
> 
> > tahoe-LAFS is not really a backup software but rather a storage
> > solution. The primary objective is to secure your data, either for
> 
> I would call it "distributed filesystem" rather than "storage
> solution". (Choice of nerdy rather than buzzword terms.)
> 
> > privacy or for safety (against damage). To do so, it stores your
> 
> loss, rather than damage.  That may be a translation issue, but in
> English I'd say loss because the emphasis is on servers that vanish
> more than servers that have your file but have corrupted bits.
> 
> > encrypted data (encrypted at the source) on several machines
> > organized in a network with a configurable policy (specifying K=2
> > and N=5 for instance, will spread your data on 5 machines, 2 of
> > which need at least to be available to access your data).
> >
> > A few remarkable points:
> >   - I like its "paranoid" approach. The idea is to trust no one (and
> >     especially not your online storage provider)
> >   - Don't need any redundant PAR2 checksum, given that the data are
> >     duplicated and spread on the network (I however recommend to
> > make another backup on another media from times to times)
> 
> To protect against bad blocks, a filesystem with ecc might make sense,
> but failures are often whole-disk.   So I don't disagree with you, but
> "need" makes this seem black and white, whereas really we're talking
> about probabilities.
> 
> Also, while tahoe works well, I don't think anyone thinks it is
> reasonable to keep data only in tahoe.  This is especially true if one
> enables expiration.
> 

Ok I'll change accordingly !

> >   - Community et mailing-list are very active and very helpful
> > (post a message to see how welcoming they are !)
> >   - Documentation is excellent
> >   - You can join an already existing network (like VolunteerGrid2)
> > by adding your machine. That way all members of the network will
> > have access to a part of your (encrypted !) data et vice versa. It
> > is quite a psychological jump to accept (you have to trust
> > encryption).
> >   - You can also rent storage nodes to Least Authority Enterprises
> >   - No delta encoding but has deduplication at the source, however
> > only on a file level.
> >   - Works on Linux, Mac OS X and Windows. I have however a few
> > doubts on the Windows compatibility for managing locked files. But
> > you can use Duplicati which uses Windows VSS and can use tahoe-LAFS
> > as backend.
> 
> It also works fine on NetBSD.  It probably works on other BSDs.
> 

Unix-like is the appropriate word then ?
I never know the proper expression (linux, Gnu/linux, BSD*, etc.)

> I don't know what you mean about locked files.  If you mean locking
> like in NFS and lockd/statd, then I wouldn't expect that to work
> anywhere.
> 

I'm talking about this problem :
http://backuppc.sourceforge.net/faq/limitations.html#locked_files_are_not_backed_up

BURP for instance if managing that with Windows VSS (and I suppose so
is Duplicati).

> >   - In case of backup interruption, resume is possible but you have
> > to upload the whole file again.
> >   - Encryption is with AES-128 (soon to be combined with XSalsa20)
> >
> >
> > I would be very interested to have any comment. But please be aware
> > that I have to keep it quite short and simple.
> > Sorry for the bad translation from french !

Thanks for your input !