Remote encrypted backups

[jonthysell]

Heya,

I'm currently using dmcrypt to encrypt my entire drive in my desktop (Gutsy).

I'm also running a remote server (Hardy) that I can access over SSH.

I want to be able both securely transfer and store incremental backups from Gutsy to Hardy automatically and regularly.

Right now, I'm using rsync to save local backups of Gutsy onto the same encrypted drive (secure, but eggs all in one basket).

The Hardy server is on 24/7, and I know that I can securely transfer everything over with an ssh/rsync combo, but is there any way to store the end files encrypted?

Since the Hardy server is on all the time, I don't want an encrypted drive always mounted (plus it's headless, so it can't auto mount at startup because if the power cycles then the machine won't boot without prompting for the luks password).

Also, if I create and encrypted image of the files (say with truecrypt or an encrypted 7zip) before transfer, won't rsync copy the whole backup every time?

Any suggestions?

Thanks and be happy!

[Dr Small]

Why not create a encrypted partiton on the Hardy server that can be mounted with fstab at bootup and uses a keyfile. Then securely transfer your backups to the encrypted partition.

[jonthysell]

Why not create a encrypted partiton on the Hardy server that can be mounted with fstab at bootup and uses a keyfile. Then securely transfer your backups to the encrypted partition.

Then the keyfile would have to be on a drive physically attached to the server. I'm using drive encryption in case of physical theft.

If the server accesses the key in an unencrypted space (at bootup), then so can any potential thieves.

Is there any way to say, leave the drive on Hardy unmounted, then only mount/unlock when I'm backing up? Could I store the server keyfile on my desktop then pass it securely to the server, mount the encrypted drive, perform the backup, then unmount and delete the key?

If the key is stored encrypted (via dmcrypt) on my desktop, then it'd only be accessible the same times that my data is: when I'm logged in. Which is of course the only time that backups can occur anyway

[Biochem]

Tar has incremental backup capabilities and can be piped to gpg. Public key don't need password for encryptions and the only the changed files are going to be transfered.

[jonthysell]

Ok I've been searching all day on this, and have cobbled a working solution, I'll probably post a more detailed howto in a bit.

Briefly:

On the server :
1. Setup a dmcrypted drive.
Optional (for password-less script):
2. (Optional) Give the dmcrypted drive a keyfile (but store on desktop).
3. (Optional) Modify sudoers to not ask for permissions for cryptsetup, mount, umount.
4. (Optional) Setup password-less ssh login.

On the desktop (in a script):
1. Copy the keyfile (if exists) to the server (using SCP).
2. Decrypt (open) the drive on the server with the key (using SSH).
3. Delete the keyfile (if exists) from the folder over ssh (using SSH).
4. Mount the drive (using SSH).
5. Transfer files with rsync and ssh.
6. Unmount the drive (using SSH).
7. Encrypt (close) the drive.

The setup can be completely automated if the keyfile and other optional setups are done. Otherwise you'll get password prompts.

It means having a server on 24/7 with an encrypted drive that is only "available" during it's backup period, so if it's stolen, no tears.

I'll post my script once I clean it up.

[Steve413z]

try "duplicity"

http://duplicity.nongnu.org/

it's in the Ubuntu repositories

[Steve413z]

duplicity uses GnuPG to encrypt your backups, you can have it use public key encryption or symmetric encryption, and it supports SSH transfers, it's very nice, it's been around for a long time, but not many people know about it

[hyper_ch]

is there a reason to not fully encrypt the server also? Only at bootup you'd have to enter the password...

[jonthysell]

try "duplicity"

http://duplicity.nongnu.org/

it's in the Ubuntu repositories

I'll have to check it out. It would probably be easier than what I have (even though the script works).

[Dr Small]

is there a reason to not fully encrypt the server also? Only at bootup you'd have to enter the password...

Just a question from a curious mind, How would you enter the password on a headless server? which as he says, is so.