encfs vs Truecrypt?

[mcguinness]

Anyone got a preference?

I'm fairly new to using rsync etc. but I want to be able to encrypt some of my backup. I just don't know enough about encfs to make a call on it. I'ver read some stuff about it being slow and mounting it not being secure?

Does anyone have a suggestion on the best way to backup and encrypt around 10Gb of files?

Of course my other files will be unencrypted and I just need a mirror of my local storage for that. Rsync the best thing?

Actually, on second thoughts, is there a way to roll an incremental backup to allow restoration of previous versions? But only going back a few iterations or only up to one month old?

Sorry for all the Qs.

This service looks great. Love the 30 day trial to see what works best.

[John Wooton]

EncFS vs TrueCrypt.....

TrueCrypt has an advantage of being multiplatform and portable.  So, if at some point...you wanted to copy the entire 10GB encrypted volume down to your Windows or Linux desktop...you could...and you could mount it there.   However, that really doesn't apply to a straight up offsite backup scenario, where you want your files offsite.  This really in my opinion isn't that great...particularly if you're running Linux.  Now, if you're just a fan of Truecrypt & trust it's ability to be secure...that in itself may tip the scales in favor of TrueCrypt.

EncFS has the advantage of accessibility.  I actually lean toward EncFS myself.  I'm not aware of any security shortcomings.  One thing that some folks might mention is...if you mount your EncFS directory from the "server side"... there is a chance that "I" ... being the admin of the server can access those files while that directory is mounted.  Once it's unmounted...that possibility disappears.  Now, say you trust me the Admin, but your fear is the server gets hijacked...then if whoever took control of the system is running as root...they could do the same... "IF" you have it mounted server side at that time. 
  
                So, how do you avoid this possibility entirely, you mount it the same way you do TrueCrypt...remotely from your desktop.  That way, there is no way for an admin...or attacker that has compromised the system, to impersonate you and jump into that mounted directory.  To mount that directory...it would have to be actively mouted & they would have to do it from your home PC.

Rsync

  For a solution to mirror a directory in location A...to Location B...and any variation of that scenario...I can't think of a better more reliable tool.  A lot of folks use variants of Rsync or some other mirroring software...but I stick with a pure Rsync solution.  Particularly for data that doesn't contain sensative info.  And even for the parts of your data that need to be encrypted...you can just Rsync into your encrypted directory/file.  Rsync is very efficient and only sync's changes after the first full sync.  For text files & other certain file types...only the changes "inside" the files are transmitted...so it's really efficient in those scenarios when the format of the data permits.

Data History

Rsync actually supports an option ... it's the --backup switch "I think".  I don't use it currently, but I have in the past.  It will hold a seperate directory that contains the original versions of any files that were changed, deleted, etc.  You can specify as part of that --backup switch how long to retain those files.  So for instance, you can hold onto those for 30 days and then they get automatically deleted after that amount of time passes by.

Or, if you don't want to do that.  You can just do your sync's without the --delete option.  The --delete option keeps the directories perfectly in sync.  So if something was deleted on the source...it's deleted on the destination.  If you don't specify the --delete switch, any files that are deleted on the source...will remain in the destination until the day comes when you want to run that risk and sync fully with the --delete switch.  With regard to files that aren't deleted...but only changed.  Don't quote me on this...but I think those would still be updated to match the source.  So you could still lose something that way.  That's where you would find the --backup switch useful.


Let me know if you have any other questions.  Also, in all honesty...there are probably some folks in these groups that could answer these questions even better than I...or might have something useful to add...(or correct me on something I didn't exactly state just right).  That's another thing I like about this service...is you gain with it a lot of good people from the Linux community.  Things have been kinda quiet recently in the Discussion group...but I wouldn't be surprised if someone chimes in with some other suggestions.  No one solution is perfect for everyone.

[Martin Larsen]

On 28 November 2011 02:35, John Wooton <jo...@datastorageunit.com> wrote:

Data History

Rsync actually supports an option ... it's the --backup switch "I think".  I don't use it currently, but I have in the past.  It will hold a seperate directory that contains the original versions of any files that were changed, deleted, etc.  You can specify as part of that --backup switch how long to retain those files.  So for instance, you can hold onto those for 30 days and then they get automatically deleted after that amount of time passes by.

I use the --link-dest option. It takes a reference folder as a parameter and compares the source folder with that. New or changed files are copied to the destination, but instead of leaving it as this, existing files are hardlinked from the compare folder into the destination so you _apparantly_ have a complete mirror of the source but still use only the space of the new or changed files plus a very smule overhead for the hardlinks themselves.

I simply name my backups after the date, and using this scheme I can go back in time and retrieve any version of a file from a given backup set.

Martin

[knnniggett]

Perhaps this has changed, but at the time I was facing the same
decision, Truecrypt volumes could not be expanded. If you ran out of
space, you had to delete and start over. That was simply not an option
for me.

[mcguinness]

Thanks for all the advice guys. Looking into encfs & rsync (also
having a look at rdiff).

[niknah]

I am using encfs on my local machine.  Backing up to the encfs using rdiff-backup.  Then rsync the 'encrypted' encfs folder to datastorageunit.

Takes up more space but you have two backups & the remote server doesn't see your data.

If you don't want the remote server(datastorageunit) to look at your files, then encrypt locally first then backup the encrypted data to the remote server.  This is one big difference between datastorageunit and the usual remote backup software out there, which are usually closed source and don't tell you at which point the data is being encrypted.

I've tried keeping a key file locally and mounting the encrypted volume remotely but it is very slow.  Especially if you're using rsync/rdiff like tools to backup which requires that the data be read & compared first before backing up the modified parts of the file.

I've tried truecrypt & tricky things like lvm over truecrypt to get an expanding volume but it's not reliable.

What you can use is something like...

rdiff-backup /home /mnt/encfs

rdiff-backup --remove-older-than 30D /mnt/encfs

To restore...

rdiff-backup --r 2011-11-29 /mnt/encfs /tmp/restored

I've found that rdiff-backup   can keep many days of data with very little space.  If you get 100gb here for 10gb of files, it will last almost indefinately.

[mcguinness]

Thanks for this niknah.

[bb]

You might want to look at Duplicity (http://www.nongnu.org/duplicity/). It is basically rdiff-backup that encrypts backups locally before it is sent to the server. You don't have to trust the whomever is hosting your data, because they cannot access it. I've been using duplicity for years, but not at DSU.