[tahoe-dev] Potential use for personal backup

Peter Secor secorp at secorp.net
Tue May 22 20:36:24 UTC 2012


Comments plus a way you probably can use Tahoe to do what you want inline
below.

On Tue, May 22, 2012 at 1:16 PM, Saint Germain <saintger at gmail.com> wrote:

> On Tue, 22 May 2012 13:01:58 -0600, "Zooko Wilcox-O'Hearn"
> <zooko at zooko.com> wrote :
>
> >
> > I hope this helps! I would very much like to read a letter from you to
> > the tahoe-dev list saying whether you tried to use Tahoe-LAFS, and how
> > you tried to use it, and how well it worked.
> >
> >
>
> Wow, you guys don't do things by half...
> I was not expecting such a detailed answer !
> After 12 years on linux, it never ceases to amaze me how open and
> friendly the open source community is.
>
<PS> Thanks for the kind words, zooko is particularly good at responding
well to questions both asked and unasked.

>
> 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.

>
> 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.

>
> As for testing, I don't have the remote server yet (I am evaluating
> different backup strategy/solutions before doing the jump). So
> unfortunately it would be difficult for me to test right now (I only
> have my laptop which is only connected when I am using it).
>
> Anyway I will include tahoe-LAFS in my article. A little advertisement
> for volunteers/contributors cannot do you much harm. ;-)
>
<PS>Let us know if you need any more information.

>
> Thanks again
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> 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/ad009be7/attachment.html>


More information about the tahoe-dev mailing list