Remote encrypted backups

[hyper_ch]

you don't reboot a server

And the server might be at his some attached with keyboard

[jonthysell]

you don't reboot a server

And the server might be at his some attached with keyboard

I currently have physical access to the server, but that's not always the case (it's in California and I upgraded it from Debian sarge to etch while I was living in East Africa over SSH). Soon I'll be living out of state again.

True, the only time the server is down is after power outages, but it is in California, and with the summer coming, it will happen at least once.

Currently it boots headless fine, the most I can expect is to have someone power cycle it if necessary.

[Dr Small]

you don't reboot a server

And the server might be at his some attached with keyboard

That isn't always the case with mine. There have been lots of times I have rebooted my (development) server. Also, we have some pretty vilolent storms around here, which also requires powering it down.

If I were to encrypt the whole drive, I don't see how I could enter the password to unlock the drive without plugging a keyboard and monitor into it.

Lucky for me though, my server sets right beside my desk

[Steve413z]

duplicity would be perfect for you, because I currently backup my data to a server via SSH, and I like the backups to be encrypted because the server is off-site.

duplicity
1. splits files into manageable file sizes
2. uses rsync to make make incremental backups small
3. encrypts files using GnuPG (either password, or public key)
4. transfers files via: scp/ssh, ftp, rsync, HSI, WebDAV, and Amazon S3

[honeydew]

rsyncrypto.. scriptable seemless and lightweight.

http://rsyncrypto.wiki.sourceforge.net/

[jonthysell]

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've attached the shell script I made, one version that transfers a keyfile to decrypt the remote volume, one that just prompts for a password.

rsync+ssh+dmcrypt&keyfile and a well managed /etc/sudoers means complete automation. I appreciate any feedback on the scripts (they're pretty short).

I misspoke/understood before when I said I want "incremental" backups: what I want is the rsync method of only transferring what is saved to update the remote files, not a "base" backup with a chain of compressed diffs (ala tar).

So that means duplicity is out.

As for rsyncsrypto:

"Rsyncrypto does, however, do one thing differently. It changes the encryption schema from plain CBC to a slightly modified version. This modification ensures that two almost identical files, such as the same file before an after a change, when encrypted using rsyncrypto and the same key, will produce almost identical encrypted files. This means that both objectives can be achieved simultaneously."

Ummm, makes me nervous.

[userid]

my server has 1 encrypted partition, which i mount after boot. its got a luks password container in there. the partition is thus always mounted and could be breached if someone entered the headless server without interrupting the power supply. i think this is ratehr unlikely though.