バックアップと災害復旧

ObjectOS 自体はステートレスであり、ランタイムはコンテナイメージから 再構築できます。バックアップの対象は ObjectOS が依存するデータであり、 ObjectOS 自体ではありません。 復旧計画はそれらのデータセットを中心に 立てましょう。

何をバックアップするか

ObjectOS はコンテナファイルシステムの個別バックアップを必要としません。 キャッシュディレクトリ（OS_CACHE_DIR）は再構築可能です。

データベースのバックアップ

戦略はドライバーに合わせます。

どのドライバーであっても、次の点を検証してください。

• バックアップが顧客の RPO 内に完了すること。
• 新しいデータベースが同じ成果物から ObjectOS を起動し、 トラフィックを処理できること。
• 復元テストが少なくとも四半期に一度はエンドツーエンドで実施されること。

SQLite デプロイ

SQLite はデフォルトのドライバーであり、単一ノードの ObjectOS にとって 正当な本番選択肢です — デスクトップアプリ、小規模チーム向けの社内ツール、 エッジ / オンプレミスのアプライアンス、評価環境などです。トレードオフは 構造的なもので、SQLite は単一ライターであるため、マルチノードの ObjectOS、 高い同時書き込みスループット、共有データベースのデプロイには適しません。 そうしたケースでは PostgreSQL を使用してください。

本番で SQLite を実行する場合、安全性を確保する構成とバックアップの レシピは一体です。

ランタイム構成

• WAL を有効にする: PRAGMA journal_mode=WAL（リーダーがライターを ブロックせず、クラッシュセーフ）。
• PRAGMA synchronous=NORMAL は通常のデスクトップ/単一ノードの デフォルトです — WAL と組み合わせれば安全で、FULL よりはるかに高速です。
• データベースファイルはローカルディスクに置いてください。ランタイムの 実行中に、NFS、SMB、または Dropbox / OneDrive / iCloud で同期される フォルダの内部には置かないでください — SQLite のロックはそれらでは 信頼できず、これが SQLite デプロイで最もよく見られる破損の原因です。

ホットスナップショット（ダウンタイムなし）

ランタイムはトラフィックを処理し続けながら、SQLite の Online Backup API または VACUUM INTO を使ってスナップショットを取得します。

VACUUM INTO '/var/backups/objectos/db-2026-05-27T13-00Z.sqlite';

RPO に合わせた頻度でスケジュールします（cron、systemd タイマー、または プロセス内スケジューラ）。各スナップショットには、それを生成した成果物 バージョンのタグを付け、データベースと成果物をまとめてロールバックできる ようにします（後述の 成果物のバージョニング を参照）。

オフサイトコピー

ローカルスナップショットはディスク喪失に耐えられません。各スナップショットを 耐久性のあるストレージにプッシュしてください。

• サーバー / VM: S3 または任意の S3 互換バケットにプッシュ（おそらく storage 機能用にすでに 1 つ構成済みでしょう）。
• デスクトップアプリ: スナップショットをユーザーが管理する同期フォルダ （OneDrive / iCloud / Google Drive）に書き込みます — スナップショット ファイルはクローズされたイミュータブルなもので、稼働中のデータベースとは 異なるため、ここでは許容されます。

継続的レプリケーション（より低い RPO）

SQLite を手放さずにサブ分の RPO を実現するには、ObjectOS プロセスと並行して Litestream を実行します。WAL を S3 互換ストレージに ストリーミングし、ポイントインタイムリストアをサポートします。単一ノードの SQLite デプロイでほぼゼロのデータ損失が必要な場合の推奨パスです。

復元

ランタイムを停止し、データベースファイルを選択したスナップショットで 置き換え（または litestream restore を実行）、そのスナップショットを 生成したのと同じ成果物バージョンに対してランタイムを起動します。

成果物のバージョニング

公開した成果物はイミュータブルとして扱います。各成果物には、それを コンパイルするために使用したリリース ID のタグを付けます （例: objectstack-2026-05-24.json）。既知の正常な業務状態への復旧は、 通常次のことを意味します。

1. データベースを選択した時点まで復元する。
2. その時点で稼働していた成果物バージョンに ObjectOS を再び向ける。
3. ランタイムを再起動する。

成果物をその場で上書きすると、データベースのバックアップが完璧であっても、 きれいにロールバックする能力を失います。

RPO/RTO の計画

顧客デプロイで実現可能な出発点としての目標値:

より厳しい目標値には、ObjectOS コンテナ自体の外側にあるプラットフォーム 変更（HA データベース、マルチ AZ イングレス、ウォームレプリカ）が必要です。

リハーサルする価値のある障害モード

• データベースが長時間利用不能。 ランタイムが明確な 503 を返し、 プローブが Pod を正しく不健全とマークすることを確認します。
• 成果物のリグレッション。 成果物ポインタをロールバックします。 データは影響を受けません。
• シークレットのローテーション。 AUTH_SECRET をローテーションすると、 すべてのセッションが無効になります。メンテナンスウィンドウ中に実行するか、 レプリカ間でずらして行います。
• リージョン障害。 顧客がリージョンフェイルオーバーを必要とする場合、 業務データベース、シークレットマネージャー、イングレスのすべてが クロスリージョンである必要があります。ObjectOS 自体はイメージが利用可能な 場所であればどこでも実行できます。

ランブックに記載すべき内容

• 各データセットのバックアップスケジュール、保持期間、オンコール連絡先。
• ステップバイステップの復元手順（最初にデータベース、次に成果物、 最後に ObjectOS の起動）。
• 復元したデータベースの整合性を確認する検証クエリ。
• ObjectOS イメージと成果物バージョンの両方のロールバック計画 （アップグレードとロールバック を参照）。
• 顧客に見える障害のためのコミュニケーションテンプレート。