この記事の見出し一覧
自宅ラボのProxmox VEクラスタ、これまでNFSとローカルディスクだけでバックアップを取っていたが、「オフサイトにもう1本、しかも安価に」を目標に、Proxmox Backup Server(PBS)のS3バックエンドとしてWasabi Object Storageを使う構成を組んでみた。今回はその手順と、実際に動かしてみた所感をまとめておく。
構成の全体像
- Proxmox VE 9.2.3(pveノード) … バックアップ対象のVM/CTが動く本体
- Proxmox Backup Server 4.2.0(VMノード、pve上) … バックアップの受け皿
- Wasabi Object Storage(シンガポール/ap-southeast-1リージョン) … PBSのデータストアが実データを置くS3バックエンド
PBS 4.xからデータストアの実体をS3互換ストレージに置けるようになったので、「PBS自体はキャッシュ用の小さいローカルディスクだけ持ち、実データはS3」という構成が可能になっている。これを使ってWasabiの安いオブジェクトストレージにバックアップを逃がすのが今回の狙い。
Wasabi側の準備
アカウント作成と有料プランへのアップグレード
Wasabiはアカウント作成直後は無料トライアル(1TB・30日間)で利用でき、期限内であればそのまま検証を進められる。ダッシュボードを見ると、トライアル開始が2026/07/01、終了が2026/08/01、割当ては1.00TBと表示されていた。
今回は本運用前提だったので、問題が起きなければ有料プランへアップグレードするつもりだ。Wasabiの従量課金プランは以下の内容。
- 月額 $7.99〜(USドル/月、使った分だけ課金：ドル円160として1,278円)
- 出力(エグレス)・APIリクエストは追加料金なし
- ベーシックサポートプラン込み
- アクティブストレージの最低必要容量は1TB(最低利用量の考え方に近い)
エグレス・API課金がない点は、リストア時の転送量を気にしなくていいのでホームラボ用途ではかなりありがたい仕様。
バケットの作成とリージョン選択
バケット名は例として pbs-jpn、リージョンはシンガポール(ap-southeast-1)を選択した。日本国内リージョンではないが、体感のレイテンシは許容範囲。バケットの「属性」タブでは、ストレージサイズが日次で集計され、運用開始後は181.69GBまで積み上がっているのが確認できた（集計は日次のため、当日分の増減はまだ反映されていない旨の注記あり）。
コンプライアンスモード(オブジェクトロック)の検討
バケット設定の「コンプライアンス」タブでは、コンプライアンスモードをオンにして保持期間を日単位で設定できる。有効にすると、指定した保持期間中はオブジェクトの削除・変更が一切できなくなり、ランサムウェア対策や誤操作からのバックアップ保護に使える機能だ。
ただし、有効化するとファイルの全バージョンが保持されてストレージコストに積み上がっていく仕様のため、PBSのprune/GCジョブとの相性は事前によく検討したほうがよい。今回はまず短めの保持日数で試験的に有効化し、運用しながら期間を調整していく方針にしたが、PBSの現バージョンではエラーになったのが残念だ。
アクセスキーの発行
「アクセスキー」メニューから新規キーを発行。作成直後の画面でのみアクセスキーとシークレットキーが表示され、閉じると二度と表示されない(再表示不可)ので、この場でPBS側の設定にそのまま転記した。ルートアカウントキーをそのまま使う形にしたが、権限を絞ったIAMユーザーを別途作る運用の方が本来は望ましいので、後日見直す予定。
Proxmox Backup Server側の設定
S3エンドポイントの追加
PBSの「Configuration → S3 Endpoints」から、Wasabiを新規エンドポイントとして登録する。
| 項目 | 設定値 |
|---|---|
| S3 Endpoint ID | wasabi |
| Endpoint | ap-southeast-1.wasabisys.com |
| Region | ap-southeast-1 |
| Port | default (443) |
| Access Key / Secret Key | Wasabiで発行したキーを入力 |
| Path Style | 有効(チェックON) |
WasabiはS3互換APIだが、Path Style形式でのアクセスが必要になる点がハマりどころ。ここのチェックボックスがオフのままだと接続テストで失敗するので要注意。
S3バックエンドのデータストア作成
エンドポイント登録後、Datastore作成時にバックエンドとして先ほどのS3エンドポイントとバケットを指定する。作成できたデータストア「wasabi」のSummary画面では、キャッシュ使用率が5.50GB/27.61GB(20%)、直近30日のタスクサマリーとしてBackup成功11件、Garbage collection成功1件、重複排除係数(Deduplication Factor)は1.05という結果が出ていた。ローカルキャッシュ分はそこまで大きくならず、実データの大半はWasabi側にretireされている形になる。
ユーザーと権限
PBS側のユーザーは admin@pbs を作成し、/datastore/wasabi に対してAdminロールをPropagate(配下に伝播)する設定で権限を付与した。Proxmox VE側からこのデータストアにアクセスする際の認証にもこのユーザーを使う。
Proxmox VE側にPBSをストレージ追加
PBSをバックアップストレージとして登録
Proxmox VEの「Datacenter → Storage → Add → Proxmox Backup Server」から、先ほど構築したPBSを登録する。
| 項目 | 設定値 |
|---|---|
| ID | wasabi-storage |
| Server | 192.168.0.45(PBSのIP) |
| Username | admin@pbs |
| Datastore | wasabi |
| Fingerprint | PBSダッシュボードの「Show Fingerprint」で取得した値を入力(下画像) |
証明書は自己署名のため、Fingerprintの入力を忘れると接続エラーになる。PBS側のダッシュボードで表示されるSHA-256フィンガープリントをそのままコピーして貼り付ければOK。
バックアップジョブの実行
登録が済んだら、通常のvzdumpバックアップジョブの保存先として wasabi-backup を選択するだけで、あとは既存のスケジュールジョブに乗せられる。ストレージのBackups一覧には、VM100〜VM121まで複数のVMのバックアップが並び、フォーマットは pbs-vm、暗号化はNo、検証状態はNoneの状態で実行できていることを確認した。
実際に届いたバックアップ完了メール(vzdump backup status)では、8台のVM(VMID 100, 101, 105, 110, 115, 116, 117, 118)すべてが ok で完了し、合計所要時間 1時間33分6秒、合計サイズ 382.001GiB という結果だった。VM105(128GiB)の転送に40分ほどかかっているのを見ると、初回フルバックアップ相当のデータ量ではWasabiへの上りが律速になっている印象はあるが、差分メインの日次運用であれば十分実用的な時間に収まりそうだ。
構築した所感
- 料金面:最低1TB課金($7.99〜/月)なので、少量データだと割高感はあるが、エグレス・APIリクエストが無料なのはリストアテストを気兼ねなくできる点で大きい。
- 重複排除:デデュープ係数1.05という数値からもわかる通り、PBS側のチャンクベース重複排除はS3バックエンドでもちゃんと効いている。
- 設定のハマりどころ:Path Style有効化とFingerprintの入力、この2点を押さえれば接続自体はスムーズ。逆にここを見落とすと接続確認で延々とエラーになるので最初に確認したい。
- 今後の課題:コンプライアンスモード(オブジェクトロック)を有効にした場合のPrune/GCジョブとの兼ね合いは、もう少し運用データを溜めてから改めて記事にしたい。
まとめ
Proxmox Backup ServerのS3バックエンド機能を使うことで、ローカルのProxmox VEクラスタからオフサイト(しかも海外リージョン)のオブジェクトストレージへ、追加コストを抑えつつバックアップを逃がせる構成が組めた。ホームラボ規模であれば、Wasabiの最低1TBプランでもコスト感は許容範囲内で、今後は複数世代の保持と、コンプライアンスモードを使った改ざん耐性のあるバックアップ運用に発展させていきたい。
※本記事は当サイト管理人の個人的な備忘録です。情報内容には配慮しておりますが、本記事の参照または付随ソースコード利用後にいかなる損害が発生しても、当サイト及び管理人はいっさいの責任を負いません。