Efficient Incremental Remote Encrypted Backups

Figure the size of everything you need to backup, roughly double it, then divide it into «reasonable sized» chunks.

Let's say your backup data is 60GB and each chunk is 5GB. 24 chunks.

Be sure to configure your kernel to have max_loop = 24 or more!

    - Create 24 files each 5GB in size. Randomize their contents.  
    - Setup each one as a loop device along these lines: losetup /dev/loop5 /backups/image5  
    - Make each loop device a physical volume: pvcreate /dev/loop5
    - Create a volume group, let's call it 'backup' vgcreate backup /dev/loop3 /dev/loop4 ... /dev/loop27
    - Create a logical volume for that group lvcreate backup/main
    - Cryptsetup, mkfs: cryptsetup create safebackup /dev/mapper/backup-main; mkfs.ext4 /dev/mapper/safebackup
    - Mount it somewhere: mount /dev/mapper/safebackup /mnt/backups
    - Now rsync your backups to that directory rsync -aPv /some/place/with/important/data/ /mnt/backups/ (you can even cpio them, this is still completely local still.) Actually you should probably use rdiff-backup. rdiff-backup /some/place/with/important/data/ /mnt/backups/important-data/
    - To your remote server, rsync the initial image files, which now should contain the files you saved, but encrypted down to their names and even sizes! rsync /backups/image* username@remote.org:\~/backups/

To set up this system again,

    - Setup each one as a loop device losetup /dev/loop23 /backups/image23
    - Poke LVM. lvscan; lvchange -a y
    - cryptsetup: cryptsetup create safebackup /dev/mapper/backup-main
    - mount mount /dev/mapper/safebackup /mnt/backups/

In a cronjob you'll probably want to:

    - rsync in! rdiff-backup /important/stuff/ /mnt/backups/thing/
    - sync just in case sync
    - rsync out! rsync /backups/image* username@remote.org:\~/backups/

To recover, you make sure safebackup is unmounted, then rsync username@remote.org:\~/backups/image* /backups/ . Then just mount again, and copy your backup out of /mnt/backups/. Shazam!

The reason you use multiple image files is because rsync sends a list of hashes of pieces of files, but can avoid that by simply checking timestamps. Whenever you save a file to the backup directory, it propogates through cryptsetup, the volume group, and then writes to one single image leaving the others untouched. That means you only have to check the 5 gigabytes for changed hashes, not the other 23 of them, and rsync can do this intelligently. Since the cryptsetup is in there, nothing but encrypted data ever touches the image files, and thus nothing unencrypted ever gets sent to the (possibly untrustworthy) remote server.

Realistically you'll probably want to keep your backups below 60 gigabytes, more like 2 gigabytes for your emails or something.

Be sure not to use the code literally. It's only vague pseudocode intended as a guideline for you to match to your own special needs.

No ferrets were harmed in the making of this guide.

Я делаю так.

man encfs

я вижу один: во время передачи данных даже если webdav и через https работает, то все равно, на стороне яндекса всяко могут подслушать трафик (передаваемые файлы) и тогда толку шифровать их вообще нет

Исходите из предположения, что шифрует железо Яндекса? Чудно.

во время передачи данных даже если webdav и через https работает, то все равно, на стороне яндекса всяко могут подслушать трафик (передаваемые файлы) и тогда толку шифровать их вообще нет. угу?

Нет

encfs/ecryptfs. Использую 1е с dropbox+pam_mount