ガイド

著者 Matt Connor 2026-08-15

VPSにProxmox Backup Serverを構築する方法

Q: backup encryption key はどこに保存すべきですか？

保護対象の cluster だけに保存することは避けてください。Proxmox VE は /etc/pve/priv/storage/ .enc に保持しますが、これはすべての node に複製されるため、cluster とともに失われます。初日に別の場所へコピーし、proxmox-backup-client key paperkey で印刷して、そのコピーを別の建物で保管してください。また、この key は chunk digest の生成に使われるため、後から置き換えると次回の backup で全データが再度 upload されます。

VPSをProxmox Backup Serverのオフサイトバックアップ先にする手順です。データストア、ホスト別ネームスペース、prune、ガベージコレクション、暗号化鍵、リストアテストを解説します。

VPS 上の Proxmox Backup Server で実現できること

VPS 上の Proxmox Backup Server (PBS) は、既存の Proxmox VE (virtual environment) クラスターが使用しているものと同じプロトコルで通信するオフサイトのバックアップ先です。そのため、初回以降のバックアップはすべて増分となり、ゲスト間で重複排除され、施設外へ送信される前に暗号化され、後から検証できます。ブロックボリューム付きの VPS を借り、Debian 13 に PBS をインストールし、そのボリューム上に 1 つのデータストアを作成して、Proxmox VE に pbs タイプのストレージとして追加します。インストールは 10 分で完了します。その後のネームスペース、ガベージコレクション、鍵の管理、実際に実行したリストアが、1 年後にもそのバックアップに価値があるかどうかを決めます。

PBS を使用する理由は、vzdump ファイルをレンタルしたディスクへコピーする方式とは異なり、チャンクストアを利用できるためです。クライアントは各ゲストディスクを約 4 MiB のチャンクに分割してハッシュ化し、データストアにまだ存在しないチャンクだけをアップロードします。稼働中の仮想マシンでは、初回バックアップ後に QEMU が dirty bitmap を使って変更ブロックを追跡するため、次回以降はローカルディスクから変更されたブロックだけを読み取ります。200 GB のゲストで 1 日に 3 GB が変更される場合、送信されるデータも 1 日あたり約 3 GB です。これにより、自宅の uplink とレンタルボリュームを組み合わせて運用できます。そのため、VPS をオフサイトバックアップ先として使用する方法は、友人宅に予備ドライブを置くよりも優れています。ハイパーバイザー自体をどこで運用するかまだ決めていない場合は、自宅運用の Proxmox とレンタル VPS の比較でこの問題を別途説明しています。

ボリュームを借りる前にサイズを決める

サイズの算出は、自分の環境の数値で行う計算です。各ゲストが実際に使用している容量を使い、仮想ディスクのサイズは使わないでください。そのうえで、1 日あたりの変更量に保持日数を掛けた値を加えます。圧縮と重複排除によって実際の使用量はさらに減るため、この結果は目標値ではなく上限として扱います。

ChartWorked sizing example: three guests, thirty daily snapshots kept

label

used_gb

daily_change_gb

store_gb

web VM

0.8

mail VM

120

3.0

210

file server container

300

1.5

345

The data behind this chart

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

これらの行は計算例であり、測定値ではありません。各ゲスト内の df -h から使用容量を確認してください。日次の変更量は、PBS のタスクログに 2 回目と 3 回目のバックアップが記録された後、それらのサイズから確認します。

この例のメールゲストは 120 GB を使用し、1 日あたり約 3.0 GB 変化します。そのため、30 日分の日次スナップショットには、およそ 210 GB が必要です。完全なコピー 1 つ分に、30 日分の変更量を加えた計算です。3 台のゲストについて最後の列を合計すると、合計は約 619 GB です。インデックス、メタデータ、ガベージコレクションに必要な空き容量として、その 5 分の 1 を上乗せすると、1 TB のボリュームが適しています。

残りの構成は小規模です。PBS は RAM 2 GB で動作し、4 GB なら余裕があります。負荷の高い処理はクラスタ側で実行されるためです。Proxmox VE ノードがゲストのディスクを読み取り、チャンク分割とハッシュ計算を行います。VPS 側で行うのは、チャンクの書き込みと、ガベージコレクションおよび検証という 2 つの負荷の高いジョブの実行です。データストアは、1 つの大きな root ディスクではなく、別のブロックボリュームとして借りてください。後からサーバーを再構築せずにボリュームを拡張できるためです。

Debian 13 に Proxmox Backup Server をインストールする

2026 年 8 月時点の組み合わせは、Debian 13（コードネーム trixie）上の Proxmox Backup Server 4 です。古い手順では PBS 2 と Debian 11 を組み合わせており、コードネームはリポジトリ定義の一部です。そのため、古い suite 名をコピーすると、リリースファイルが見つからないという apt エラーになります。Debian 13 の最小構成イメージから開始してください。以下の操作はすべて root で実行するか、sudo を付けて実行してください。

sudo apt update && sudo apt install -y wget
sudo wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

チェックサムは 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45 になる必要があります。一致しない場合は中止してください。正しくない keyring を使用すると、確認していない署名でパッケージをインストールすることになります。

サポート契約のないサーバーに適した no-subscription リポジトリを、/etc/apt/sources.list.d/pbs.sources に記述します。

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update
sudo apt install -y proxmox-backup-server

Web インターフェースは HTTPS の 8007 番ポートで応答します。root@pam として、システムの root パスワードでログインしてください。PBS は PAM（pluggable authentication modules）を使用してこのユーザーを認証します。これはオペレーティングシステムが使用するアカウントと同じものです。証明書は自己署名のため、ブラウザーに警告が表示されます。この証明書のフィンガープリントは、後で Proxmox VE がピン留めに使用する値です。そのため、この警告は想定されるものであり、修正すべき問題ではありません。

8007 番ポートはパブリックインターネット上のログインフォームです。そのため、全員に開放したままにしないでください。1 つの nftables ファイルで管理できます。/etc/nftables.conf を書き込むと、現在のルールセットが flush されます。そのため、このサーバー上で別の仕組みがすでにファイアウォールを管理している場合は実行しないでください。

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

sudo systemctl enable --now nftables で適用してください。実行中は、2 つ目の SSH セッションを開いたままにしてください。policy drop に加えて SSH ルールを 1 文字でも誤ると、自分のサーバーから締め出されます。203.0.113.7 は、クラスターから離脱する接続元アドレスに置き換えてください。そのアドレスが動的な場合は、プロバイダーの範囲までルールを広げるか、トンネルで接続を終端してください。また、多くの VPS パネルにはマシンの前段に独立したネットワークファイアウォールがあるため、同じポートを許可する必要があります。

データストアを専用ボリュームに配置する

データストアを root ファイルシステムに配置してはいけません。データストアによって共有 root ファイルシステムが満杯になると、バックアップだけでなく、そのサーバー上のすべての処理が失敗します。原因の調査に必要なログ出力も停止します。ブロックボリュームを接続し、フォーマットし、マウントしてから、マウントポイント内にデータストアを作成してください。

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

デバイス名は lsblk から取得してください。ほとんどの KVM イメージでは /dev/vdb、その他のイメージでは /dev/sdb ですが、決めつけてはいけません。再起動後のデバイス名の変更によってデータストアが別のディスクを参照しないように、ラベルを使って /etc/fstab にマウントを追加してください。

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt では、デバイス、パス、rw,relatime を含むオプションが表示されるはずです。この1行には、2つの障害が隠れています。マウントされていない状態でデータストアを作成すると、PBS はマウントポイントの下にある root ファイルシステムへ書き込みます。その後マウントが正常に行われても、このデータは削除されずに隠れます。その結果、データストアは空に見えますが、root ファイルシステムは満杯のままです。オプションに noatime と表示される場合、PBS は動作しません。データストアの作成時と、各 garbage collection の実行時に access time の安全性チェックを行うためです。

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

これにより、.chunks ディレクトリが作成されます。このディレクトリには、0000 から ffff までの名前を持つ 65536 個のサブディレクトリが格納されます。データストアは、少数の大きなファイルではなく、数十万個の小さなファイルで構成されます。このため、2つの点に注意が必要です。通常のファイル単位のツールでデータストアをコピーすると、遅すぎて実用になりません。また、バックアップ実行中に取得したプロバイダーのボリュームスナップショットは、データストアの一貫したコピーではありません。これは、他の場所でもスナップショットがバックアップの代わりにならないのと同じ理由です。

Namespaces によって 2 台のホストのデータが衝突しないようにする

データストアは、デフォルトではフラットな構成です。バックアップには vm/100、ct/101、host/<name> という名前が付けられます。どちらのクラスタにも ID 100 のゲストがある場合、両方のクラスタが同じグループに書き込むため、スナップショットが混在します。一方のクラスタ用に設定した保持ルールが、もう一方のクラスタのスナップショットまで数えてしまいます。Namespaces を使うと、1 つのデータストア内に、ソースごとのツリーを作成できます。

PBS ホスト上で作成します。--repository 引数の形式は [[auth-id@]server[:port]:]datastore です。そのため、ローカルの namespace は root@pam@localhost:store1 になります。このコマンドを実行すると、root パスワードの入力を求められます。

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

この分離によって重複排除の仕組みは変わりません。チャンクはデータストア全体で共有されるため、3 つの namespace に分散した Debian ゲストが 10 台あっても、ベースシステムは 1 つだけ保存されます。これが、ホストごとに 1 つのデータストアを用意するより、1 つのデータストアに namespaces を設定する方がよい理由です。データストアを分けるとチャンクプールも分かれます。チャンクプールを分けると、同じ Debian のインストールを何度も保存することになります。

ソースごとにアカウントを作成し、それぞれの namespace だけを使用できるように権限を限定します。API（application programming interface）トークンはユーザーに属する認証情報で、独自の権限を持ちます。盗難の可能性があるマシンでは、この方式が適しています。

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

トークンコマンドは、シークレットを 1 回だけ表示します。

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

PBS は、後から再表示できる形でシークレットを保持しません。そのため、表示された時点でコピーしてください。アクセス制御コマンドは慎重に確認してください。そこではユーザーではなく、トークンである backup@pbs!pve-home を指定します。トークンの権限は、トークン自体を指定したエントリだけから計算されるためです。backup@pbs だけを指定したエントリでは、トークンにアクセス権がまったく付与されません。その場合、最初のバックアップはネットワーク上で確認できる問題ではなく、権限エラーで失敗します。パスも同様に重要です。/datastore/store1/pve-home に限定されたトークンは、office namespace 内のデータを読み取ったり削除したりできません。そのため、1 つのクラスタが侵害されても、別のサイトの履歴を破壊されることはありません。

Proxmox VE に VPS をバックアップストレージとして追加する

まず PBS ホストで証明書のフィンガープリントを確認します。

sudo proxmox-backup-manager cert info | grep Fingerprint

次に、クラスタ内の任意のノードで実行します。

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

3 行目のプレースホルダーを、cert info に表示された値で置き換えます。値を指定せずに --password を渡すと、pvesm が入力を求めるため、トークンの Secret がシェル履歴に残りません。Secret は /etc/pve/priv/storage/pbs-offsite.pw に保存されます。ストレージ定義自体は /etc/pve/storage.cfg に保存され、クラスタ内のすべてのノードに複製されるため、クラスタ全体に対して 1 回だけ設定すれば済みます。

--prune-backups keep-all=1 は、Proxmox VE に何も削除しないよう指定します。保持期間の設定は PBS 側で行います。これは明確な理由があります。トークンに削除権限が不要になるため、クラスタがランサムウェアによって暗号化されても、復旧に必要なオフサイトの履歴を削除できません。

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status を実行すると、ステータス列に active が表示され、その横にデータストアの総容量と使用容量が表示されます。inactive は、ノードがポート 8007 への TLS (transport layer security) セッションを確立できなかったことを示します。これは認証情報ではなく、ファイアウォールまたはフィンガープリントの問題です。

最初のバックアップではすべてのデータをアップロードするため、開始前に計算しておきます。200 GB は 1600 gigabits です。100 Mbit のアップリンクでは毎秒 0.1 gigabit を転送できるため、理論上の最短でも約 4.5 時間かかり、実際にはさらに長くなります。帯域幅を使う必要がない時間帯に開始してください。2 回目以降は、新しいチャンクだけが送信されます。

クライアント側の暗号化と鍵の保管場所

VPS は、お客様が所有していないコンピューターです。クライアント側で暗号化すれば、データストアにはプロバイダーが読み取れないチャンクだけが保存されます。

sudo pvesm set pbs-offsite --encryption-key autogen

これにより、新しい鍵が /etc/pve/priv/storage/pbs-offsite.enc に書き込まれます。鍵を読み取れるのは root だけで、/etc/pve の他のデータとともに複製されます。次回以降のバックアップでは、クライアントが各チャンクを送信前に暗号化します。サーバーはスナップショットとそのサイズを一覧表示できますが、内容を読み取ることはできません。

ここからが、これをリスクではなくバックアップとして成立させるための重要な部分です。生成された鍵にはパスフレーズがなく、その鍵を保護するクラスターにしか存在しません。そのクラスターが盗まれたり、第三者によって暗号化されたりすると、VPS には誰も開けないデータだけが残ります。鍵を作成した日に、クラスターの外部へコピーしてください。

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey は、紙に印刷して別の場所に保管するための文書として鍵を出力します。このファイルをそのまま秘密情報として扱ってください。ファイルを持つ人は、その鍵で作成されたすべてのバックアップを復号できます。より大規模な構成では、PBS は master key もサポートします。これは proxmox-backup-client key create-master-key で作成する RSA (Rivest Shamir Adleman) 鍵ペアです。各バックアップは固有の暗号化鍵を持ち、その鍵を公開鍵で暗号化して保存します。秘密鍵は、復旧時に使えるようオフラインで保管します。

この設計には、運用を開始してからではなく、開始前に把握しておくべき影響があります。暗号化されたバックアップでは、チャンクのダイジェストが平文の内容と暗号化鍵を結合した値から計算されます。そのため、同一のチャンクでも異なる鍵で暗号化すると異なるダイジェストになり、互いに重複排除されません。鍵を変更すると、次回のバックアップで全データが再度アップロードされます。古いチャンクは、スナップショットが pruning されて回収されるまで残ります。最初のアップロード前に、暗号化を使用するか決めてください。

プルーニングは目印を付け、ガベージコレクションが再利用します

ここが省略されやすい部分であり、ボリュームを満杯にする原因でもあります。スナップショットをプルーニングすると、マニフェスト、インデックス、ログ、ノートなどのメタデータが削除されます。チャンクは一切削除されません。チャンクは複数のスナップショットで共有されるため、残っているすべてのインデックスを読み取るまで、そのチャンクが未使用かどうかは判断できません。そのインデックスを読み取る処理がガベージコレクションです。プルーニングのスケジュールだけを設定し、ガベージコレクションのスケジュールを設定していないデータストアは、増え続けます。

両方を設定します。まず保持期間を設定し、namespace ごとに 1 つのジョブを登録します。

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

次に、データストアでコレクションのスケジュールを設定します。プルーニングジョブの数時間後に実行し、バックアップ時間帯とは重ならないようにします。

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

この分離を、PBS ホスト上で一度確認します。

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

プルーニングジョブを実行し、その後に df を実行しても、使用量は変わりません。ガベージコレクションを実行し、もう一度 df を実行すると、使用量が変化します。

ガベージコレクションは 2 段階で実行されます。第 1 段階では、データストア内のすべてのインデックスを走査し、それらのインデックスが参照する各チャンクのアクセス時刻を更新します。第 2 段階では、アクセス時刻が実行開始時点から 24 時間 5 分より前のチャンクを削除します。ただし、まだ書き込み中の最も古いバックアップの開始時刻のほうが早い場合は、その時刻を基準にします。この余裕は、Linux がデフォルトでファイルシステムを relatime でマウントするために設けられています。relatime では、読み取りのたびにアクセス時刻を更新せず、おおむね 1 日に 1 回更新します。そのため、1 時間前に書き込まれたチャンクは、まだ何からも参照されていなくても削除されません。また、プルーニングで空いた容量が反映されるのは、そのチャンクが最後に参照されてから 1 日以上経過した後に初めてコレクションが実行されたときです。何も回収されていないように見えるデータストアは、単にこの待機期間内にあることがよくあります。

小規模な VPS では、ボリューム上のすべてのチャンクファイルについて stat を取得するため、これがホスト上で最も負荷の高いジョブになります。タスクログの末尾には、削除された項目と、猶予期間のため保留されている項目の概要が表示されます。保留項目が多い場合は、翌日にもう一度実行します。PBS では、gc-atime-safety-check と gc-atime-cutoff をデータストアの調整オプションとして提供していますが、どちらも変更しないでください。これらはアクセス時刻を記録できないストレージ向けの機能です。noatime でマウントされたファイルシステム上で安全確認を無効にすると、実行中のスナップショットがまだ参照しているチャンクまで失うおそれがあります。

検証によりチャンクが引き続き読み取れることを確認できます

正常にアップロードできたバックアップでも、1 年後には読み取れなくなることがあります。検証ではチャンクを再読み込みし、インデックスに保存されたチェックサムと比較します。そのため、リストア時ではなく、スケジュールに従って破損を検出できます。

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

小規模な VPS では、スレッド数を少なく設定してください。検証はディスクと CPU の性能に制限されるため、設定しないとサーバー上の他の処理とリソースを競合します。スケジュールには、Web インターフェースのデータストアにある Verify Jobs タブを使用します。すでに検証済みのスナップショットをスキップし、30 日より古いものを再検証するジョブを週 1 回実行すると、同じ処理を繰り返さずに、時間をかけてストア全体を検証できます。

検証に失敗したスナップショットは、データストアの画面で failed と表示されます。無視しないでください。チャンクは共有されるため、ベースイメージに含まれる 1 つの破損チャンクによって、それを参照するすべてのスナップショットが失敗することがあります。修復するには、失敗したスナップショットを forget してから、新しいバックアップを実行します。これにより、不足しているチャンクが再度アップロードされます。失敗が繰り返し発生する場合は、データストアの基盤ストレージに問題があると考えてください。VPS 上でディスクの健全性を監視する仕組みを設定して、Verify Jobs が検出する前にドライブから異常を通知できるようにします。

復元をテストし、その後クラスターなしでテストする

バックアップが機能することは、実際に復元するまで確認できません。2 種類のテストを行います。それぞれ確認する内容が異なります。

クラスター上でゲスト全体を復元します。

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

pvesm list の最初の列はボリューム ID です。タイムスタンプも ID の一部なので、例を入力せず、自分の値をコピーしてください。未使用のゲスト ID と別のストレージを指定して復元し、ネットワークインターフェースを切断した状態で起動します。バックアップが機能することを確認するために、実行中のゲストへ上書き復元してはいけません。復元が途中で失敗すると、動作しているコピーまで失うためです。

2 つ目のテストは、実施されることがほとんどありません。クラスターのある建物が失われたと仮定し、クラスターに一度も参加していないマシンから復元します。Debian 13 のマシンで、クライアント専用のリポジトリを /etc/apt/sources.list.d/pbs-client.sources として追加します。

Types: deb
URIs: http://download.proxmox.com/debian/pbs-client
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

引用符で囲まれた 3 つのプレースホルダーには、自分の値を入力してください。最後の行のアーカイブ名には、snapshot files の出力に表示された名前を指定します。これにより、最初のテストでは確認できない点を検証できます。つまり、鍵ファイルのコピーで実データを復号できることと、クラスターの設定を一度も保持していないマシンからクライアントを操作できることです。必要だった 4 つの値、リポジトリ文字列、トークンシークレット、フィンガープリント、鍵ファイルを記録し、ディザスタープランで指定した場所にまとめて保管してください。

ディスク使用量に対する重複排除の効果と限界

重複排除は実際に機能し、データストア全体に適用されます。10 台の Debian ゲストでベースシステムのコピーを 1 つ共有できるため、2 台目の同一ゲストの保存コストはほとんど発生しません。サーバーがすでに保持しているチャンクについては、クライアントがデータの代わりにチェックサムを送信するため、アップロード帯域幅も節約できます。

ただし、重複排除でできないことも明確に理解しておく必要があります。

変更されるデータのサイズは縮小しません。データベースが毎晩ファイルの大部分を書き換えると、毎晩新しいチャンクが生成され、保持期間によってそれらが累積します。
前述のとおり、暗号鍵の境界を越えて適用することはできません。
データストアの境界を越えて適用することはできません。これが namespace を使う根拠です。
ボリュームが満杯になることを防ぐものではありません。データストアが満杯になるとバックアップは失敗します。対処方法は、より大きなボリュームにするか、保持期間を短くすることだけです。

その下に別の重複排除層を追加しないでください。チャンクはクライアントによって重複排除と圧縮が済んだ状態で到着します。そのため、データストアの下で ZFS deduplication を有効にすると、書き込まれる前に除去された一致データを探すために RAM を消費します。この用途では、ボリューム上に通常の ext4 または xfs を使用するのが適切です。

Web インターフェースには、データストアの重複排除係数が表示されます。この値は自分のゲストのデータを表すため、運用計画に使う価値があるのはこの値だけです。公表されている比率は、他者のデータに基づくものだからです。Proxmox ゲストではないマシンのファイル単位のバックアップも必要な場合は、同じ VPS 上で併用してください。PBS はゲスト全体を対象とするハイパーバイザー対応の保存先である一方、restic と BorgBackup はディレクトリを対象とします。また、VPS への restic バックアップは、PBS が対象としていないノート PC や単独サーバーに適しています。

障害の発生パターンと確認できる内容

ストレージが inactive と表示される。 ノードがポート 8007 への TLS セッションを完了できない場合、pvesm status --storage pbs-offsite は inactive を出力します。VPS のファイアウォール、次にプロバイダー側の別のネットワークファイアウォール、最後にフィンガープリントを確認します。証明書と一致しなくなったフィンガープリントは、ポートがブロックされている場合と同じように表示上の障害になります。また、証明書を置き換えるたびに変わります。

最初のバックアップが権限エラーで失敗する。 アクセス制御エントリにはユーザーではなくトークンを指定し、ストレージが指す名前空間を対象にする必要があります。他の場所を調べる前に、Web インターフェースのデータストアの権限タブで両方を確認します。

ガベージコレクションを開始できない。 アクセス時刻の安全性チェックに失敗しています。ほとんどの場合、データストアのファイルシステムが noatime でマウントされています。findmnt -no OPTIONS /mnt/datastore/store1 を実行して確認し、/etc/fstab のオプションを修正してから再マウントします。この問題を回避するためにチェックを無効にしないでください。

データストアの容量だけが増え続ける。 prune ジョブは実行されますが、何も解放されません。ガベージコレクションのスケジュールが設定されていないか、バックアップ直後に実行されるため、毎回のコレクションが 24 時間の猶予期間内に入っています。proxmox-backup-manager datastore show store1 でスケジュールを確認します。

以前は短時間で完了していたバックアップに数時間かかる。 停止、移行、またはリストアされたゲストは dirty bitmap を失います。そのため、次回の実行ではアップロード量が少なくても、クラスタ側でディスク全体が読み取られます。タスクログには、アップロード量が少ない一方で長い実行時間が表示され、次の実行は再び高速になります。VPS 上のすべてのジョブが遅い場合、原因は通常データストアの外部にあります。最初にノイジーネイバーによる CPU steal time を測定します。

FAQ

Proxmox Backup Server の datastore は prune ジョブの実行後もなぜ増え続けるのですか？

prune は snapshot のメタデータ、つまり manifest、indexes、log、notes だけを削除するためです。chunks は、どの index からも参照されなくなったものを garbage collection が削除するまでディスクに残ります。proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' で datastore にスケジュールを設定し、datastore のパスに対して df -h を proxmox-backup-manager garbage-collection start store1 の前後で実行して確認してください。phase two では、access time が 24 hours and 5 minutes より古い chunks だけが削除されるため、少なくとも 1 日の遅延を見込んでください。

Proxmox Backup Server の VPS にはどの程度のディスク容量が必要ですか？

各 guest が実際に使用する容量を合計し、さらに各 guest の 1 日あたりの変更量に保持日数を掛けた値を加えてください。compression と deduplication が有効に働くため、この合計値は上限になります。indexes と作業領域として約 5 分の 1 を加え、購入可能な volume size に切り上げてください。最初の backup 前の見積もりは必ず実際とずれるため、2 週間後に datastore view の実使用量と照合して再確認してください。

backup encryption key はどこに保存すべきですか？

保護対象の cluster だけに保存することは避けてください。Proxmox VE は /etc/pve/priv/storage/<storage>.enc に保持しますが、これはすべての node に複製されるため、cluster とともに失われます。初日に別の場所へコピーし、proxmox-backup-client key paperkey で印刷して、そのコピーを別の建物で保管してください。また、この key は chunk digest の生成に使われるため、後から置き換えると次回の backup で全データが再度 upload されます。

Proxmox host ごとに 1 つの datastore が必要ですか。それとも namespaces を使うべきですか？

1 つの datastore に、source host または cluster ごとに 1 つの namespace を用意してください。deduplication は datastore 内で機能し、datastore 間では機能しません。そのため host ごとに分割すると、同じ base images が複数回保存されます。namespaces により backup groups を分離できるため、ID 100 の guest を持つ 2 つの host が衝突することはありません。また、/datastore/store1/pve-home 形式の access control path により、各 host の API token を自身の namespace に限定できます。

小規模な VPS で Proxmox backup server を運用できますか？

homelab であれば、通常は運用できます。chunking と hashing は backup server ではなく Proxmox VE node 側で実行されるためです。VPS は chunks の書き込みと、garbage collection および verification という 2 つの負荷の高いジョブを実行します。4 GB の RAM を割り当て、verification の thread count は低く抑えてください。両方のジョブを backup window の外にスケジュールしてください。それでもディスク性能から想定される時間を大幅に超える場合は、より高額な plan を購入する前に steal time を測定してください。

#proxmox #backups#offsite#deduplication#vps