Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a small network with a Ubuntu server in the middle and Ubuntu notebooks around. The notebooks all use eCryptfs to encrypt the whole home directory of users. Usually, there are two or more users per notebook. The backup procedure stays inside the network, so we are fine with transfering the files unencrypted to the server. We'd like to go with an rsync based solution, but are fine with others, too.

We ran into difficulties when trying to backup the home directories of the notebooks, that brought us major headaches. It boils down to this:

  1. If user A is logged in, the home directory is decrypted, and the encrypted files in /home/.ecryptfs/A are locked against reading from other processes (which is a good thing)

  2. If user B is not logged in, his home directory is not decrypted, there are only the encrypted files in /home/.ecryptfs/B.

  3. We need to have a backup script, that can run, while user A is logged in (because she starts it manually in our case) and user B may or may not be logged in (usually not).

Now the question is: What should we backup? If we go for the encrypted data, the stuff of user A cannot be backed up. Decrypted data means on the other hand, that user B must be logged in, too. And mixing both leads to a fun time, when it comes to restoring something.

Are there perhaps other solutions to this problem, that we missed?

share|improve this question

3 Answers 3

up vote 3 down vote accepted

Are you sure that /home/.ecryptfs/A is locked for reading? I use ecryptfs and while I'm logged in and can browse and read the files in /home/.ecryptfs/myusername/.Private. I just tried going into that directory (and sub-directories) and opening files (using vim -b) and I could read them fine. I'd certainly want them locked for writing, but I don't see why they'd be locked for reading. What OS version are you using? (I'm on Ubuntu Lucid 10.04). Maybe ask a separate question about errors you're getting, because maybe something else is causing the problem.

To directly answer your question - back up the contents of /home/.ecryptfs/. This will backup (encrypted copies of) all the files for all users.

In addition you ought to be able to decrypt the files if necessary. So you should store the unwrapped passphrase somewhere secure, in case the user forgets their password, leaves ... To obtain it, have the user run

ecryptfs-unwrap-passphrase

while logged in, and store the result somewhere. It's small enough that you could write it down (double triple check it) and store it in a safe, or have two people keep half of it each or some such, depending how much security you require.

Otherwise you would need /home/.ecryptfs/*/.ecryptfs/wrapped-passphrase and the users' passwords.

You should also note that rsync won't be able to speed up file transfers when syncing encrypted data. Any change in the unencrypted file will completely change the encrypted file. And compression won't really work with encrypted data. This shouldn't be a big issue for your case, where the sync is across a LAN, but may be important for other people reading this question. Though rsync can still check if an encrypted file is unchanged, so it won't have to re-transfer unchanged files.

Readers of this question might also be interested in this guide to backing up by the maintainer of ecryptfs.

share|improve this answer
    
I think that eCryptfs really encrypts the file in 4KB blocks so a localized change to a file should modify at max additional 8KB of the file. As a result, rsync should work fine. –  Mikko Rantalainen Dec 21 '11 at 14:36

Presumably the passphrase of the user not present is absolutely needed for decryption. Hence your only option is to look for a solution that backs up encrypted files, and use this for both users. This has the advantage that the apparently confidential information is also encrypted on the backup media - which can be important if you're transferring it around the place (for offsite).

I'm not familiar with ecryptfs but it sounds like the files are standard files when viewed by the underlying filesystem (at a guess ext3).

So, 1) Is the 'original' directory that contains the encrypted data actually somewhere else, and then mounted so that the unencrypted version appears at the location you've given - in which case you could just get the encrypted data from the original location. Some of the ubuntu documentation suggests that the unencrypted private files are what you see in /home/.ecryptfs/A/Private and their encrypted counterparts are actually present in /home/.ecryptfs/A/.Private. If so, and you use rsync you will have the encrypted .Private directory for both users anyway, and for clarity you could use the exclude options of rsync to prevent backup of the unencrypted Private directory.

2) Alternatively, you question reads a bit like the entire folder A (or B) is encrypted, and possibly the unecrypted and encrypted versions mount at the same location. If so, could you try something like mount -o ro --bind /home/.ecryptfs/A /mnt/encryptedA which would provide another access point to A's directory via /mnt/encryptedA. If this was done before user login then possibly you'd retain access to the encrypted version via /mnt/encryptedA even while /home/.ecryptda/A gives access to the unencrypted version. I don't know whether this will work - you'd just have to try it and see.

share|improve this answer

Why not "just" synchronize their files on log out to a share. this way instead of having to manually start your job it'll "autorun" (cron, action event ...) copy the unencrypted files to the share (which may or may not be encrypted) and then encrypt its own FS again before logging out.

I can see this not being the ultimate solution, but this means that the user'll always have a up to date backup since his files are synced on the server. And if user B hasn't logged in for a while, then there's no harm in not backing him up because his files won't have changed to begin with.

Is this something along the lines of what your looking for, or are you aiming for a more .... streamlined, all in one solution ?

Ideally though chucking the lot over a ENCRYPTED transfer for backing up would be better since right now you leave your valuable data right open to man in the middle and / or sniffing attempts.

share|improve this answer
    
The problem that I see immediately with this approach is: User A travels with the notebook, but is close to never logged in "at home". User B gets the notebook, when in reach of the share. Then A is never backed up, while B is. This is not a common scenario at ours, but it is reasonable to assume it will occur over time. –  Boldewyn Aug 23 '10 at 10:03
1  
"The backup procedure stays inside the network" –  Luke has no name Aug 23 '10 at 12:25
    
@Luke: s/network/intranet/, if that's clearer. The owner may use it outside the intranet, too. And then, no backup will be made. –  Boldewyn Aug 24 '10 at 6:18
    
Other things to consider: If user A is away for a long time they'll have a lot of changes to sync. How patient are they going to be waiting to log in/out while stuff gets copied? (This is the problem often cited against Windows "roaming profiles" FWIW) –  voretaq7 Aug 27 '10 at 15:10
    
then what you could do is make a script that dynamically sets up a VPN tunnel when its not directly connected to the corporate network. This way you CAN sync when he's not "in the office" too much as long as he actually gets connectivity to the internet from time to time. Plus added security notion: VPN is pretty secure compared to "other" means. or you could SCP to the corporate network ... whatever suits your needs better –  Entity_Razer Aug 30 '10 at 15:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.