著者は、 Write for DOnations プログラムの一環として、 Free and Open SourceFundを選択して寄付を受け取りました。

序章

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

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

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

前提条件

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

  • Ubuntu16.04ガイドを使用した初期サーバーセットアップを使用して構成された2つのUbuntu16.04サーバー。
  • VPSガイドでCronを使用してタスクを自動化する方法を読んでcrontabエントリを作成する方法に精通していること。

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

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

ステップ1—追加の非ルートユーザーの作成

Ubuntu 16.04 を使用した初期サーバー設定チュートリアルでは、プライマリバックアップの両方でsammyという非ルートsudoユーザーを作成する手順を説明しました。サーバ。 このステップでは、2つの新しいユーザーを作成します。1つは primary サーバー上に、もう1つはbackupサーバー上に作成します。 これにより、ガイドを操作する際の混乱を防ぐことができます。ガイドの最後でSSHセキュリティ構成が有効になっている場合は、backupサーバーでroot以外のsudoユーザーを使用する必要があります。

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

  1. ssh [email protected]primary_server_ip
  2. ssh [email protected]backup_server_ip

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

  1. sudo adduser primary_user

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

  1. sudo usermod -aG sudo primary_user

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

  1. su - primary_user

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

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

ステップ2—両方のサーバーにUnisonをインストールする

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

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

  1. sudo apt-get update

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

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

  1. sudo apt-get install unison

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

ステップ3—SSHキーの作成とSSHの構成

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

プライマリサーバーでそのキーペアを取得したら、公開キーをバックアップサーバーにコピーし、UnisonがSSHを使用してサーバー間で通信できることをテストします。

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

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

  1. 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キーを作成します。

  • .ssh/unison-primary
  • .ssh/unison-primary.pub

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

cat .ssh/unison-primary.pub

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

  1. nano .ssh/authorized_keys

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

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

  1. ssh -i .ssh/unison-primary backup_user@backup_server_ip

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

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

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

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

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

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

Output
unison version 2.48.3

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

ステップ4—ユニゾンの設定

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

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

  1. mkdir .unison

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

  1. nano .unison/default.prf

次に、次のように入力します。

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

これらの2つの線は次のように意味します。

  • force:これにより、変更がのみプライマリサーバーからバックアップサーバーにプッシュされます。 /home/primary_user/dataパスは、バックアップするデータを保持するディレクトリの場所です。
  • sshargs:このオプションは、生成したSSHキーを使用するようにUnisonに指示します。

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

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

ステップ5—Unisonを使用したディレクトリのバックアップ

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

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

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

  1. mkdir data/

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

  1. touch data/file{1..5}

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

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

  1. unison -batch -auto /home/primary_user/data ssh://backup_user@backup_server_ip//home/backup_user/data

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

  • batch:質問せずに実行します。
  • auto:競合しないアクションを自動的に受け入れます。

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

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

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

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

Output
Contacting 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が同期したデータについて説明します。

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

Output
Contacting 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.

これは、/data/file1primaryサーバーで変更された場合の出力です。

Output
Contacting 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ディレクトリの正確なコピーを保持します。

警告: Unisonを実行すると、backupサーバーのdataディレクトリにある新しいファイルや変更が失われます。

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

ステップ6—ユニゾンCronジョブの作成

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

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

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

  1. 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

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

  1. crontab -e

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

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

...
* */3 * * * /usr/bin/unison -log -logfile /var/log/unison.log -auto -batch -silent /home/primary_user/data ssh://backup_user@backup_server_ip//home/backup_user/data

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

  • -silent:エラーを除くすべての出力を無効にします。 Unisonをcrontabから実行する場合は、読み取る人がいないため、通常の出力は必要ありません。
  • -log:ユニゾンにアクションをログに記録するように指示します。
  • -logfile:ユニゾンがアクションをログに記録する場所を指定します。

この例では、ユニゾンは3時間ごとに実行されます。 これは、要件をより適切に満たす任意の頻度に変更できます。

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

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

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

  1. sudo touch /var/log/unison.log

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

  1. sudo chown primary_user /var/log/unison.log

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

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

ステップ7(オプション)—SSHの保護

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

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

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

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

  1. 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サービスをリロードして、新しい構成を有効にします。

  1. sudo systemctl reload ssh.service

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

  1. ssh -i .ssh/unison-primary [email protected]backup_server_ip

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

Output
Unison 2.48

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

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

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

結論

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

Unisonを使用する必要があるかどうかを判断するときは、次の点を考慮する必要があります。

  • ファイルの数が少ない場合やデータの量が少ない場合は、ユニゾンが最適な選択ではない可能性があります。 この場合、rsyncがより適切な選択になります。 rsyncの使用について詳しくは、Rsyncを使用してVPSガイドでローカルディレクトリとリモートディレクトリを同期する方法を参照してください。

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