午前2時の緊急アラート：ストレージ枯渇の悪夢
日曜日の午前2時15分、PagerDutyのアラートがスマートフォンに鳴り響きました。画面には「PVE-Storage-Pool: 98% disk capacity reached（ディスク使用率98%到達）」の文字。わずか3週間の間に、8台のVMと12個のLXCコンテナを素のNFSストレージにバックアップする標準のvzdumpスケジュールが、なんと14TBものディスク容量を食いつぶしていたのです。毎晩のジョブで生成されるのは、非圧縮または巨大な単一の.vma.zstアーカイブ。毎回まったく同一のギガバイト級OSレイヤーがネットワーク上を流れ、1Gbpsの帯域を圧迫し、ストレージI/Oを極限まで疲弊させていました。
本番データベースのクエリが停滞する中、手作業で古いアーカイブを削除する作業は悲惨そのものでした。そして、痛感したのです。クラスターの規模が数ノードを超えると、従来のフルバックアップや差分バックアップ戦略は破綻するのだと。
Proxmox Backup Serverがストレージの肥大化を解決する仕組み
Proxmox Backup Server（PBS）は、巨大なモノリシックイメージの一括ダンプを廃止し、以下の4つの特化メカニズムを採用しています。
- チャンク単位の重複排除（Chunk-Level Deduplication）： PBSはバックアップストリームを平均4MBの動的なコンテンツ定義チャンクに分割します。例えば20台のDebianやWindows ServerのVMが同一のベースバイナリを共有している場合、PBSはすべてのVMおよびスナップショット履歴を通じて、その共有ブロックを一度だけ保存します。
- ダーティビットマップによる永久増分バックアップ（Incremental Forever Backups）： QEMUのダーティビットマップ（Dirty Bitmaps）がRAM上で変更されたディスクブロックを追跡します。PVEクライアントは新しく変更されたチャンクのみをPBSにアップロードします。日々の変更差分が450MB程度の200GBデータベースVMのバックアップなら、40分かかっていた処理がわずか15秒で完了します。
- クライアント側暗号化（Client-Side Encryption）： PVEハイパーバイザーは、データをネットワーク経由で送信する前にAES-256-GCMでチャンクを暗号化します。PBSは暗号化されたブロブ（Blob）をそのまま保存するため、秘密の復号キーにアクセスすることは一切ありません。
- 自動整合性検証（Automated Integrity Verification）： バックグラウンドの検証ジョブが、保存されたチャンクをSHA-256チェックサムと照合し、災害時のリストアが必要になるずっと前にディスク上のビット腐敗（ビットロット）を検出します。
実践ガイド：ベアメタルPBSの構築とPVEとの統合
ステップ 1：専用マシンにProxmox Backup Serverをインストールする
PBSは常に、メインのPVEコンピュートクラスターとは別のスタンドアロンハードウェアまたはセカンダリホスト上で実行してください。公式のPBS ISOイメージを書き込んでインストールするか、クリーンなDebian 12（Bookworm）最小サーバー上にインストールできます。
既存のDebian BookwormマシンにPBSをインストールするには、コミュニティリポジトリを設定します。
# PBS no-subscriptionリポジトリを追加
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" > /etc/apt/sources.list.d/pbs.list
# Proxmoxのリリースキーをダウンロードして登録
wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
# パッケージインデックスを更新してサーバーパッケージ一式をインストール
apt update && apt install -y proxmox-backup-server
インストールが完了したら、ブラウザを開いて https://<PBS-IP-ADDRESS>:8007 の管理パネルにアクセスします。
ステップ 2：ストレージの初期化とデータストアの作成
バックアップチャンクは専用のZFSプールに保存します。2台のディスクによるミラーリング、または複数ディスクによるRAIDZ2構成を採用することで、高い耐障害性とデータブロックの自己修復機能が得られます。
# 4TBのエンタープライズドライブを使用してミラー構成のZFSプールを作成
zpool create -f -o ashift=12 backup-pool mirror /dev/sdb /dev/sdc
# データストア用のマウントポイントパスを設定
zfs set mountpoint=/mnt/datastore/backup-pool backup-pool
CLIを使用するか、Web UIの Datastore > Add Datastore からPBS内にデータストアを登録します。
proxmox-backup-manager datastore create BackupVault /mnt/datastore/backup-pool
ステップ 3：専用バックアップユーザーとAPIトークンの作成
PVEの認証にPBSのrootアカウントを使用するのは避けてください。代わりに専用のサービスアカウントを作成し、権限を制限したAPIトークンを紐付けます。
# PVE用のサービスアカウントを作成
proxmox-backup-manager user create pve-backup@pbs --comment "PVEクラスター用バックアップワーカー"
# 対象のデータストアにDatastoreBackup権限を付与
proxmox-backup-manager acl update /datastore/BackupVault DatastoreBackup --auth-id pve-backup@pbs
# 自動認証用のAPIトークンを生成
proxmox-backup-manager user generate-token pve-backup@pbs pve-token
ターミナルに表示されたシークレットトークンキーをコピーします。次に、PBSホストからTLS証明書のフィンガープリントを取得します。
# SHA-256証明書フィンガープリントを抽出
proxmox-backup-manager cert info | grep "Fingerprint (SHA256)"
ステップ 4：Proxmox VEにPBSストレージターゲットを追加する
Proxmox VEのrootシェルに切り替えます。中間者（MITM）攻撃を防ぐためにAPIトークンと証明書フィンガープリントを渡し、pvesmを使用してクラスターをPBSに接続します。
# クライアント側暗号化を有効にしてPVEにPBSリモートストレージを追加
pvesm add pbs PBS-Remote \
--server 192.168.10.50 \
--datastore BackupVault \
--username pve-backup@pbs!pve-token \
--password "ab48f189-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
--fingerprint "9a:4f:b3:81:12:...:5e:31" \
--encryption-key autogen
--encryption-key autogen パラメータにより、ローカルの共通鍵が /etc/pve/priv/storage/PBS-Remote.enc に書き込まれます。このファイルをダウンロードし、暗号化パスワードマネージャーやオフラインのコールド保管庫に安全に保存してください。PVEノードがクラッシュした場合、このキーファイルがなければ暗号化されたバックアップを一切復元できなくなります。
ステップ 5：重複排除バックアップの実行と計測
新しいPBSターゲットに対して、VM（例：VMID 101）の手動テストバックアップを即座に実行してみます。
vzdump 101 --storage PBS-Remote --mode snapshot
初回の実行ではゲストドライブ全体が読み取られ、ユニークな4MBチャンクがPBSにストリーミング送信されます。次に、1分後にまったく同じコマンドを実行してみてください。
QEMUのダーティビットマップによって変更されたブロックがないことが認識されているため、PVEは変更のないディスクセクターを完全にスキップします。2回目の実行はわずか5秒未満で完了し、転送されるのは数キロバイトのメタデータのみです。20〜50台のVMが稼働する本番環境では、重複排除率が通常8倍〜25倍程度に収束します。
ステップ 6：保持ポリシー、ガベージコレクション、検証の設定
データストアを健全な状態に保つため、Datastore > Prune & GC Jobs で自動メンテナンスジョブを設定します。
- プルーニング（Prune）スケジュール：
keep-daily=7、keep-weekly=4、keep-monthly=6などの保持ルールを設定します。 - ガベージコレクション（GC）： 週に1回（例：日曜日の午前3時）実行するようにGCをスケジュールします。プルーニングは参照されなくなったスナップショットに削除マークを付けるだけですが、GCによってリンクの切れたチャンクがディスクから実際に削除されます。
- 検証ジョブ（Verify Jobs）： 保存されたチャンクの整合性検証を毎週実行し、障害によるリストアが必要になる前にストレージレベルのディスク破損を早期特定します。
ディザスタリカバリのためのより優れた基盤
Proxmox Backup Serverへ移行することで、肥大化したバックアップ時間枠と膨大なストレージの浪費を解消できます。ネットワーク負荷は劇的に軽減され、VM間の重複排除によりディスク使用量は80%以上削減、さらにクライアント側暗号化によってオフサイトデータも安全に保護されます。保持ポリシーと定期的な検証ジョブを設定しておけば、バックアップパイプラインはバックグラウンドで安定して稼働し続けます。
