<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-text-plain" wrap="true" graphical-quote="true"
style="font-family: -moz-fixed; font-size: 12px;" lang="x-western">
<pre wrap="">On 22-05-12 16:07, Saint Germain wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">Hello,
I am new to tahoe-LAFS and I would like to see if I can also use it for backups.
I have read the last month discussion but it is still not really clear for me.
</pre>
</blockquote>
<pre wrap="">The tahoe-lafs protocol allow for many applications, secure backup is
one of them.
Other applications are fine-grained file sharing, secure collaborative
work. For example, it can be used as a backend for a git repository. So
far I've only used it for backups as well.
It all depends on the level of integration of the tahoe-API in
applications. When used as a plain shared file-system you run into
issues where applications open and close files all the time and that
makes it slow. Besides, it leaves the most important feature,
capability-based access control unused.
Currently, there are not so many applications that use this API, that
might explain the silence in the media.
The tahoe backup command creates immutable files from your local
filesystem into the connected storage nodes. It does deduplication on
file level, so every time your VM-image changes, it writes a whole new
file into the store. (Anyone, please correct me if I'm mistaken).
Files that move from one directory to another don't change their
signature so these get deduplicated very well.
The biggest benefits of tahoe-backup are:
- it's easy to setup, although not yet "Parent-proof";
- it works out-of-the-box on many platforms;
- it is encrypted by default;
- only you have the key, so no one can read your data, unlike the other
cloud providers;
- that it shows the 'health' of your data; and allows to repair it.
That's why I use it.
Regards, Guido Witmond.
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">If I have my computer at home and a remote server somewhere, I want to
use 1-out-of-2 configuration in case I lost either of them.
So tahoe-LAFS works in that case basically as Dropbox synchronisation
(with the encryption).
Is there some kind of optimization which only transfer modified parts
to the other nodes, or is the whole file transfer each time it is
modified ? Especially for VM.
Same question for moved files.
Now I want to run backup on the remote server in case I accidentally
delete some files. So I use "tahoe backup" on the server.
But what kind of benefits I got exactly from using tahoe backup ?
If I have a VM of 1 Go that I want to regularly backup on the remote
server. Do I get to use 1 Go on the home computer and 1 Go on the
remote computer for the current version and 1 Go for each backup of
the VM ?
I was interested in bup/obnam/burp/backshift because of the efficient
incremental backup features (deduplication) which could manage this
kind of things very efficiently.
I have to say I am quite impressed by the tahoe-LAFS features. I am
surprise that it doesn't have a much bigger media presence. I am
currently writing an article on new backup softwares on french
linuxfr.org and I may add tahoe-LAFS as well.
Thanks !
_______________________________________________
tahoe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a>
<a class="moz-txt-link-freetext" href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</div>
</body>
</html>