restic

Restic

Restic はバックアップ用 CLI であり、デーモンではありません。スケジュールされたジョブまたはサービスマネージャーを実行レイヤーとして扱ってください。実用的なバックアップ設計では、ソースが取得されたこと、リポジトリを読み取れること、保持方針が意図的に定められていること、別のターゲットへの復元が機能することの 4 点を必ず確認します。

運用上の契約

1. 変更を加える前に、restic のバージョン、バックエンドの種類、リポジトリ形式、ソースパス、認証情報の仕組み、スケジュール、保持ポリシー、復旧目標を確認します。
2. リポジトリのパスワードとバックエンドの認証情報は、コマンド履歴、ログ、テンプレート、チャットに含めないでください。値をコマンドに直接記述するより、root／ユーザーのみが読み取り可能なパスワードファイルまたはシークレットマネージャーのコマンドを優先してください。
3. 変更を加える前に、対象のリポジトリ、ソースの範囲、除外対象、保持グループ、スケジュール、メンテナンス時間枠、ロールバック／復旧手順を確認します。読み取り専用の調査は、確認なしで進めてもかまいません。
4. 一貫性のあるホスト名とタグの規則に従ってバックアップします。生成されたスナップショットを確認してから、空の独立したターゲットへの復元をテストします。バックアップの終了コードが成功しても、それだけでは復旧可能である証拠になりません。
5. forget、prune、key remove、rebuild-index、repair、migrate、バックエンドのライフサイクルルールは、重大な影響を伴う操作として扱ってください。可能な場合は事前確認を行い、正常な復旧手段を確保してください。

まず読み取り専用で調査する

scripts/restic-preflight.sh
restic version
restic snapshots --json
restic stats --mode raw-data

リポジトリを開くコマンドを実行する前に、環境変数またはコマンドフラグでリポジトリの場所とパスワードの取得元を設定してください。共有シェルの履歴に平文のパスワードをエクスポートしないでください。リポジトリとバックエンドの設定を参照してください。

使用しない場合

一度限りの暗号化されていないファイルコピー、restic では作成できない形式のデータベースバックアップ、restic リポジトリを伴わないプロバイダー固有のオブジェクトストレージ管理には、これを使用しないでください。一貫性を確保するには、該当するアプリケーションのバックアップ手順を使用し、その後、このスキルを使って生成された成果物を保護してください。

手順を選ぶ

必要な作業	まず読む項目
サポート対象のバイナリをインストールまたは選択する	基礎とインストール
リポジトリを初期化する、または local、SFTP、オブジェクトストレージ、REST、rclone のバックエンドを選択する	リポジトリとバックエンド
ソース、除外対象、タグ、スケジュール、サービスマネージャーによる自動化を設計する	バックアップの設計と自動化
無人実行ジョブを作成する、終了コードを処理する、JSON を解析する、またはロックについて検討する	スクリプト作成とコマンドの仕様
保持方針を定義する、メンテナンスを実行する、整合性を検証する、または復元訓練を実施する	保持、整合性、復旧
シークレット、アクセス、ランサムウェア、認証情報の脅威モデルを作成する	セキュリティと脅威モデル
実行時間を短縮する、帯域幅／キャッシュを制御する、または有用な証拠を収集する	パフォーマンスと可観測性
障害、ロック、破損、バックエンドエラー、コピー／移行作業を診断する	トラブルシューティングと移行
ソースの範囲、バージョンの最新性、またはバックエンドに関する説明を確認する	ソースインデックス

安全なワークフロー

生成データ： データベースのエクスポートをバックアップジョブに埋め込む前に、 スクリプトとコマンドの契約をお読みください。 --stdin-from-command は -- の後に指定されたプロデューサーコマンドを厳密に 1 つ実行します。外側のシェルパイプはそのプロデューサーには含まれません。圧縮や変換を行う場合は、テスト済みのラッパープログラムをプロデューサーとして渡すか、pipefail と明示的なエラー処理を設定した場合に限り backup --stdin を使用してください。

# 1. Read-only preflight. It never prints secret values.
scripts/restic-preflight.sh

# 2. Initialize only after confirming the intended empty target.
restic init --repo /path/to/repository --password-file /secure/path/restic-password

# 3. Create a tagged snapshot, then inspect it.
restic --repo /path/to/repository --password-file /secure/path/restic-password \
  backup /data --tag production --tag files
restic --repo /path/to/repository --password-file /secure/path/restic-password snapshots

# 4. Restore to an empty, separate directory and inspect the result.
restic --repo /path/to/repository --password-file /secure/path/restic-password \
  restore latest --target /var/tmp/restic-restore-test

非シークレットのポリシーを記録するには templates/backup-policy.env.example を使用し、証拠に基づく復旧テストを記録するには templates/restore-drill.md を使用してください。Linux のスケジュール設定では、templates/systemd/restic-backup.service と templates/systemd/restic-backup.timer を調整してください。シークレットのパスとソースパスはローカルに保持し、コミットしないでください。

スクリプト

• scripts/restic-preflight.sh — 読み取り専用のローカル設定と CLI のチェックです。値をマスキングし、リポジトリを開くことはありません。
• scripts/restic-verify.sh — 範囲を限定したリポジトリ検証です。デフォルトではメタデータをチェックし、オプションでサンプルまたは全データを読み取ります。保持設定を変更したり、データをプルーニングしたりすることはありません。
• scripts/test-restic-preflight.sh — 偽の restic 実行ファイルを使った、決定論的なシェルテストです。
• scripts/test-restic-verify.sh — 範囲を限定した check コマンドの構築を検証する、決定論的なシェルテストです。

スクリプトはスキルのルートから実行してください。Bash と restic が必要です。また、restic-verify.sh には、あらかじめ設定されたリポジトリとパスワードの仕組みも必要です。

厳守する境界

• 所要時間とロックへの影響を把握していない限り、唯一のバックアップジョブと同じ無人実行時間帯に prune を実行しないでください。
• forget をストレージの回収と同一視しないでください。forget はスナップショットへの参照を削除し、参照されなくなったデータは後から prune によって削除されます。
• 復旧の最初の手順として、本番のソースパスに上書き復元しないでください。別の場所に復元して検証し、その後、意図的に切り替えてください。
• バックアップがブロックされたという理由だけで unlock を使用しないでください。まず、別の restic プロセスが実行中かどうか、またロックが古いものかどうかを確認してください。
• 汎用の S3 URL から、プロバイダーの不変性、保持設定、権限、オブジェクトロックの仕様を推測しないでください。該当するバックエンドのポリシーを確認し、訓練で復元してください。

完了基準

要求された操作は、関連する境界が証拠で確認できた場合にのみ完了です。インストールでは想定したバイナリが報告されていること、バックアップでは一覧にスナップショットが表示されていること、メンテナンスでは操作後に check が実行されていること、復旧では別の保存先に復元し、復元データを検査していることが必要です。