Re: [tlug] Raid5 box & backup

[Christian Horn <chorn@example.com>]

On Sun, May 25, 2008 at 08:39:17PM +0900, bruno raoult wrote:
> 
> Ooops... Is there a risk to loose everything in that case? Is is linked
> to loop? Otherwise I don't understand the difference with a normal FS...
> Encrypted or not, the raid-5 will keep the data safe (I mean as safe as
> a non-crashing disk, to avoid discussions out of topic :)
> 
> Do you think there is a difference with the loop mount? Or is the loop
> mount not secure by design?

Yes i think the risk to loose data is bigger with the loop.

Case a, plain nfs, unencrypted.
Pure nfs is used here, usual small files stored on the 2 datastores.
pros: highest fault tolerence, rsync efficient because it syncs single 
  files
cons: data sniffable on the network, and in the clear on the 2 datastores

Case b, plain nfs, files ecrypt encrypted.
Pure nfs, small files on datastores, but each file is encrypted seperately.
pros: still good fault tolerance (crash while writing a file has low risk
  to influence the users other small files), rsync efficient because it
  syncs single small files
cons: linux only as far as i know

Case c, plain nfs, over that one big crypt-file per user
Pure nfs, over that one cryptfile mounted by the user.
pros: works for all your architectures
cons: highest number of possible troublemakers - many layers involved 
  (loop-mount, filesystem on that), rsync sees just one file and has pro-
  bably to sync the whole file, for the rsync-backup the crypt-file should
  also be umounted by the user so the file is consistent.


One could simulate something like 'Case b' with gnupg for important files,
that would at least be portable over macos/linux/windows.
I dont really see the perfect solution for you, for plain linux i would
go for b, but the possibility of trouble with c would prevent me from im-
plementing that solution, but thats my fault-tolerance/security tradeoff.

Christian