[tahoe-dev] Potential use for personal backup

[erpo41 at gmail.com]

Hi,

Just thought I'd put in my 2 cents. No offense to the devs, but I don't
fully trust Tahoe's encryption. It may be open source, but the community is
small compared to, say, gpg, so I can't depend on independent code audits
by experts I trust. Plus, implementation errors are always a possibility.

That's why I encrypt everything myself before uploading. It's a strategy
that works as well with google drive or dropbox as it does with
volunteergrid2.

Cheers,
Eric
On May 22, 2012 7:45 PM, "Jean Lorchat" <jean at iijlab.net> wrote:

> Hello,
>
> I just wanted to add my own little perspective about backups.
>
> I'm living in a country that has been shaken by 2+1 almost simultaneous
> disasters. So I can tell that multiple nodes is not just an advantage, it
> is mandatory. I can't think of something as a backup solution if it keeps
> all eggs in the same geographical basket.
>
> And for me, encryption is mandatory as well. It's the only way to make
> sure that nobody's peeking (think google drive or your typical free
> ad-supported online backup service, ah ah). It allows you to put your own
> personal data in places you wouldn't fully trust otherwise
> (friend/cloud/rented/hosted). Finally, it allows to make sure that the data
> cannot be easily recovered if you lack the key (anyone thinking megaupload
> ?).
>
> I am not very familiar with all the backup solutions mentioned here, but I
> am pretty sure that Tahoe-LAFS can be a backend for most of them. It is a
> very good lower layer for many things !
>
> Cheers,
> Jean
>
> On 05/23/2012 05:50 AM, Saint Germain wrote:
>
>> On Tue, 22 May 2012 13:36:24 -0700, Peter Secor<secorp at secorp.net>
>> wrote :
>>
>>> On Tue, 22 May 2012 13:01:58 -0600, "Zooko Wilcox-O'Hearn"
>>>> <zooko at zooko.com>  wrote :
>>>>
>>> <PS>  Thanks for the kind words, zooko is particularly good at
>>> responding well to questions both asked and unasked.
>>>
>>>
>> Hello and thanks for your answer.
>>
>>
>>>> Indeed what I had in mind was not possible with tahoe. It was mainly
>>>> because I couldn't imagine such a radical different approach.
>>>>
>>>> So as I understand it makes no real sense to have a node on my home
>>>> computer and it makes no real sense either to have a single node on
>>>> my remote server. So I have indeed to participate in some kind of
>>>> VolunteerGrid2 (I don't know anyone else as curious as me).
>>>> It's quite a psychological step to "give" your backups to people you
>>>> don't know, even if it is encrypted. But I _do_ understand all the
>>>> advantages.
>>>>
>>>>  <PS>  Here is one idea for a solution in your scenario. The setup
>>> would be that you have let's say a laptop that you carry around with
>>> you and a home server. You can set up a local node on your laptop
>>> that is a non-storage node (one line in the config file - under the
>>> [storage] section set "enabled=true"). Then, you can set up a storage
>>> node on your home computer server and just make shares.needed=1,
>>> shares.happy=1, and shares.total=1, meaning no expansion, just
>>> straight 1-to-1 mapping for the encrypted file to shares on the
>>> server. Run the introducer on that server as well, and then every
>>> time your laptop is awake and you run a "tahoe cp" or "tahoe backup",
>>> it will use the local non-storage node on the laptop to encrypt the
>>> file and then transfer it over to your home server.
>>>
>>> For bonus points, if you configure a helper on your home server
>>> (again, a one line config file change - under the [helper] section set
>>> "enabled=true") and you have enough disk space, it will actually
>>> handle partial uploads and restart if your connection dies. This is
>>> quite useful when transferring large files. However, none of this
>>> handles the big file with a small change (VM) scenario very well, for
>>> that you'd need some other method.
>>>
>>>
>> Hum yes but in that case I don't see the advantage of tahoe over other
>> backup solutions like bup/obnam/backshift/BURP (except maybe
>> encryption).
>> For backups, the real advantage of tahoe is the multi-node architecture
>> I think (many backups software also offer encryption).
>>
>>  I suppose that it is possible that I contribute one node to
>>>> VolunteerGrid2 which can be used by my whole family and friends,
>>>> each having its private encrypted store ?
>>>>
>>>>  This could be possible, just contact the volunteer grid group with a
>>> description of what you want to do and that will provoke a discussion
>>> about it and what the general rules of engagement and use are.
>>>
>>>
>>>> The only problem I see, is that I will be limited by the storage
>>>> capacity. The remote server I intend to rent has 2 TB and I was
>>>> already thinking that it was too small for my "group" (5-10
>>>> people). I understant that it is better on VolunteerGrid2 if I
>>>> contribute between 500 GB and 1 TB ?
>>>>
>>>>  <PS>Again, this is probably a good discussion to have with the
>>> volunteer grid group, perhaps they will encourage people to start
>>> contributing more and you could be a push in that direction.
>>>
>>>
>> Ok. I will do that if I decide to go with tahoe-LAFS !
>>
>> Thanks again
>> ______________________________**_________________
>> tahoe-dev mailing list
>> tahoe-dev at tahoe-lafs.org
>> https://tahoe-lafs.org/cgi-**bin/mailman/listinfo/tahoe-dev<https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev>
>>
>>
> ______________________________**_________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-**bin/mailman/listinfo/tahoe-dev<https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120522/a3bab400/attachment-0001.html>