web-dev-qa-db-ja.com

Rsync：受信側でtruecryptをオンザフライでマウントする方法は？

短いバージョン：truecryptボリュームにrsyncバックアップを保持するにはどうすればよいですか？難しいのは、rsyncに必要なときに、このボリュームをオンザフライでマウント/アンマウントすることです。

詳細

これは私の現在のバックアップ構成です（ほとんどの部分でかなりうまく機能します）：

  • バックアップソースはWin764ビットで、宛先はリモートLinuxボックス（Debian）です。
  • 実際のデータ転送は、sshを介してrsyncによって行われます（cygwinを使用したcwRsync）
  • rsyncデーモンはsshを介してオンデマンドで開始されます

Linuxボックスでは、バックアップはファイルのアクセス許可によってのみ保護されます。ここでセキュリティを強化し、バックアップをtruecryptボリュームに入れたいと思います。そのボリュームをシェルに手動でヒューズマウントできます。問題は、rsyncにssh接続を開いてrsyncデーモンを起動させるだけでなく、truecryptボリュームを前にマウントする（そして後でアンマウントする）にはどうすればよいかということです。

私のお金はオプション--rsync-pathにあります。これは、コマンドラインをsshに渡すために使用できます。ただし、stdinとstdoutが同じように機能する場合に限ります。コマンドはシェルスクリプトでなければならないと思います。これは可能ですか？スクリプトはどのようになりますか？

参考までに、そのオプションの引用を次に示します。

--rsync-path=PROGRAM

これを使用して、rsyncを起動するためにリモートマシンで実行するプログラムを指定します。多くの場合、rsyncがデフォルトのリモートシェルのパスにない場合に使用されます（例：--rsync-path=/usr/local/bin/rsync）。 PROGRAMはシェルの助けを借りて実行されるため、標準入力と標準入力を破損しない限り、実行したい任意のプログラム、スクリプト、またはコマンドシーケンスにすることができます。 rsyncが通信に使用していることを確認します。

トリッキーな例の1つは、--relativeオプションで使用するためにリモートマシンに別のデフォルトディレクトリを設定することです。例えば：

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

これは完全です rsyncのマニュアルページ 。

backuprsynctruecrypt
3
deepc

その間、私は問題を解決し、数週間から私のために働く解決策を持っています。誰かが興味を持っている場合に備えて、私はここに詳細を投稿しています。トロイジョンソンによるこの 記事 は途中で助けました。

前提条件

  • Linuxにインストールされ、パスで利用可能なTruecrypt
  • /home/deepc/var/backup.tcで準備および入手可能なTCコンテナ
  • cygwinとrsyncがWindowsにインストールされ、パスで利用可能

Linux

LinuxボックスでTruecryptコンテナをマウントおよびアンマウントするために2つのシェルスクリプトを作成しました。これらのスクリプトは、Windowsマシンからsshを介してリモートで呼び出されています。

〜/ 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

ウィンドウズ

remote-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 [email protected] 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 [email protected]:/home/deepc/mnt
ssh -p THESSHPORT -i ../.ssh/id_dsa [email protected] bin/backup-umount.sh

このバッチファイルをタスクスケジューラに配置します。毎日のスケジュールで。ユーザー名、リモートホスト、sshポート、Truecryptコンテナのパスワード、そしてもちろんバックアップパスを必ず調整してください。申し訳ありませんが、すでに多くの時間を無駄にした後、これ以上クリーンアップすることはできませんでした...

このスクリプトを使用すると、Rsyncは2つのテキストファイルに含まれるものと含まれないものを読み取ります。例：

files-from.txt：

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

excludes.txt：

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

完了しましたか？

これは元の質問への回答です。マイナーな問題は1つだけです。Windowsのファイル名の特殊文字がLinuxでマングルされ、ext2がLinuxのTCコンテナで使用されています。考えられる--iconvパラメーターのすべての組み合わせを試しましたが、役に立ちませんでした。私はそれと一緒に暮らす必要があるようです-勇敢な魂がここまで読んで、答えを知っていて、コメントで私を啓発しない限り;-）（コンテナ内のNTFSはオプションではありません）

1
deepc

私は似たようなことをしようとしてきました。ラップトップにTruecryptコンテナがあり、NAS上の場所と同期したいと考えています。双方向の同期が必要なため、rsyncではなくUnisonを使用していますが、Unisonはrsyncプロトコルを実装しているため、操作は同様である必要があります。

私は、TCコンテナーがマウント解除されているときに同期するというアイデアを使用し、TCがコンテナーの一部を変更するのは、少数のデータ変更が行われた場合のみであるという事実に依存しています。ただし、私が見つけた問題は、コンテナのサイズ（20GB以上）が原因で、CPUの電力がかなり低い宛先（NAS）がコンテナファイル全体をチェックサムしてかどうかを判断する必要があるため、同期に永遠に時間がかかることです。変更されました。実際の転送はかなり速いですが、CPUを噛むまでに長い時間がかかります。

そこで、代わりに、deepcが取り組んできた別のアプローチに移行し、リモートエンドにコンテナーをマウントしてから、コンテンツを同期しました。これは、何も変更されていない場合に同期に数秒かかるため、はるかに高速です（他のアプローチでは45分を超えるのとは対照的です）。もともとこのアプローチを妨げていた唯一の考えは、TCを自分のNAS（ARMベース）でコンパイルできなかったということでしたが、今はその問題を解決し、すべてが実際に機能していますさて。

この点では、YMMVと「true」rsyncの方がUnisonよりも優れていると思います。しかし、私はコンテナ自体ではなく、コンテナの内容の同期を使用します。

1
David

Truecryptコマンドラインインターフェースを使用します。

truecrypt --mount file --password=password

動作するはずであり、truecrypt-hはあなたにいくつかのアイデアを与えるはずです。ただし、パスワードはrsyncファイルにプレーンテキストで保存する必要があります。宛先ボックスのbash履歴に記録されないように注意してください。そうしないと、追加されたセキュリティが失われます。悪意のある攻撃者がhistory | grep truecryptを呼び出し、パスワードを確認してバックアップを取得する可能性があります。

0
user54114

Rsyncはtruecryptコンテナの内部を調べることなく効率的に増分バックアップを実行できるように見えるため、実際にはこれを行う必要はないかもしれません。注：これを行う動機は、インクリメンタルコピーのメリットを享受することであると想定していますが、これは質問者の意図ではない可能性があります...

Truecryptディスクイメージの内部構造により、リモートの場所に効率的にrsyncすることが可能になったことを喜んで報告します。つまり、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〜3GBを転送します...

私はこれをすぐにテストします、私の発見でここにコメントします。

0
Jon M

TruecryptボリュームがWindowsにファイルとして存在する場合は、ファイルをLinuxマシンにコピーしてみませんか？次に、転送中に暗号化され、宛先に到達したときにすでに暗号化されています。それに加えて、資格情報を使用する必要がないという事実...

WindowsマシンがVSSをサポートしている場合は、プラグを抜いてマシンをシャットダウンした場合と同じように、マウントされたファイルシステムのコピーを取得できる可能性があります。

ボリュームがファイルとして存在しない場合、これはそれほど簡単ではない可能性があります。また、VSSの使用をプログラムする方法がわかりませんが、バックアップ時に使用するスナップショットを作成することは理解しています。 （詳細についてはあまり知りません）。

0
Slartibartfast