[sf-lug] Linux backup software .. that meets unique requirements

[David Hinkle]

If there is no hard link support, that would be another very good reason to go to one of the built in Linux encrypted filesystems.

David

-----Original Message-----
From: sf-lug-bounces at linuxmafia.com [mailto:sf-lug-bounces at linuxmafia.com] On Behalf Of Alex Kleider
Sent: Monday, March 15, 2010 11:59 AM
To: sf-lug; David Rosenstrauch
Subject: Re: [sf-lug] Linux backup software .. that meets unique requirements

The link you give indicates that the file system does NOT support hard links so in effect, each 'snap shot' will end up being a whole extra copy of your file system. i.e. files that have not changed will be copied again and will occupy disk space. Am I understanding that correctly?
I too, am very interested in a solution to this problem you have posed.
alex
 


--- On Mon, 3/15/10, David Rosenstrauch <darose at darose.net> wrote:

> From: David Rosenstrauch <darose at darose.net>
> Subject: Re: [sf-lug] Linux backup software .. that meets unique requirements
> To: "sf-lug" <sf-lug at linuxmafia.com>
> Date: Monday, March 15, 2010, 8:10 AM
> On 03/11/2010 03:03 PM, David Hinkle
> wrote:
> > Have you considered writing a script that produces a
> copy of the tree
> > you're working on, but encrypts each file with a
> simple symmetric
> > cipher using the filename as the initialization vector
> for the
> > encryption?   Then you can run rsync to
> back that tree up.   Rsync
> > will have to copy any file that changes in it's
> entirety, but the
> > data should be safe.  You could take it one step
> further and cache
> > the md5sums of the files before you encrypt them (like
> duplicity) so
> > you can avoid re-encrypting files that haven't
> changed.   An approach
> > like that might work well enough for a source code
> repository, but
> > will be bad for anything like a database.
> > 
> > David
> 
> Thanks much for the suggestion, David.
> 
> This is indeed the way I was leaning.  But I wasn't
> too thrilled about having to go through 2 full rsync steps -
> particularly because it's a pretty sizable file system
> tree.
> 
> Fortunately I think I've found a neat workaround: 
> Continue backing up as I've been (i.e., using
> rsync/rsnapshot) but have the backup process backup to a
> mount point that is an encfs encrypted directory on top of
> an sshfs remote mounted directory, as described here: http://wiki.rdiff-backup.org/wiki/index.php/BackupToEncfsAcrossSshfs
> 
> Result meets all my requirements:  files are backed up
> using rsync, to my existing storage space, and are encrypted
> both in transit and on disk.
> 
> Going to give this a whirl tonight.
> 
> Thanks much for helping me bat this problem around with
> you, David.
> 
> DR
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
> 


      

_______________________________________________
sf-lug mailing list
sf-lug at linuxmafia.com
http://linuxmafia.com/mailman/listinfo/sf-lug
Information about SF-LUG is at http://www.sf-lug.org/