バックアップと復元

Rediaccは暗号化されたリポジトリを外部ストレージプロバイダにバックアップし、同じマシンまたは別のマシンで復元できます。バックアップは暗号化されており、復元にはリポジトリのLUKS認証情報が必要です。

ストレージの設定

バックアップを送信する前に、ストレージプロバイダを登録します。Rediaccはrclone互換のストレージをすべてサポートしています：S3、B2、Google Driveなど。

rcloneからのインポート

既にrcloneリモートが設定されている場合：

rdc config storage import --file rclone.conf

これにより、rclone設定ファイルからストレージ構成が現在の設定にインポートされます。サポートされているタイプ：S3、B2、Google Drive、OneDrive、Mega、Dropbox、Box、Azure Blob、Swift。

ストレージの表示

rdc config storage list

バックアップの送信

リポジトリのバックアップを外部ストレージに送信します：

rdc repo push --name my-app -m server-1 --to my-storage

プッシュは書き込み前に常にターゲットリポジトリがマウントされているか確認します。マウントされていない場合、操作は中止されます。

オプション	説明
--to <storage>	ターゲットストレージの場所
--to-machine <machine>	マシン間バックアップのターゲットマシン
--dest <filename>	カスタム宛先ファイル名
--checkpoint	プッシュ前にCRIUチェックポイントを作成（rediacc.checkpoint=trueラベル付きコンテナ用）。ターゲットはrepo up時に自動復元
--force	既存のバックアップを上書き
--bwlimit <limit>	rsync転送の帯域幅制限（例：10M、500K）
--tag <tag>	バックアップにタグを付ける
-w, --watch	操作の進捗を監視
--debug	詳細出力を有効化
--skip-router-restart	操作後のルートサーバー再起動をスキップ

バックアップの取得 / 復元

外部ストレージからリポジトリのバックアップを取得します：

rdc repo pull --name my-app -m server-1 --from my-storage

プルは書き込み前に常にターゲットリポジトリがマウントされているか確認します。マウントされていない場合、操作は中止されます。

オプション	説明
--from <storage>	ソースストレージの場所
--from-machine <machine>	マシン間復元のソースマシン
--force	既存のローカルバックアップを上書き
--bwlimit <limit>	rsync転送の帯域幅制限（例：10M、500K）
-w, --watch	操作の進捗を監視
--debug	詳細出力を有効化
--skip-router-restart	操作後のルートサーバー再起動をスキップ

バックアップの一覧表示

ストレージの場所にある利用可能なバックアップを表示します：

rdc repo backup list --from my-storage -m server-1

出力は スケジュールバックアップ のフォルダ（hot/ と cold/）の両方をマージした統一テーブルで、すべてのバックアップを 1 つのビューで確認できます。

カラム	意味
Mode	hot または cold. このエントリが属するスケジュールバックアップフォルダ
Name	ローカル設定から解決されたリポジトリ名（設定にないリポジトリの場合は GUID にフォールバック）
GUID	ディスク上のリポジトリ GUID
Size	バックアップファイルの人間可読のサイズ
Modified	ストレージバックエンドからの UTC タイムスタンプ

特定のモードに絞り込むには --path を渡します。

rdc repo backup list --from my-storage -m server-1 --path hot
rdc repo backup list --from my-storage -m server-1 --path cold

ストレージレイアウト

スケジュールバックアップは、ストレージで設定されたフォルダ内のモード別サブフォルダに書き込まれるため、同じストレージで毎時ストリームと毎週ストリームを混在させずにきれいにホストできます。

<bucket>/<folder>/
├── hot/
│   ├── <guid-1>
│   ├── <guid-2>
│   └── ...
└── cold/
    ├── <guid-1>
    ├── <guid-3>
    └── ...

リポジトリは hot/ と cold/ の両方に出現する可能性があります（毎時スケジュールがスナップショットを取り、毎週スケジュールが再度スナップショットを取る）。マージされた一覧では両方の行が表示されるため、どのストリームがどのリポジトリをカバーしているかが明確になります。

一括同期

すべてのリポジトリを一度に送信または取得します：

すべてをストレージに送信

rdc repo push --to my-storage -m server-1

すべてをストレージから取得

rdc repo pull --from my-storage -m server-1

オプション	説明
--to <storage>	ターゲットストレージ（送信方向）
--from <storage>	ソースストレージ（取得方向）
--repo <name>	特定のリポジトリを同期（繰り返し指定可能）
--override	既存のバックアップを上書き
--debug	詳細出力を有効化
--skip-router-restart	操作後のルートサーバー再起動をスキップ

スケジュールバックアップ

Rediaccは名前付きバックアップ戦略を使用します。各戦略はスケジュール、バックアップモード、オプションの帯域幅制限、ファイルフィルターを定義します。マシンは名前で戦略を参照し、実行するバックアップを決定します。

バックアップモード

モード	動作	ダウンタイム
hot	サービス稼働中にBTRFSスナップショットを取得（クラッシュ整合性）	なし
cold	サービス停止、スナップショット取得、サービス再起動、スナップショットアップロード（アプリケーション整合性）	リポジトリごとの停止+起動ウィンドウ、リポジトリ間で並列化。下記「コールドバックアップのダウンタイム見積もり」を参照。

クラッシュ整合性スナップショットが許容されるサービスにはhotを使用します。保証された整合性が必要で短い再起動を受け入れられる場合はcoldを使用します。

コールドバックアップのセマンティクス

コールドバックアップは、対象リポジトリごとに3つのフェーズで実行されます：停止 — スナップショット — 起動。保証の限界を理解することで、オペレーターが部分的な障害を早期に検出できます。

コールドバックアップが保証すること：

• スナップショット前に、各対象リポジトリで実行中のすべてのコンテナがRediaccfileのdown()フックを通じて正常に停止され、リポジトリごとのDockerデーモンが静止されます。スナップショットはクラッシュ整合性だけでなく、アプリケーション整合性を持ちます。
• スナップショット前に実行されていたコンテナIDのセットが/var/run/rediacc/cold-backup-<guid>.running.jsonのサイドカーファイルに保持されます。これが「完了時に再び起動すべきもの」の真実の情報源です。
• スナップショット後、リポジトリのRediaccfileのup()フックが呼び出され、完全なcomposeスタックが復元されます。
• 実行ごとのステータスサイドカーファイル/var/run/rediacc/cold-backup-<guid>.status.jsonに、各試行のフェーズ、結果、エラーが記録されます。

コールドバックアップが保証しないこと：

• up()はベストエフォートです。コールドバックアップの制御外の理由で失敗する可能性があります（depends_on: service_healthy条件の待機中、composeファイルの構文エラー、イメージプル中の一時的なネットワーク障害など）。失敗した場合、コールドバックアップはエラーレベルでログを記録し、ステータスサイドカーを書き込み、次のリポジトリに進みます。
• up()が失敗した場合、直接フォールバック再起動が実行されます：実行サイドカーが読み込まれ、記録された各コンテナIDがDocker APIを通じて直接再起動されます（composeなし）。composeフローに問題があっても、Rediaccfileフックを再実行せずにサービスを復帰させます。
• 一部のコンテナID（Dockerデーモン自体がダウンしているなど）のフォールバックが失敗した場合、サイドカーはそのまま残され、ルーターwatchdogが各ティックで再試行できるようにします。

Watchdog回復： 各ティックで、watchdogは実行サイドカーの存在を確認します。そこにリストされているコンテナIDのうち、現在停止しているものは、コンテナの保存されたrestart_policyに関わらず再起動されます。これにより、restart: on-failure（クリーンな停止後にDockerが再起動しない）のサービスも、コールドバックアップ後に復帰します。リストされたすべてのコンテナが実行中になると、サイドカーは削除されます。

オペレーターが障害を検出する方法：

• rdc machine query --name <machine> --containersで実行状態を確認します。期待されるセットと比較してください。
• マシン上の/var/run/rediacc/cold-backup-<guid>.status.jsonを確認します。rdc term connect -m <machine> -r <repo> -c "cat /var/run/rediacc/cold-backup-$GUID.status.json"で検査できます。success: falseと古いstartedAtは、最後のバックアップが正常に完了しなかったことを示します。
• renetバックアップ実行のログ（journalctl -u renet-*または直接のrdc machine deploy-backup呼び出し）は、Cold backup: post-snapshot restart summary total=N compose_ok=N fallback_ok=N failed=N failed_repos=[...]の形式の最終サマリー行を出力します。空でないfailed_reposがgrepのターゲットです。

コールドバックアップのダウンタイム見積もり

各リポジトリは、自身のdown() + up()ウィンドウの間だけダウンします。ウォーム状態のホストでは通常：

リポジトリの種類	典型的な停止+起動
小規模（コンテナ1-2個、DBなし）	5-15 秒
中規模（Webアプリ + キャッシュ）	20-45 秒
大規模（DB + キュー + メール）	60-120 秒

スナップショット手順（btrfs subvolume snapshot -r）はリポジトリサイズに関わらずO(1)で、0.1-1秒です。他のリポジトリのスナップショット中にあるリポジトリが停止したままになることはありません。アップロードは読み取り専用スナップショットに対して実行され、その間すべてのリポジトリはすでに復帰しています。

実行全体の所要時間（ウォールクロック） は、同時に再起動するリポジトリ数によって決まります。renetはホストからこの値を導出します：

concurrency = min(repoCount, max(2, NumCPU/2), 8)

例：

ホスト	リポジトリ	同時実行数	ウォールクロックの再起動
4 CPUのVM	5リポジトリ、各平均30秒	2	~75 秒
16 CPUのサーバ	10リポジトリ、各平均40秒	8	~80 秒
64 CPUのフリートノード	50リポジトリ、各平均40秒	8	~4 分

環境変数によるオーバーライド： バックアップサービスの環境でREDIACC_COLD_BACKUP_CONCURRENCY=Nを設定（通常はsystemdドロップインを使用）すると、値を固定できます。=1は厳密な直列再起動を強制し、あるリポジトリのup()フックでのクラッシュループをデバッグする際に役立ちます。

レイテンシに敏感なリポジトリ（公開Webアプリ、メール）を運用している場合、そのダウンタイムは自身の停止+起動（通常30-90秒）で制限され、実行全体の長さではありません。リポジトリは発見された順序で同時実行スロットに割り当てられ、優先キューはありません。細かいスケジューリングが必要な場合は、重いリポジトリを--excludeで限定した別の戦略に分けてください。

長時間実行されるバックアップとスケジュールの重複

自身のスケジュール間隔より長くかかるコールドバックアップ（例：500 GBリポジトリの初回シードは適度な回線で24時間以上かかることが正当にあり得、その間に夜間タイマーが再度発火する）は、2回目の実行をキューに入れたり起動したりしません。systemdのType=oneshotユニットは単一インスタンスです：タイマーが発火し、サービスがすでにactivatingの場合、systemdは起動を既存のジョブに統合します。新しいプロセスは起動されず、実行は後でのためにキューに入れられません。

具体的に、月曜日の03:00 UTCに開始し、木曜日の正午に終了する実行：

曜日	03:00 UTCの発火	結果
月曜日	最初の発火	実行開始
火曜日	2回目の発火	静かに破棄（前の実行がまだアクティブ）
水曜日	3回目の発火	静かに破棄（前の実行がまだアクティブ）
木曜日	実行が正午に終了	キャッチアップなし；次の実行は金曜日の03:00 UTC

タイマーのPersistent=trueディレクティブはこれらの発火を救いません。Persistent=trueは、タイマー自体が非アクティブだった（システムオフ、タイマー無効）ために見逃された発火を再生します。サービスがビジーだったために破棄された発火は失われます。

このデフォルトは意図的です。同じデータストアに対して2つのコールドバックアップを並行実行すると、BTRFSスナップショットパス、rcloneリモート、および/var/run/rediacc/cold-backup-<guid>.status.jsonのリポジトリごとのサイドカーで競合します。長時間実行インスタンスの後ろにシリアル化することが安全な結果です。

モニタリングへの影響。 ハングしたバックアップ（例：rcloneがネットワークブラックホールで詰まる）は、その後のすべてのタイマー発火を静かに破棄します。スケジューラはアラームを発しません。systemctl show <unit> -p ActiveEnterTimestampを監視してください：サービスが予想実行時間より長くactivatingになっている場合（例：夜間タイマーで48時間以上）、調査してください。

各スケジュール発火を実行する必要がある場合、タイマーをOnCalendar=<cron>からOnUnitInactiveSec=<間隔>に切り替えます。これは、固定のウォールクロックスケジュールではなく、前の実行の完了後N時間後に発火するため、長時間実行は破棄を引き起こしません。次の実行を後ろに押すだけです。トレードオフはスケジュールドリフトです：03:00の夜間は「最後の終了から24時間後」になります。

戦略の定義

標準的なデフォルトは 2 つの戦略の組み合わせです。すべてのリポジトリをキャプチャする高速な毎時ホットストリームと、アプリケーション整合性のあるスナップショットを取る低速な毎週コールドストリームです。2 つの戦略は異なるストレージサブフォルダ（hot/ と cold/）に書き込むため、バックアップが混ざることはありません。

rdc config backup-strategy set \
  --name hourly-hot \
  --destination my-storage \
  --cron "0 * * * *" \
  --mode hot \
  --bwlimit 20M \
  --enable

rdc config backup-strategy set \
  --name weekly-cold \
  --destination my-storage \
  --cron "15 3 * * 0" \
  --mode cold \
  --exclude very-large-repo \
  --enable

コールド戦略の --exclude フィルターは、毎週のメンテナンスウィンドウに収まらない非常に大きなリポジトリのための推奨されるエスケープハッチです。毎時のホット戦略は引き続きそれらをカバーし、コールドはスキップするだけです。--exclude のリポジトリ名はローカル設定のリポジトリ名と一致します（:tag なし）。

オプション	説明
--name <name>	戦略名（マシンバインディングに使用）
--destination <storage>	アップロード先のストレージプロバイダ
--cron <expression>	cron式（例："0 2 * * *" で毎日午前2時）
--mode <hot|cold>	バックアップモード
--bwlimit <limit>	アップロードの帯域幅制限（例：10M）
--include <pattern>	包含フィルター（繰り返し指定可能）
--exclude <pattern>	除外フィルター（繰り返し指定可能）
--enable / --disable	戦略を有効化または無効化

戦略の表示

rdc config backup-strategy list
rdc config backup-strategy show --name weekly-cold

戦略の削除

rdc config backup-strategy remove --name weekly-cold

マシンへの戦略のバインド

設定内で、1つ以上の戦略名をマシンにバインドします：

{
  "machines": {
    "hostinger": {
      "backupStrategies": ["hourly-hot", "weekly-cold"]
    }
  }
}

バックアップ操作

マシンへのスケジュールのデプロイ

バインドされた戦略をsystemdタイマーとしてマシンにプッシュします：

rdc machine backup schedule -m server-1
rdc machine backup schedule -m server-1 --dry-run

デプロイは状態レコンサイラーです。マシン上の現在のユニットファイルと systemd の状態を読み取り、設定が生成するであろう内容と比較し（ファイルごとに SHA-256）、内容が実際に変更されたユニットのみに触れます。設定変更なしで再実行しても no-op です。書き込みなし、daemon-reload なし、タイマーの変動なし。

--dry-run はマシンに触れずに、各戦略のプランを表示します（created、updated (service, timer, env)、unchanged、removed）。--debug と組み合わせると、生成されたユニット本体も表示されます。rclone トークンは編集されます。

更新または削除しようとしている戦略のバックアップが現在実行中の場合、デプロイは直ちに失敗し、キャンセルするか --force を渡すヒントが表示されます。--force を使うと、実行中の呼び出しはメモリ内のユニットを保持し、新しい設定は次のタイマーティックで適用されるため、実行中のバックアップは決して強制終了されません。

--reset-failed はオプトインです。渡された場合、デプロイ成功後に変更されたサービスの systemd の failed 状態をクリアします。既定では無効で、以前の障害シグナルがアラートに表示されたままになります。

今すぐバックアップを実行

タイマーを待たずに即座にバックアップを開始します。タイマーがデプロイされていなくても、systemd-runによるアドホック実行が可能です：

rdc machine backup now -m server-1
rdc machine backup now -m server-1 --strategy weekly-cold

バックアップ状態の表示

バックアップタイマーの現在の状態と最近のジョブ結果を表示します：

rdc machine backup status -m server-1
rdc machine backup status -m server-1 --strategy hourly-hot

実行中のバックアップのキャンセル

rdc machine backup cancel -m server-1
rdc machine backup cancel -m server-1 --strategy weekly-cold

リポジトリの移行

リポジトリをあるマシンから別のマシンに移動します：

rdc repo migrate --name my-app --from server-1 --to server-2

オプション	説明
--name <repo>	移行するリポジトリ
--from <machine>	ソースマシン
--to <machine>	宛先マシン
--provision	転送前に宛先でリポジトリをプロビジョニング
--checkpoint	移行前にCRIUチェックポイントを作成
--skip-dns	移行後のDNSレコード更新をスキップ
--bwlimit <limit>	転送の帯域幅制限（例：50M）

移行はrsyncを介して暗号化されたリポジトリデータを転送します。ソースリポジトリは明示的に削除するまで保持されます。

ストレージの参照

ストレージの場所の内容を参照します：

rdc storage browse --name my-storage

ベストプラクティス

• 重要なデータのアプリケーション整合性スナップショットのために毎日のコールドバックアップをスケジュールする
• ゼロダウンタイムが必要な高頻度スナップショットにはホットバックアップを使用する
• バックアップの整合性を確認するため、定期的に復元テストを実施する
• 重要なデータには複数のストレージプロバイダを使用する（例：S3 + B2）
• 認証情報を安全に保管する；バックアップは暗号化されているが、復元にはLUKS認証情報が必要