バックアップの宛先

バックアップ戦略は、複数のストアに書き込めます。宛先ごとに独立した復旧ポイントになり、それぞれが専用のスナップショット、専用のコミット、専用のステータス行を持つため、1つのストアで障害が起きても他のストアには影響しません。

すべてのストアは1つのアカウントに属します。1つのconfig、1つのライセンス、1つの請求で全体をカバーします。2つのアカウントにサインインしているマシンは、これまでどおり拒否されます。複数の宛先とは、1つのアカウント内の複数のストアを意味するためです。

ストア

ストアは、アカウントサーバーがマシンの代わりに書き込むバケットです。すべてのサブスクリプションには初日から home という名前のストアが1つあります。バックアップ系のコマンドがこれまで使ってきたホスト型ストアです。ストアを指定しない宛先は home に書き込みます。

これ以外に、次の2種類を登録できます。

種類	内容	登録に必要なもの
hosted-r2	デプロイが提供するリージョンから選ぶ、2つ目のホスト型リージョン	IDとリージョン。認証情報は不要
customer-s3	お客様が運用するバケット。S3、RustFS、その他のS3互換サービス上のもの	ID、HTTPSエンドポイント、バケット、署名リージョン(既定は us-east-1)、任意の公開エンドポイント、アクセスキーのペア1組

マシンがお客様のバケットのキーを保持することはありません。キーは封印された状態でアカウントサーバーに置かれ、マシンはセッションが指定する1つのストアに対してだけ、有効期間の短い署名付きURLを受け取ります。

ストアの登録

登録は rdc コマンドではなく、アカウントAPIの呼び出しです。POST /backups/stores でストアを登録し、GET /backups/stores で登録済みのストアを一覧し、DELETE /backups/stores/<id> でストアを廃止します。登録、ローテーション、廃止には、現在の組織オーナーまたは管理者が作成した、スコープ backup:manage のAPIトークンが必要で、いずれも監査記録に残ります。一覧には backup:read が必要です。

サーバーはストアを受け付ける前に検査します。

• 適合性プローブ。 ホスト型ストアが通るのと同じチェックをサーバーが実行します。チェックサムを強制しないストアは、最初のバックアップで発覚するのではなく、登録の時点で拒否されます。
• 削除プローブ。 プローブは削除も試します。ストアが削除を拒否した場合、クリーンアップを無効にした状態で登録されます(下記参照)。
• エンドポイントのルール。 HTTPSのみ、ポートは443、内部ネットワーク上のエンドポイントは不可。
• ストア数の上限。 サブスクリプションあたりのストア数はプランによって決まります。home を含み、廃止したストアは数えません。

プラン	ストア数
Free	1
Community	2
Professional	3
Business	5
Enterprise	10

すでに存在するIDを登録すると、認証情報だけがローテーションされ、プローブが再実行されます。認証情報が使えなくなったストアは、最初に拒否された権限付与の時点で停止中としてマークされます。GET /backups/stores にはエンドポイント、バケット、キーIDの末尾の文字が表示され、シークレットは表示されません。

有効な宛先がまだ指定しているストアは廃止できません。home も廃止できません。

宛先のストアを指定する

宛先のストアは、--destination と一緒に使う --target で指定します。

# Write to the home store (the default).
rdc backup strategy set daily --destination primary

# Write to a registered store.
rdc backup strategy set daily --destination offsite --target office-rustfs

オプション	説明
--destination <name>	作成または変更する宛先
--target <storeId>	宛先が書き込む登録済みストアのID(既定は home)。--destination が必要

1つの戦略の有効な2つの宛先が同じストアを指定することはできません。登録されていないストアは、登録済みIDの一覧とともに拒否されます。

スケジュールされた各実行は、有効な宛先ごとに、宛先を宣言した順にスナップショットを1つ取り、それぞれに専用の帯域幅の上限が適用されます。スナップショットはいずれも新しいコピーオンライトのreflinkなので、それぞれが単独で整合性のある時点になります。失敗した宛先があっても、次の宛先はスキップされません。ただし、どれかの宛先が失敗した場合、ユニットは非ゼロで終了するため、systemdと実行漏れチェックが失敗を検知できます。

ストアから復元する

rdc backup restore、rdc backup restore --path、rdc backup browse --at、rdc backup download --store は --from <storeId> を受け付けます。

# The best store, chosen automatically.
rdc backup restore my-app --as my-app-copy --at <snapshot-id>

# One named store.
rdc backup restore my-app --as my-app-copy --at <snapshot-id> --from office-rustfs

--from を省略すると、CLIはリポジトリの系統を保持しているストアをアカウントサーバーに問い合わせます。直近の検証に合格した最新のスナップショットを持つストアを先頭に順位付けされ、その順に試します。スナップショットのないストアはスキップされます。順位を読み取れない場合、復元は home を使い、その旨を表示します。

--from を省略した backup restore、restore --path、browse --at、download --store は、その順位の先頭のストアから始め、障害がストア側にある場合に次のストアへ切り替えます。サーバーエラー、拒否された権限付与やセッション、応答しないエンドポイントが該当します。どのコマンドも、どのストアが処理したかを表示します。スナップショット自体の不具合では、どのコマンドも切り替えません。存在しない、期限切れ、破損したスナップショットはどのストアでも同じに見えるため、代わりにエラーが表示されます。--from を指定したコマンドは、そのストアだけを読み、切り替えは行いません。

--from なしで指定したスナップショットIDは、系統のすべてのストアを対象に検索されます。

宛先ごとのステータス

rdc backup status は、スケジュールの表に加えて、宛先ごとに1行を表示します。

列	意味
Store	宛先が書き込むストアのID
Last run	そのストアに対する最後の実行が終了した時刻
Result	その実行の結果
Newest snapshot	ストアが保持する最新のスナップショット
Verify	ストアの直近の検証の結果
Clean-up	enabled、または無効の場合はその理由

アカウントが状態を報告できないストアは、その列に - が表示されます。実行漏れチェックはストアごとに行われるため、バックアップを受け取らなくなったストアは独自のアラームを上げ、他のストアは正常のままです。

クォータに含まれるもの

ホスト型ストア(home と2つ目のリージョン)は、物理的に保存された一意のバイト数で計測され、そのバイト数は同じプランのクォータに含まれます。rdc backup usage で確認できます。

お客様のバケットのバイトはRediaccが保存しないため、クォータには含まれません。そのためにアカウントが保持するメタデータ(マニフェスト行、検証の実行、インデックスオブジェクト)は、ホスト型ストアと同じように計測されます。

クリーンアップが無効なストア

削除を拒否するストアは、すべてのオブジェクトを保持します。保持期間の管理とガベージコレクションは、そこから何も削除しません。スナップショットが期限切れになると、スイープはアカウント上でそれを期限切れとしてマークし、復元の候補から外しますが、オブジェクトはバケットに残します。

rdc backup status とバックアップのヘルスダイジェストは、そのストアをクリーンアップ無効として報告します。削除権限のあるキーで同じIDを再登録して削除用の認証情報を追加するまで、バケットは増え続けます。