ストレージ移行ランブック

​

前提条件

• 両方のプロバイダーについて、ストレージサポートポリシーとリリースノートを読む。
• リリースがプロバイダー中立の永続削除アウトボックスを使用することを確認する。履歴の MinIO専用削除ギャップは修正済みです。その古い 制限を新しい設計に持ち込まないでください。
• 宛先の容量、暗号化、バージョニング、保持、ライフサイクル、 オブジェクトサイズ、メタデータ、および命名動作を確認する。
• 最小権限のソース読み取りおよび宛先書き込み移行アイデンティティを作成する。
• TLS信頼を設定する。--no-check-certificate を使用してはならない。
• PostgreSQLとソースストレージの一貫性バックアップを取得してテストする。
• オブジェクト数、合計バイト、ソースバージョン/スナップショット、および設定を記録する。
• 書き込み静止とロールバックを許可する変更ウィンドウを設定する。

pnpm storage:backup-verify inventory \
  --output '<protected-manifest.json>'
chmod 600 '<protected-manifest.json>'

​

1. インベントリとドライラン

rclone version
rclone size source:casebender --json > source-size.before.json
rclone lsf source:casebender --recursive --files-only \
  > source-objects.before.txt
rclone copy source:casebender destination:casebender \
  --checksum --metadata --dry-run --log-level INFO \
  --log-file migration-dry-run.log

​

2. アプリケーション稼働中のシードコピー

rclone copy source:casebender destination:casebender \
  --checksum --metadata --fast-list --transfers 8 --checkers 16 \
  --log-level INFO --log-file migration-seed.log

​

3. 書き込みを静止し、一貫性ポイントを取得する

rclone copy source:casebender destination:casebender \
  --checksum --metadata --fast-list --transfers 8 --checkers 16 \
  --log-level INFO --log-file migration-final.log

​

4. カットオーバー前の検証

rclone check source:casebender destination:casebender \
  --download --one-way --combined migration-check.txt
rclone size source:casebender --json > source-size.final.json
rclone size destination:casebender --json > destination-size.final.json

STORAGE_TEST_PROVIDER=s3 \
STORAGE_TEST_ENDPOINT=https://storage.example.com \
STORAGE_TEST_BUCKET=casebender \
AWS_REGION=us-east-1 \
./scripts/storage/validate-storage.sh

​

5. カットオーバー

1. 暗号化された変更記録に、古いプロバイダー設定とSecretリソースバージョンを 保存する。
2. StorageMigrationLedger エントリが VERIFIED であることを確認する。移行 プロセッサーは先にコピーし、読み戻し、SHA-256を検証し、宛先 プロバイダーバージョンを記録してから、CUTOVER に遷移します。
3. 明示的なプロバイダープロファイルと資格情報のみを変更する。バケット 内容と永続キーを保全する。
4. Webアプリケーションを再起動し、/api/health/ready を待つ。
5. アプリケーションのアップロード/ダウンロード/list/コピー/削除テストを実行し、SHA-256を検証する。
6. 複数の経過時間とサイズにわたる既存の添付と証拠を検証する。
7. ワーカーと取り込みを再開し、その後ユーザー書き込みを再開する。
8. ロールバックウィンドウ中、ストレージエラー、失敗した削除、レイテンシ、スロットリング、キュー深度、および 監査イベントを継続的に監視する。

​

6. ロールバック

1. メンテナンスモードに再入り、書き込みを静止する。
2. カットオーバー以降に宛先に書き込まれたすべてのオブジェクトを記録する。
3. 削除なしで、逆差分をソースにコピーする。

rclone copy destination:casebender source:casebender \
  --checksum --metadata --fast-list \
  --log-level INFO --log-file rollback-copy.log
rclone check destination:casebender source:casebender \
  --download --one-way --combined rollback-check.txt

4. クリーンなチェックを要求してから、以前のプロバイダー設定と 資格情報バージョンを復元する。
5. 再起動し、アプリケーションのライフサイクル/整合性テストを実行して、トラフィックを再開する。
6. インシデント/変更レビューが完了するまで、両方のストアとすべてのエビデンスを保持する。

​

7. クローズアウト

• 最終件数/バイトを調整し、ハッシュ、ログ、ツールバージョン、承認、 設定バージョン、およびサンプリングしたアプリケーション結果をアーカイブする。
• 一時的な移行資格情報をローテーションする。
• 承認済みロールバック期間中、ソースを読み取り専用で保持する。
• 正式なサインオフと法務/保持レビューの後、 プロバイダーの監査済み廃棄プロセスを使用してソースデータを削除する。
• プロバイダー製品/バージョン、TLS/CA詳細、 契約結果、性能結果、バックアップ結果、およびロールバック演習でサポート記録を更新する。

pnpm storage:backup-verify verify-restore \
  --manifest '<protected-manifest.json>' \
  --target-profile '<isolated-restore-profile>' \
  --isolated-prefix 'tenants/<test-tenant>/restore-verification/<exercise-id>' \
  --evidence-output '<sanitized-restore-evidence.json>'

​

プロバイダー固有の注意点

• S3/Ceph RGW: バージョンIDと削除マーカーを保全する。通常のコピーでは Object Lock/リーガルホールド状態が保持されない場合があります。正確な製品バージョンと プライベートCAを再適格性確認します。
• GCS: 数値世代を保全する。バケット保持、オブジェクト保持、 イベントベースホールド、およびCMEKポリシーは、別途宛先での証明が必要です。
• Azure: BlobバージョンIDを保全する。不変性とリーガルホールドは 宛先固有であり、コピーされたBlobは新しいバージョンIDを受け取ります。
• レガシーMinIO: 元のボリュームスナップショットとS3 APIエクスポートの両方を保持する。 MinIOの内部ファイルシステムレイアウトを別のプロバイダーにインポートしてはなりません。