Relayium

cron で暗号化されたサーバーバックアップを自動化する

最終更新: 2026-08-06

自分で覚えて実行しなければならないバックアップは、たいてい実行されません。cron は覚えていてくれますし、Relayium CLI はまさにそのために作られています。ディレクトリを別のマシンへコピー（またはミラー）し、すべてのファイルを検証し、ネットワークが切れても中断した所から再開する、単一の非対話型コマンドです。

本ガイドでは、cron から relayium push と増分同期の relayium sync をスケジュール実行する方法、どちらでも使える2つの転送方式、そしてそのままコピーできる crontab の行を扱います。

push と sync：全体コピーか増分ミラーか

push と sync はどちらもディレクトリを別のマシンへ転送し、どちらも繰り返し実行して安全ですが、解決するバックアップの課題は少し異なります。

push は実行するたびに SSH または daemon-direct 経由で毎回コピーを送ります。シンプルで、relayium がインストールされていない素のサーバーに対しても tar フォールバックで動作します。一方 sync は宛先をソースの増分・一方向ミラーとして維持します。変更されたファイルだけを再送するので、大きなディレクトリでも最初の同期の後は夜間の同期が高速です。sync は常に両端で relayium のネイティブプロトコルを必要とします。tar フォールバックはありません。

始める前に

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

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

2つの転送方式：SSH か daemon-direct か

どちらのコマンドも、SSH の宛先（scp 形式、お使いの ~/.ssh/config を使用）を指定できますし、相手のマシンで relayium serve が動いていれば、SSH なしで daemon-direct プロトコル経由で直接接続することもできます。

# SSH の宛先：既存の SSH 鍵と設定をそのまま使います
relayium push ./data user@backup-server:/srv/backups/

# daemon-direct：宛先で "relayium serve" が動いていれば SSH は不要です
relayium push ./data relayium://backup-server:9031

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

手順1の前に必要なもの

  • このマシンの CLI。sync を使うつもりなら送り先にも必要です。sync に tar のフォールバックはありません。
  • パスフレーズなしの SSH 鍵、または relayium serve が動いている送り先。cron にはエージェントも端末もないため、パスフレーズの入力には答えられません。
  • cron が起動する時点で実在するソースディレクトリ。ログイン中だけマウントされるネットワーク領域では困ります。
  • ログの書き出し先。出力がどこにも残らない cron ジョブは、必要になったときに初めて問題が分かるバックアップです。

push と sync はどちらも単一の非対話型コマンドなので、そのまま crontab に組み込めます。パスフレーズなしの鍵（または agent）を指定し、出力をログに残して失敗を確認できるようにしましょう：

# 毎晩2時に全体コピー：crontab に追加します（crontab -e）
0 2 * * * relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-backup.log 2>&1

# 代わりに15分ごとの増分ミラー
*/15 * * * * relayium sync -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-sync.log 2>&1

  1. relayium が実際にどこにあるかを調べます。cron はシェルの PATH を使わず、install.sh は /usr/local/bin に書けないとき ~/.local/bin に置きます——まさに cron から見えない場所です。

    command -v relayium

  2. 誰も鍵盤の前にいない状態でも鍵が使えるか確認します。BatchMode=yes は入力を促さずに失敗するので、cron と同じ条件です。

    ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true

  3. まず手で一度、cron が実行するのとまったく同じ書き方で、絶対パスも含めて通しで実行します。

    /usr/local/bin/relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/

  4. それが通ってからスケジュールを追加します。絶対パスとリダイレクトはそのまま残してください。

    crontab -e

  5. 最初の定期実行のあと、思い込まずにログを読みます。ここが最も飛ばされやすく、そして問題を教えてくれたはずの手順です。

    tail -n 20 ~/relayium-backup.log

正しく設定できたときの見え方

relayium が crontab にそのまま貼れる絶対パスとして解決され、BatchMode 付きの ssh 確認が何も表示せず何も尋ねずに終了コード0で終わります。対話シェルでしか動かないバックアップは、まだスケジュールされていません。

$ command -v relayium
/usr/local/bin/relayium
$ ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
$ echo $?
0

削除のミラーリングとリアルタイム同期

デフォルトでは、sync は宛先側でファイルを追加または更新するだけです。--delete を付けると真のミラーになり、ソースにもう存在しないファイルも削除します。受信側は serve --allow-delete で明示的に待ち受けている必要があり、そうでなければ削除は黙って無視され、拒否されたと結果に報告されます。ソースディレクトリが1つもファイルを解決しない場合、sync は --delete の実行そのものを拒否するので、ソースパスの誤字で宛先が消えてしまうことはありません。

cron の次の実行タイミングを待ちたくない場合は、--watch を使うと relayium sync が動き続け、ソース配下のファイルが変化するとすぐに自動で再同期します。スケジュールでポーリングする代わりの軽量な選択肢です。

うまくいかないとき

どれもログを見るまでは表に出ません。だからログのリダイレクトは crontab の行に最初から入っていて、任意ではないのです。5つめは見えないより厄介で、成功したように見えます。

症状、確認、対処

ログに relayium: command not found と出るのに、同じコマンドがシェルでは動く。
tail -n 5 ~/relayium-backup.log
# /bin/sh: relayium: command not found

cron は最小限の PATH、たいてい /usr/bin:/bin だけで動きます。install.sh が /usr/local/bin に書けなかった場合、バイナリは ~/.local/bin に置かれ、cron はそこを決して探しません。command -v が示す絶対パスを crontab の行に書くか、crontab の先頭に PATH= の行を足してください。

ログに ssh 接続の拒否が出る、または初回以降なにも記録されない。
ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
# Permission denied (publickey).

cron には ssh-agent も端末もないため、パスフレーズ付きの鍵は固まるか失敗するかしかありません。-i でバックアップ専用のパスフレーズなし鍵を指し、BatchMode=yes で確認してください。これは、そこにいない人を待つ代わりに入力を拒否します。

sync は問題なく走るのに、ソースで削除したファイルが送り先に残っている。
grep -i deni ~/relayium-sync.log

削除は受信側のオプトインです。相手側に serve --allow-delete がなければ削除はスキップされ、denied として報告されます。答えが終了コードではなくログにあるのはそのためです。受信側のリスナーを --allow-delete 付きで再起動してください。

sync が --delete をきっぱり拒否する。
relayium sync ~/documents user@backup-server:/srv/backups/ --delete
# refusing --delete with an empty source: this would delete everything on the destination. Check the path(s).

ソース側が1ファイルも解決できず、そのままではミラーが送り先を空にしてしまう状態です。この拒否は意図的です。パスの打ち間違いを確認し、そこにマウントされるはずのものが、ログイン中だけでなく cron の起動時点でも実際にマウントされているかを確認してください。

バックアップは走り、終了コード0で終わるのに、中身は思っているものではない。
ssh user@backup-server command -v relayium

リモートに relayium がないとき、push は SSH 上の素の tar ストリームにフォールバックします。ファイルは届くので何も文句を言いませんが、その経路にはファイルごとの SHA-256 検証も再開もありません——scp ではなくこれをスケジュールする理由そのものが失われます。送り先に CLI を入れれば戻ります。sync にこの失敗はありません。フォールバックが一切ないので、代わりに大きな音を立てて失敗します。

よくある質問

バックアップサーバーに relayium のインストールは必要ですか？

コマンドによります。push はどちらでも動作します。relayium がインストールされていればネイティブプロトコル（再開 + ファイルごとの SHA-256 検証）を使い、なければ push は SSH 上の tar ストリームにフォールバックするので、素のサーバーでも動作します。sync は常にリモート側で relayium のネイティブプロトコルが必要です。sync に tar フォールバックはないので、先にインストールしてください。

バックアップは暗号化・検証されますか？

されます。すべてのファイルはエンドツーエンドで SHA-256 ハッシュによって検証され、SSH または daemon-direct でプッシュする場合、バイトはその接続自体の暗号化によってすでに保護されています。追加の設定は不要です。

cron ジョブが途中で中断された場合はどうなりますか？

両端に relayium があれば、次の予定された実行で部分的なファイルが全体を再送するのではなく再開されます。きれいに全体を再送したい場合は --no-resume を指定してください。

--delete で誤って宛先を消してしまうことはありますか？

sync はソースディレクトリにファイルが1つもない場合、--delete の実行自体を拒否します。また、削除が実際に反映されるには受信側が serve --allow-delete で起動されている必要があります。そうでなければスキップされ、結果として報告されます。

アカウントは必要ですか、これは有料ですか？

いいえ。CLI は無料で、push、pull、sync のいずれにもアカウントは不要です。転送はご自身の SSH 接続、または直接の daemon 接続の上で行われ、Relayium のサーバーは経由しません。

覚えておかなくていいスケジュールにバックアップを乗せましょう。暗号化、再開可能、そして無料です。

CLI を入手

続けて読む