Ubuntu 16.04でUnisonを使用して大きなディレクトリをバックアップする方法

著者は、Write for DOnationsプログラムの一部として寄付を受け取るためにFree and Open Source Fundを選択しました。

前書き

Unisonは、オープンソースのファイル同期ツールです。 少数のファイルのみが追加または更新された大規模なデータコーパスのバックアップに非常に効率的です。 この状況は、たとえば、企業のSambaファイルサーバーまたは電子メールサーバーで発生します。

これらのサーバーの大部分のファイルは同じままですが、毎日少数のファイルが追加または変更されます。 Unisonは、数百万のファイルとテラバイトのデータがある場合でも、これらの新しいファイルを非常に迅速に検出およびバックアップできます。 このような状況では、rsyncなどの従来のツールは、同じバックアップ操作を実行するのに長い時間がかかる可能性があります。

このチュートリアルでは、1組のサーバーにUnisonをインストールして構成し、それを使用してディレクトリをバックアップします。 また、SSHを安全な通信プロトコルとして使用するようにUnisonを構成し、cron jobを作成して定期的にUnisonを実行します。

前提条件

このガイドを始める前に、次のものが必要です。

このガイドでは2つのサーバーを使用します。

  • primaryサーバー:バックアップするデータをホストするサーバー。

  • backupサーバー:バックアップされたデータをホストするサーバー。

[[step-1 -—- creating-additional-non-root-users]] ==ステップ1—追加の非ルートユーザーの作成

Initial Server Setup with Ubuntu 16.04チュートリアルでは、primaryサーバーとbackupサーバーの両方でsammyという非rootsudoユーザーを作成する方法を説明しました。 このステップでは、2人の新しいユーザーを作成します。1人はprimaryサーバーに、もう1人はbackupサーバーに作成します。 これにより、ガイドを読み進める際の混乱を防ぐことができます。ガイドの最後でSSHセキュリティ構成が有効になっている場合は、backupサーバーで代替の非rootsudoユーザーが必要です。

2つのターミナルウィンドウでSSH経由でsammyユーザーとしてprimaryサーバーとbackupサーバーの両方にログインする必要があります。 次の2つのSSHコマンドは、これらのサーバーにログインします。

ssh [email protected]_server_ip
ssh [email protected]_server_ip

まず、primaryサーバーで、次のコマンドを使用してprimary_userという新しいユーザーを作成します。

sudo adduser primary_user

次に、sudoのアクセス権を付与します。

sudo usermod -aG sudo primary_user

最後に、primary_userアカウントに変更します。

su - primary_user

次に、backupサーバーで同じ手順を実行しますが、backup_userという名前の新しいユーザーを作成します。 ガイドの残りの部分では、これらのユーザーとしてprimaryおよびbackupサーバーにログインしていることを確認してください。

両方のサーバーで必要なユーザーを作成したので、Unisonソフ​​トウェアのインストールに進むことができます。

[[step-2 -—- installing-unison-on-both-servers]] ==ステップ2—両方のサーバーにUnisonをインストールする

この手順では、両方のサーバーにUnisonパッケージをインストールします。

Ubuntuパッケージマネージャーaptを使用して、両方のサーバーにUnisonをインストールします。 久しぶりにaptを使用する場合は、次のコマンドでローカルパッケージインデックスを更新する必要があります。

sudo apt-get update

これにより、Unisonの最新バージョンを確実にインストールできます。 これは、インストールエラーの回避にも役立ちます。

次に、Unisonをインストールします。

sudo apt-get install unison

これで、Unisonのインストールが完了しました。 次のステップでは、Unisonが2つのサーバー間で通信できるようにSSHを構成します。

[[step-3 -—- creating-ssh-keys-and-configuring-ssh]] ==ステップ3—SSHキーの作成とSSHの構成

SSH接続にキーベースの認証を使用するため、最初に行う必要があるのは、primaryサーバー上にSSHキーペアを作成することです。 キーベース認証の利点は、パスワードを入力せずに安全な接続が可能なことです。 パスワードが発生するたびにパスワードを入力せずに実行する必要がある自動バックアップ手順を作成するため、これは重要です。

primaryサーバーにそのキーペアを配置したら、公開キーをbackupサーバーにコピーし、UnisonがSSHを使用してサーバー間で通信できることをテストします。

SSHキーペアを作成するとき、通常は強力なパスワードを使用します。 ただし、Unisonは自動的に実行されるため、実行するたびにパスワードを手動で入力することはできません。 パスワードを入力せずにENTERキーを押します。 これにより、パスワードなしのSSHキーペアが生成されます。

primaryサーバーのprimary_userホームディレクトリから次のコマンドを実行して、SSHキーペアを生成します。

ssh-keygen -t rsa -b 4096 -f .ssh/unison-primary

ここで使用されるオプションは次を意味します。

  • -t rsa:作成されるキーのタイプを設定します。 RSAキーは、最も互換性のあるタイプです。

  • -b 4096:キーの長さを設定します。 キーが長いほど、安全性が高くなります。 4096のキー長は、RSAキーの現在の推奨キー長です。

  • -f .ssh/unison-primary:キーの名前と保存場所を設定します。 この場合、選択した名前を使用して、SSHのデフォルトディレクトリ.sshにキーを保存します。

上記のコマンドは、次の2つのファイルに公開および秘密SSHキーを作成します。

  • .ssh/unison-primary

  • .ssh/unison-primary.pub

最初は秘密のSSHキーで、2番目は公開キーです。 公開鍵ファイルの内容をbackupサーバーにコピーする必要があります。 コピー用の公開鍵ファイルの内容を表示する最も簡単な方法は、catコマンドを使用して内容を端末に出力することです。

cat .ssh/unison-primary.pub

backup_userホームディレクトリのbackupサーバーで、テキストエディタを使用して.ssh/authorized_keysファイルを開きます。 ここでは、nanoを使用します。

nano .ssh/authorized_keys

公開キーをエディターに貼り付け、保存して終了します。

これで、SSH経由でprimaryサーバーからbackupにログインすることにより、SSH構成が機能していることをテストできます。 backupサーバーのSSHサーバーのキーフィンガープリントを受け入れて保存する必要があるため、これは重要です。そうしないと、Unisonが機能しません。 primaryサーバー上のターミナルで、primary_userのホームディレクトリから次のコマンドを実行します。

ssh -i .ssh/unison-primary [email protected]_server_ip

-i .ssh/unison-primaryオプションは、SSHに特定のキーまたはIDファイルを使用するように指示します。 ここでは、作成した新しいunison-primaryキーを使用します。

Y、次にENTERを押して指紋を受け入れ、ログインおよびログアウトします。 サーバー間でSSHが機能することを確認し、backupサーバーのSSHフィンガープリントを保存する必要がありました。 指紋は手動でのみ保存できるため、チュートリアルの後半でプロセスを自動化する前に行う必要があります。

次に、primaryサーバーのprimary_userホームディレクトリから次のコマンドを実行して、Unisonが接続することを確認します。

ssh -i .ssh/unison-primary [email protected] unison -version

このコマンドでは、最後にUnisonコマンドを追加して、接続のテストに使用したのと同じSSHコマンドを使用しました。 コマンドがSSH接続の最後に配置されると、SSHはログインし、コマンドを実行してから終了します。 unison -versionコマンドは、バージョン番号を出力するようにUnisonに指示します。

すべてが機能している場合は、backupサーバー上のUnisonのバージョンを示す応答が表示されます。

Outputunison version 2.48.3

UnisonがSSHキーを使用してサーバー間で通信できることを確認したので、Unisonの構成に進む準備ができました。

[[step-4 -—- configuring-unison]] ==ステップ4—Unisonの構成

このステップでは、primaryサーバーからbackupサーバーへのディレクトリで単純な一方向バックアップを実行するようにUnisonを構成します。

Unisonを構成するには、最初に、primaryサーバー上のprimary_userのホームディレクトリの下に構成ディレクトリを作成する必要があります。

mkdir .unison

次に、.unisonディレクトリのテキストエディタでdefault.prfという名前の新しいファイルを開く必要があります。 このファイルにはUnison設定が含まれています。 次のコマンドでファイルを開きます。

nano .unison/default.prf

次に、次を入力します。

default.prf

force = /home/primary_user/data
sshargs = -i /home/primary_user/.ssh/unison-primary

これらの2行の意味は次のとおりです。

  • force:これにより、変更がprimaryサーバーからbackupサーバーにプッシュされるようになります。 /home/primary_user/dataパスは、バックアップするデータを保持するディレクトリの場所です。

  • sshargs:このオプションは、生成したSSHキーを使用するようにUnisonに指示します。

バックアップするデータを保持するディレクトリがprimary_userホームディレクトリの下にない場合は、primary_userによって読み取りおよび書き込み可能であることを確認する必要があります。 Linuxの所有権と権限に慣れていない場合は、Introduction to Linux Permissionsガイドで詳細を確認してください。

これで、Unisonが構成され、ディレクトリをバックアップしてテストに進むことができます。

[[step-5 -—- backing-up-a-directory-with-unison]] ==ステップ5—Unisonを使用したディレクトリのバックアップ

Unisonが設定されたので、ディレクトリをバックアップする準備ができました。 primaryサーバーの/home/primary_user/dataディレクトリをbackupサーバーの/home/backup_user/data/ディレクトリにバックアップします。 mustをバックアップするデータを含むディレクトリは、forceオプションの横にある.unison/default.prfに配置したディレクトリと同じです。

Unisonが機能していることをテストするには、バックアップするためのデータが必要になります。 primaryサーバーに空のファイルをいくつか作成し、Unisonがそれらをbackupサーバーに転送したかどうかを確認します。

まず、primary_userホームディレクトリから次のコマンドを実行して、バックアップするデータを保持するディレクトリを作成します。

mkdir data/

次に、touchコマンドを使用して、5つの空のファイルを作成します。

touch data/file{1..5}

コマンドの最後の部分であるfile{1..5}は、Bashブレース展開を使用して5つのファイルを作成します。 bashに{1..5}を指定すると、不足している数値、23、および4が自動的に入力されます。 この手法は、複数のファイルをすばやく列挙するのに役立ちます。

dataディレクトリとバックアップするいくつかのテストファイルができたので、Unisonを実行してファイルをbackupサーバーにバックアップできます。 次のコマンドでこれを行います。

unison -batch -auto /home/primary_user/data ssh://[email protected]_server_ip//home/backup_user/data

これらのオプションの意味は次のとおりです。

  • batch:質問せずに実行します。

  • auto:競合しないアクションを自動的に受け入れます。

Unisonを単純な一方向同期モードで使用しているため、競合を解決する必要はありません。 これは、これらのオプションを安全に設定できることを意味します。

競合は、ユニゾンの他の操作モードでのみ発生し、両方向で同期します。 このようなユースケースは、誰かのラップトップとデスクトップのディレクトリを同期することです。 デスクトップ上のファイルを更新するとき、彼らはその変更をラップトップにプッシュすることを望みます。 Unison同期が発生する前に同じファイルが両端で変更され、Unisonが保持するファイルと上書きするファイルを自動的に決定できない場合、競合が発生します。

一方向プッシュモードでは、primaryのデータは常に保持され、バックアップのデータは上書きされます。

このコマンドは、最初の実行時に長いメッセージを出力します。 メッセージは次のようになります。

OutputContacting server...
Connected [//primary_server_ip//home/primary_user/data -> //primary_server_ip//home/backup_user/data]
Looking for changes
Warning: No archive files were found for these roots, whose canonical names are:
        /home/primary_user/data
        //backup_server_ip//home/backup_user/data
This can happen either
because this is the first time you have synchronized these roots,
or because you have upgraded Unison to a new version with a different
archive format.

Update detection may take a while on this run if the replicas are
large.

Unison will assume that the 'last synchronized state' of both replicas
was completely empty.  This means that any files that are different
will be reported as conflicts, and any files that exist only on one
replica will be judged as new and propagated to the other replica.
If the two replicas are identical, then no changes will be reported.

If you see this message repeatedly, it may be because one of your machines
is getting its address from DHCP, which is causing its host name to change
between synchronizations.  See the documentation for the UNISONLOCALHOSTNAME
environment variable for advice on how to correct this.

Donations to the Unison project are gratefully accepted:
http://www.cis.upenn.edu/~bcpierce/unison

  Waiting for changes from server
Reconciling changes
dir      ---->            /
Propagating updates
UNISON 2.48.3 started propagating changes at 16:30:43.70 on 03 Apr 2019
[BGN] Copying  from /home/primary_user/data to //backup_server_ip//home/backup_user/data
[END] Copying
UNISON 2.48.3 finished propagating changes at 16:30:43.71 on 03 Apr 2019
Saving synchronizer state
Synchronization complete at 16:30:43  (1 item transferred, 0 skipped, 0 failed)

この情報は、これが最初の同期であることを警告しています。 また、同期の実行ごとにこのメッセージが表示された場合の問題の解決方法に関するヒントも提供します。 最後のセクションでは、この実行中にUnisonが同期したデータを示します。

後続の実行ごとに、印刷される情報ははるかに少なくなります。 ファイルが更新されていない場合の出力は次のとおりです。

OutputContacting server...
Connected [//primary_server_ip//home/primary_user/data -> //backup_server_ip//home/backup_user/data]
Looking for changes
  Waiting for changes from server
Reconciling changes
Nothing to do: replicas have not changed since last sync.

これは、primaryサーバーで/data/file1が変更されたときの出力です。

OutputContacting server...
Connected [//primary_server_ip//home/primary_user/data -> //backup_server_ip//home/backup_user/data]
Looking for changes
  Waiting for changes from server
Reconciling changes
changed  ---->            file1
Propagating updates
UNISON 2.48.3 started propagating changes at 16:38:37.11 on 03 Apr 2019
[BGN] Updating file file1 from /home/primary_user/data to //backup_server_ip//home/backup_user/data
[END] Updating file file1
UNISON 2.48.3 finished propagating changes at 16:38:37.16 on 03 Apr 2019
Saving synchronizer state
Synchronization complete at 16:38:37  (1 item transferred, 0 skipped, 0 failed)

同期を実行するたびに、backupサーバーはprimaryサーバー上のdataディレクトリの正確なコピーを取得します。

[.warning]#Warning: Unisonを実行すると、backupサーバーのdataディレクトリ内の新しいファイルまたは変更が失われます。

これで、Unisonを実行してディレクトリをバックアップできるようになりました。 次のステップでは、cronを指定してUnisonを実行することにより、バックアッププロセスを自動化します。

[[step-6 -—- creating-a-unison-cron-job]] ==ステップ6— UnisonCronジョブの作成

このセクションでは、Unisonを実行するcronジョブを作成し、dataディレクトリを指定された頻度でbackupサーバーにバックアップします。

crontabは、cronプロセスによって読み取られるファイルです。 含まれるコマンドはcronプロセスにロードされ、指定された間隔で実行されます。

次のコマンドを実行して、現在のユーザーのcrontabの内容を表示できます。

crontab -l

-lオプションは、現在のユーザーのcrontabの内容を一覧表示します。 crontabを以前に編集したことがない場合は、次の情報が表示されます。

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command

次に、-eフラグを指定してprimaryサーバーでcrontabコマンドを実行し、編集モードで開きます。

crontab -e

デフォルトのコマンドラインエディターが設定されていない場合、コマンドを初めて実行するときにエディターを選択するよう求められます。 任意のエディターを選択して、crontabを開きます。

crontabを開いたら、既存のテキストの下の最初の空行に次のコマンドを追加します。

...
* */3 * * * /usr/bin/unison -log -logfile /var/log/unison.log -auto -batch -silent /home/primary_user/data ssh://[email protected]_server_ip//home/backup_user/data

使用するコマンドは、上記の手動バックアップで使用したコマンドとほぼ同じですが、いくつかの追加オプションがあります。 これらの追加オプションは次のとおりです。

  • -silent:エラーを除くすべての出力を無効にします。 Unisonをcrontabから実行する場合、読み取る人がいないため、通常の出力は必要ありません。

  • -log:アクションをログに記録するようにUnisonに指示します。

  • -logfile:Unisonがアクションをログに記録する場所を指定します。

この例では、Unisonは3時間ごとに実行されます。 これは、要件に合った任意の周波数に変更できます。

crontabを編集するときはいつでも、保存して終了する前に常に一番下に空行を置く必要があります。そうしないと、cronがcrontabファイルを正しくロードできません。 これにより、コマンドが実行されない可能性があります。

これらの変更を行ったら、ファイルを保存して閉じます。

次に、Unisonがprimaryサーバーに書き込むログファイルを作成します。 次のコマンドは、このファイルを作成します。

sudo touch /var/log/unison.log

次に、primary_userをファイルの所有者にします。

sudo chown primary_user /var/log/unison.log

/var/log/unison.logのログファイルを読み取ることで、Unisonバックアップのステータスを確認できます。 Unisonは、新規または更新されたファイルをバックアップした場合、またはエラーが発生した場合にのみログを記録します。

現在、Unisonはcrontabから定期的にバックアップしています。 最後のオプションの手順は、SSH構成をより安全にすることです。

[[step-7-optional -—- securing-ssh]] ==ステップ7(オプション)—SSHの保護

このガイドでは、パスワードのないSSHキーを作成して使用しました。 これは、SSH経由でbackupサーバーにログインするときにbackup_userが実行できることを制限することで対処できるセキュリティ上の懸念事項です。

これを行うには、SSH経由でログインしたときにbackup_userが単一のコマンドのみを実行できるようにSSHを構成します。 つまり、作成したSSHキーは、Unisonバックアップの実行にのみ使用でき、それ以外のことはできません。 これにより、backup_userとしてbackupサーバーにSSHで接続できなくなります。 これは、ログインには許可された単一のコマンド以上のものが必要だからです。

backup_userとしてbackupサーバーにアクセスする必要がある場合は、最初にsammyユーザーとしてログインしてから、su - backup_userを使用してbackup_userに変更する必要があります。

/etc/ssh/sshd_configにあるbackupサーバー上のSSH構成ファイルを編集します。

sudo nano /etc/ssh/sshd_config

次に、ファイルの最後に次の行を追加します。

/etc/ssh/sshd_config

Match User backup_user
  ForceCommand unison -server

これらの構成オプションは次のことを行います。

  • Match User:リストされたユーザーがログインすると、SSHは次のインデントされた構成オプションを適用します。

  • ForceCommand:これにより、一致したユーザーが次のコマンドに制限されます。 この場合、backup_userunison -serverコマンドのみを実行できます。

テキストエディターを保存して終了します。 次に、SSHサービスをリロードして、新しい構成を有効にします。

sudo systemctl reload ssh.service

これをテストするには、primaryサーバーからSSH経由でbackup_userとしてbackupサーバーにログインします。

ssh -i .ssh/unison-primary [email protected]_server_ip

/etc/ssh/sshd_config設定が機能している場合は、次のように表示されます。

OutputUnison 2.48

Unisonがコマンドを待機しているため、セッションがCTRLおよびCで強制終了されるまで、SSHセッションはハングします。

これは、ログイン時にUnisonサーバーが自動的に呼び出され、Unisonサーバーとの通信以外では他のアクセスができないことを示しています。

これで、データを必要な頻度でバックアップする、機能する安全なUnisonバックアップシステムが完成しました。

結論

このガイドでは、SSH経由でディレクトリをバックアップするようにUnisonファイル同期ソフトウェアをインストールおよび構成しました。 また、パスワードなしのキーが悪用されないように、指定されたスケジュールでバックアップを自動的に実行し、SSHを保護するようにcronを構成しました。

Unisonを使用する必要があるかどうかを判断する際には、考慮すべきことがいくつかあります。

  • ファイル数が少ない場合やデータ量が少ない場合は、Unisonが最良の選択ではない場合があります。 この場合、rsyncがより適切な選択になります。 rsyncの使用について詳しくは、How To Use Rsync to Sync Local and Remote Directories on a VPSガイドをご覧ください。

  • 大量のデータのバックアップには時間がかかり、パブリックネットワークインターフェイスで帯域幅の割り当てを使い果たす可能性があります。 primaryサーバーとbackupサーバーの両方がDigitalOcean Dropletsである場合、プライベートネットワークを使用すると、Unisonバックアップをはるかに迅速かつ安全に完了することができます。 無料のDigitalOceanプライベートネットワークの詳細については、Private Network Overviewのドキュメントを参照してください。

Related