ストレージと復旧

プロセスの再起動、新しいデプロイ、またはホスト障害をまたいで保持する必要があるデータに応じてストレージを選択してください。これらはそれぞれ異なるイベントです。永続ストレージ自体は、バックアップ、復元ポイント、高可用性を提供しません。

データ	保管場所	境界
アプリケーションレコード	Managed Postgres または別のデータベース	再起動と、削除または破損したデータの復元は別です。別個のエクスポートおよび復元経路をテストしてください。
キャッシュおよびキューデータ	Managed Redis	ワークロードが状態を再構築できるのか、独自の復旧計画が必要なのかを判断してください。Managed Redis にはエビクションポリシーも追記専用ファイル (AOF) もありません。メモリが不足すると再起動し、直近の書き込みが失われることがあります。失えないデータは Managed Postgres に保存してください。
アプリケーション間で共有されるファイル	Managed Object Storage	自動作成される `default` bucket は非公開です。bucket を公開するのは、誰がファイルを読んでもよい場合だけにし、ダッシュボードの bucket ブラウザーから設定してください。

sandbox のファイルには別のルールが適用されます: sandbox の終了後も残るのは、接続した Persistent Volumes の /workspace 上のファイルと、自分で作成したスナップショットの中身だけです。保存と課金を参照してください。

sandbox の終了後もファイルを保持する

ダッシュボードの ボリューム ページで名前付きボリュームと接続を管理します。sandbox の作成時にボリュームを接続し、/workspace に書き込んでください。別の sandbox に接続する前に、現在の sandbox を停止します。

メモリも含めて sandbox 全体を残すには、lizard sandbox snapshot <id> で保存し、あとで lizard sandbox restore <snapshot-id> でコピーを起動します。スナップショットを参照してください。

削除したプロジェクトは、アプリとデータベースごと 3 日間ゴミ箱に残ります。削除したデータベースも同じです。その間は、ワークスペースまたはプロジェクトの設定にある 危険ゾーン から復元できます。期間を過ぎると、Lizard が完全に削除します。

単独で削除したアプリがゴミ箱に入るのは、lizard up でファイルからデプロイした場合だけです。復元すると、そのアップロードから再ビルドされます。GitHub からデプロイしたアプリはすぐに削除されます。
Sandboxes、そのボリューム、スナップショットにはゴミ箱がありません。それら自体や、それらが属するプロジェクトを削除すると、すぐに消えます。
ワークスペースの削除にもゴミ箱はありません。

データを変更する移行またはリリースの前に:

データベースがマネージドであることを理由に、定期バックアップ、ポイントインタイムリカバリ、マルチノードレプリケーション、または復元時間の保証を想定しないでください。現在のサービス契約と、そのリソースで利用できる制御を確認してください。

アプリケーションは、環境参照からデータベース接続を読み取るべきです。接続文字列は認証情報です。更新を確認するためにそれを出力するのは避けてください。SELECT 1 のような接続確認は、shell 内で変数を見るよりも多くを証明します。