Relayium CLI と SSH で自分のサーバーにファイルをバックアップする

始める前に

以下はすべて relayium CLI なので、未インストールならまず入れてください。macOS または Linux では、1つのコマンドでビルド済みバイナリが PATH に入ります：

curl -fsSL https://relayium.com/install.sh | sh

• 自分でファイルを選びたい、または Windows の場合は、リリースページからバイナリを取得してください——relayium.com/cli にすべてのインストール方法があります（Go があれば go build ./cmd/relayium も可）。
• relayium --version でインストールを確認できます。これをしないと以下のコマンドは「command not found」と出るだけです。

ディレクトリをサーバーへ push する

push は1つ以上のソースと scp 形式の宛先を受け取ります。Relayium はいつも使っている鍵と設定を使って SSH 経由で接続し、ファイルを宛先ディレクトリへストリーミングします：

1. push が再利用する SSH アクセスを確認します。黙って戻れば、鍵もホストエイリアスもポートもすでに正しいということです。

   ssh user@your-server true

2. どちらのプロトコルになるかを調べます。パスが表示されればネイティブプロトコル（送信前の衝突チェックとファイル単位の SHA-256）、何も出なければ tar ストリームの方で、こちらはファイル単位では何も検証しません。

   ssh user@your-server command -v relayium

3. ディレクトリを push します。宛先は scp 形式で、末尾のスラッシュは「このディレクトリの中へ」を意味します。

   relayium push ./photos user@your-server:backups/

4. ssh の設定にそのホストがまだ無い場合は、このコマンドに限って鍵やポートを指定します。

   relayium push -i ~/.ssh/id_ed25519 -p 2222 ./photos user@your-server:backups/

5. 何が届いたかを確認します。push ./photos は宛先の下に photos/ を再現するので、フォルダー名もそのまま付いてきます。

   ssh user@your-server ls backups/photos

relayium push ./photos user@your-server:backups/
  photos/IMG_0413.jpg (2314518 bytes)
  photos/IMG_0414.jpg (1998233 bytes)

# against a server with no relayium installed, one summary line instead:
sent 2 file(s) (zero-dependency mode)

• 既存の ~/.ssh/config を再利用するので、すでに設定済みのホストエイリアス、鍵、ポートがそのまま使えます。
• サーバーに relayium がインストールされていれば、ネイティブプロトコルを使います。送信前にバッチ全体の衝突チェックを行い、転送する各ファイルを SHA-256 で検証してから設置します。
• インストールされていない場合は、tar ストリームをリモートへパイプする方式にフォールバックするので、relayium のない素のサーバーでも動作します。

ファイルを pull で戻す

復元は同じコマンドを逆にするだけです。リモートのソースとローカルの宛先ディレクトリを指定します。これがバックアップを復元したり、サーバーの出力をノート PC に同期したりする方法です：

relayium pull user@your-server:backups/ ./restore

• push と異なり、pull は常にリモートに relayium がすでにインストールされている必要があります。tar フォールバックがないため、なければ先にそちらへインストールしてください。

整合性は標準で備わっている——再開は備わっていない

relayium が両端にあれば、push が転送する各ファイルは SHA-256 ハッシュでエンドツーエンドに検証され、暫定領域に置かれてから設置されます。サーバーに届くものは送ったものとバイト単位で同一です。ここまでは本当で、宛先に relayium を入れる理由もそこにあります。

push がしないのは再開です。ファイルは通過した順に1つずつ設置されるため、途中で接続が切れると、すでに届いたファイルはそのまま残ります。そしてそれらが存在するせいで、同じ push をやり直しても衝突チェックに拒否されます。足りないパスを個別に push するか、すでに一致するものを飛ばし、半端なファイルを次回の実行で続けてくれる relayium sync を使ってください。

--no-resume は push と pull でも受け付けられますが、そこでは何もしません。実際に効くのは sync を受ける serve の待ち受け側です——半端なファイルが存在しうるのは、そもそもそこだけだからです。

• push も pull も、どちらのプロトコルでも再開しません。中断されうるディレクトリには sync を使ってください。tar フォールバックは再開もせず、ファイル単位の検証もしません。
• SHA-256 チェックは自動的に実行され、不一致があれば報告され、そのファイルは失敗としてフラグが立てられます。

cron でスケジュール実行する

cron に入れるのは push ではなく sync です。push は既存の宛先を拒否するので、同じディレクトリへ毎晩 push すると初回だけ成功し、以降は毎回拒否されます。sync は繰り返し実行のために作られたモードで、サイズと更新時刻が変わっていないファイルを飛ばし、変わった分だけを送り、中断された実行が残した半端なファイルを続けます。SSH 鍵を使う単一の非対話型コマンドなので、そのまま cron に入ります。パスフレーズなしの鍵（または agent）を指定し、出力をログに残して失敗を確認できるようにしましょう：

# 毎晩2時にバックアップ（crontab -e で crontab に追加）
0 2 * * * relayium sync -i ~/.ssh/backup_key ~/documents user@your-server:backups/ >> ~/relayium-backup.log 2>&1

• 中断された夜間の sync は翌晩そのまま続きます。すでに一致するものは飛ばされ、半端なファイルはやり直しではなく続きから送られます。
• いずれかのファイルが整合性チェックに失敗すると、コマンドは非ゼロで終了するので、cron の失敗時メール通知で問題に気づけます。

バックアップが届かないとき

スケジュール実行のバックアップは、その性質上ひっそりと失敗します。誰も端末を見ていないからです。次の4つでほぼ尽きますし、どれも今すぐ実行できるコマンドで判定できます。