ドキュメントを見る

バックアップと復元

有用な ThreadCells バックアップは、永続的な協調状態と、それを解釈するために必要な設定を保存します。インストール済みコードとビルドキャッシュは通常再構築できますが、データベース、オペレーター所有の設定、プロバイダー固有の証拠はそうではない場合があります。

重要なもの

該当する場合、次をバックアップします。

  • ThreadCells SQLite データベースと関連する SQLite ファイル。
  • 平文のシークレットを臨時アーカイブから除外した設定とサービス環境。
  • 別途保護する、シークレットに隣接する成果物としてのオペレーター検証ファイル。
  • 設定している場合、所有権とモードを保持した別途暗号化済み認証情報としての Telegram ボットトークンファイル。
  • 保持ポリシーで必要となるエージェントコンテキスト、添付物、ログ。
  • アクティブな作業を解釈するのに必要な管理対象 worktree とリリースのメタデータ。
  • 正確なアクティブ候補およびロールバック候補のマニフェスト/ID。
  • 外部プロバイダーの状態は、そのプロバイダー自身がサポートするバックアップポリシーに従う場合のみ。

Git リポジトリには、すでに独自のバックアップ/リモート戦略があるべきです。ThreadCells データベースのバックアップは、コミットを保存する代替にはなりません。

再構築できるもの

ダウンロード済み Web 依存関係、ブラウザーリビジョン、パッケージキャッシュ、一時ビルドディレクトリ、検証済み候補の内容は、通常ソースと lockfile から再作成できます。ランタイムパスの下にあるというだけで、すべてのキャッシュをバックアップに追加しないでください。

一貫したバックアップ手順

  1. アクティブなソース/候補 ID と現在のサービス状態を記録する。
  2. スナップショット期間中は、新しいセッションや変更操作を開始しないようにする。
  3. 稼働中の SQLite ファイルを盲目的にコピーするのではなく、正規のデータベースバックアップ機構を使う。
  4. バックアップに対して SQLite の整合性検証を実行する。
  5. 必要な設定、検証ファイル、設定済み Telegram トークン成果物を、権限を保持し内容を出力せずにコピーする。
  6. チェックサムを記録し、アーカイブを稼働中の状態ルートの外部に保管する。
  7. 意図した復旧主体がバックアップを一覧表示し読み取れることをテストする。

デプロイメントツールにバックアップコマンドがあるなら使用してください。実際のデータベースパスとサービス協調を理解しています。アーカイブ作成のために、平文のプロバイダーまたはオペレーターのシークレットをシェル履歴に残してはいけません。

検証

最低限、コピーした SQLite データベースを検証します。

bash
sqlite3 /path/to/backup.db 'PRAGMA integrity_check;'

期待する結果は ok です。また、チェックサムを記録し、アーカイブに必要な設定、検証ファイル、ビルド ID が含まれることを、ログで内容を露出させずに確認します。

テストしていないバックアップは仮説にすぎません。定期的に、隔離したパスとローカル専用ポートへの復元をリハーサルしてください。

復元の順序

  1. 対象の ThreadCells サービスを停止または隔離する。
  2. 現在の失敗状態をフォレンジック用ロールバックのために保持する。
  3. 正確に互換する候補をインストールまたは選択する。
  4. ランタイムアカウントが期待する所有権で、データベースと変更可能な状態を復元する。
  5. サービス設定を復元する。
  6. オペレーター検証ファイルを、独立した信頼済み所有者、サービスが読み取れるモード、信頼できる親ディレクトリチェーンで復元する。該当する Telegram トークンは、モード 0600 のランタイム所有の通常ファイルとして $CAO_HOME_DIR/secrets/telegram-bot-token に復元する。
  7. 起動前に整合性チェックを実行する。
  8. ループバックで起動し、ヘルス/ビルド ID を検証する。
  9. 作業を再試行する前に、アクティブなワークフロー、結果、端末、プロジェクト、プロバイダー事前検査、Statistics を確認する。

不一致のコードまたは古いサービス環境を残したまま、データベースだけを復元してはいけません。tmux/プロバイダープロセスが一貫して生き残ったと仮定せず、各ライブプロセスを永続セッション状態と照合してください。

復旧後の検証

復元後に、次を確認します。

  • Settings → About が意図した候補と一致する。
  • /health が成功する。
  • プロジェクトとセッション履歴が存在する。
  • 配信済みの結果が引き続き帰属可能である。
  • プロバイダーの可用性が、復元されたランタイムユーザーの実際のインストール状況を反映する。
  • オペレーター認可が設定済みと表示され、既存のシークレットでロック解除できる。
  • Telegram が想定した安全な設定状態を報告し、復元した場合は有効化前に明示的な接続およびテストメッセージのチェックに合格する。
  • Statistics の合計が重複なくリプレイされる。
  • アクティブ/ロールバックリリースが引き続き正しく識別される。

バックアップは自動 Housekeeping から保護されます。バックアップストレージには、別途レビュー済みの保持ポリシーを適用してください。

Full Cleanup はバックアップ保持の代わりにはなりません。正規データベースと、不要であると証明できないすべてのバックアップを保護しますが、信頼済みリリースメタデータに記録された非アクティブなローカルリリースとロールバックはすべて意図的に削除します。認可する前に、必要な復旧ポイントがローカルリリースセットの外部に存在し、整合性確認済みであることを確認してください。その後は、別の検証済みリリースがステージングされるまで、ローカルロールバックを利用できないと想定する必要があります。

Subaev Ruslan が作成・保守し、ThreadCells コミュニティが貢献しています。 リポジトリを見る