Rsync: как монтировать truecrypt на лету на принимающей стороне?

Question

Краткая версия: как мне сохранить резервную копию rsync на томе truecrypt? Сложной задачей является монтирование / размонтирование этого тома на лету, когда это необходимо для rsync.

подробности

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

• источник резервных копий находится на 64-битной Win7, назначение - удаленный Linux-пакет (Debian)
• фактическая передача данных осуществляется rsync через ssh (cwRsync с cygwin)
• Демон rsync запускается по требованию через ssh

На коробке Linux резервная копия защищена только правами доступа к файлам. Я хочу повысить безопасность и поместить резервную копию в том с истинным шифрованием. Я могу закрепить этот том вручную в оболочке. Теперь вопрос заключается в том, как заставить rsync не только открыть ssh-соединение и запустить демон rsync, но и смонтировать том truecrypt до (и размонтировать его после)?

Мои деньги идут на опцию --rsync-path которую можно использовать для передачи командной строки в ssh - при условии, что stdin и stdout по-прежнему работают одинаково. Я думаю, что команда должна быть сценарием оболочки. Возможно ли это и как будет выглядеть сценарий?

Для справки вот цитата этого варианта:

--rsync-path=PROGRAM

Используйте это, чтобы указать, какую программу следует запускать на удаленном компьютере для запуска rsync. Часто используется, когда rsync не находится в пути удаленной оболочки по умолчанию (например, --rsync-path=/usr/local/bin/rsync). Обратите внимание, что PROGRAM запускается с помощью оболочки, поэтому она может быть любой программой, сценарием или последовательностью команд, которую вы хотели бы запустить, если только она не повреждает стандартный вход и стандартный выход, который использует rsync. общаться.

Один хитрый пример - установить другой каталог по умолчанию на удаленном компьютере для использования с параметром --relative . Например:

rsync -avR --rsync-path="cd /a/b && rsync" host:c/d /e/

Это полная страница руководства по rsync.

Answer 1

Тем временем я решил любые проблемы и нашел решение, которое работает для меня уже несколько недель. Если кто-то заинтересован, я публикую подробности здесь. Эта статья Троя Джонсона помогла на этом пути.

Предпосылки

• Truecrypt установлен в Linux и доступен по пути
• Контейнер TC подготовлен и доступен по адресу /home/deepc/var/backup.tc
• cygwin и rsync установлены в Windows и доступны по пути

Linux

Я сделал два сценария оболочки для монтирования и размонтирования контейнера Truecrypt на компьютере с Linux. Эти сценарии вызываются удаленно через ssh с компьютера с Windows:

~/ Bin / backup-mount.sh:

#!/bin/bash
# usage: backup-mount.sh <password>
~deepc/bin/backup-umount.sh
echo "$1" | sudo truecrypt -t --slot=2 -k "" --volume-type=normal --protect-hidden=no /home/deepc/var/backup.tc /home/deepc/mnt

~/ Bin / backup-umount.sh:

#!/bin/sh
sudo truecrypt -d /home/deepc/var/backup.tc

Windows

дистанционный Backup.cmd:

@echo off
setlocal
set HOME=c:\home
set LC_ALL=de_DE.utf-8
set LC_CTYPE=de_DE.utf-8
set LANG=de_DE.utf-8

rem --iconv=utf-16,iso-88591
ssh -p THESSHPORT -i ../.ssh/id_dsa deepc@theremotehost.com bin/backup-mount.sh THEPASSWORD
rsync -rltvzPm --modify-window=1 --exclude-from=../etc/backup/excludes.txt --chmod=ugo=rwX --delete --delete-excluded --files-from=../etc/backup/files-from.txt -e "ssh -p THESSHPORT -i ../.ssh/id_dsa" --log-file=../tmp/remote-backup.log /cygdrive deepc@theremotehost.com:/home/deepc/mnt
ssh -p THESSHPORT -i ../.ssh/id_dsa deepc@theremotehost.com bin/backup-umount.sh

Поместите этот пакетный файл в планировщик задач, например, с ежедневным расписанием. Обязательно настройте имя пользователя, удаленный хост, порт ssh, пароль контейнера Truecrypt и, конечно, пути резервного копирования. Извините, но я не мог заставить себя убрать это больше после того, как потратил слишком много времени уже ...

С помощью этого скрипта Rsync будет читать, включает и исключает из двух текстовых файлов, например:

файлы-from.txt:

/c/Home/
/c/Users/deepc
...

excludes.txt:

Firefox/Cache
Firefox/*.lock
Thunderbird/*.lock
Thunderbird/**/*Junk*
Thunderbird/**/filterlog.html
Thunderbird/**/*.msf
Home/tmp
...

Готово?

Это ответ на оригинальный вопрос. Есть только одна незначительная проблема: специальные символы в именах файлов в Windows искажены в Linux, а ext2 используется в контейнере TC в Linux. Я перепробовал все комбинации для параметра --iconv который мог придумать, но безрезультатно. Кажется, я должен с этим смириться - если какая-то храбрая душа не прочитала до этого момента, знает ответ и просвещает меня в комментарии ;-) (NTFS в контейнере не вариант)

Answer 2

Я пытался сделать что-то подобное. На моем ноутбуке есть контейнеры Truecrypt, которые я хочу синхронизировать с местом на моем NAS. Поскольку я хочу двухстороннюю синхронизацию, я использую Unison, а не rsync, но Unison реализует протокол rsync, поэтому должен работать аналогично.

Я использовал идею синхронизации контейнера TC, пока он был отключен, и полагался на тот факт, что TC изменяет только части контейнера, если выполняется небольшое количество изменений данных. Однако проблема, которую я нахожу, заключается в том, что из-за размера контейнера (20 ГБ или более) синхронизация по-прежнему занимает целую вечность, так как пункт назначения (NAS) с достаточно низким энергопотреблением ЦП должен проверить контрольную сумму всего файла контейнера, чтобы решить, это изменилось. Фактическая передача довольно быстрая, но есть много времени, прежде чем она жует процессор.

Итак, вместо этого я перешел к другому подходу, над которым работал deepc, монтируя контейнер на удаленном конце и затем синхронизируя содержимое. Это происходит намного быстрее, если синхронизация занимает порядка нескольких секунд, если ничего не изменилось (в отличие от> 45 минут с другим подходом). Единственная мысль, которая изначально удерживала меня от этого подхода, заключалась в том, что я не смог скомпилировать TC на своем NAS (на базе Arm), но я решил эту проблему сейчас, и теперь все работает очень хорошо.

Я полагаю, что YMMV и 'true' rsync могут быть лучше, чем Unison в этом отношении. Но я бы пошел с синхронизацией содержимого контейнеров, а не самих контейнеров.

Answer 3

Используйте интерфейс командной строки truecrypt.

truecrypt --mount file --password=password

должен работать и truecrypt -h должен дать вам несколько идей. Однако тогда пароль должен быть сохранен в виде простого текста в вашем файле rsync. Будьте осторожны, чтобы убедиться, что он не попадет в историю событий bash в вашем окне назначения, иначе дополнительная безопасность исчезнет - злоумышленник может просто вызвать history | grep truecrypt , посмотрите ваш пароль и создайте резервные копии.

Answer 4

На самом деле это может быть ненужным, так как может показаться, что rsync может эффективно делать инкрементное резервное копирование контейнера truecrypt без необходимости заглядывать внутрь него. Примечание: я предполагаю, что мотивация для этого состоит в том, чтобы получить преимущества инкрементной копии, которая не может быть целью автора вопроса ...

Мы рады сообщить, что внутренняя структура образов дисков TrueCrypt позволяет эффективно синхронизировать их в удаленном месте. Это означает, что после начальной (полной) загрузки вашего образа диска TrueCrypt последующие загрузки будут эффективно передавать только те изменения, которые были внесены в зашифрованную файловую систему с момента последней загрузки.

Находится по адресу http://www.rsync.net/resources/howto/windows_truecrypt.html, а также по ссылке в этой ветке комментариев: http://digg.com/news/technology/TrueCrypt_Tutorial_Truly_Portable_Data_Encryption

rsync не будет повторно отправлять весь файл снова, как это обычно происходит с файлами, зашифрованными с помощью gpg и т. д. Truecrypt изменяет только те части файла, которые требуют изменения

а также

Я использую опции --partial и --inplace, и это работает как шарм. Обычно переносит 2-3 ГБ каждый раз, в зависимости от того, сколько работы я проделал на этой неделе ...

Я скоро опробую это, прокомментирую здесь мои выводы.

Answer 5

Если ваш том truecrypt существует как файл в Windows, почему бы просто не скопировать файл на компьютер с Linux? Затем он шифруется при передаче и уже шифруется, когда попадает в пункт назначения. Добавьте к этому тот факт, что вам никогда не придется использовать учетные данные ...

Если машина Windows поддерживает VSS, вы можете получить копию даже смонтированной файловой системы, которая была бы такой же непротиворечивой, как если бы вы выключили машину, потянув за вилку.

Если том не существует в виде файла, это может быть не так просто. Кроме того, я не знаю, как программировать использование VSS, но я понимаю, что он делает снимок для использования при резервном копировании. (Я не знаю слишком много о деталях).