PBS 3.4 to PBS 4.x Migration Checklist Before August 2026

PBS 3.4 reaches end of life on August 31, 2026, closing both its security-patch window and its support contract. The outcome you are after is straightforward: move every backup, sync job, and tape archive off PBS 3.4 and onto PBS 4.x before that date, confirm each backup still restores, and retire the old server — without losing a single chunk. This checklist takes you through the move in order, starting with the datastore format that decides what is even possible.

Key Takeaways

• Format first: PBS 4.x reads PBS 3.4 backups without a format change, but the datastore upgrade command is effectively one-way, so verify everything before you commit.
• Use the migrator: Run pbs-migrate for a point-to-point move instead of hand-copying chunks and hand-editing datastore.conf.
• Repoint, then reboot: Updating /etc/pve/pbs.cfg is what actually repoints your VMs; copying data alone leaves backup jobs broken.
• Verify the last mile: A sync job that reports "completed" and a tape drive that shows "online" both still lie until you confirm the data exists and restores.

Why Does PBS 3.4's End of Life Matter for Your Backups?

PBS follows Debian's support model: each release gets three years, the first a full support cycle and the next two extended LTS (bug-fixes only). After August 31, 2026 your PBS 3.4 box stops getting security updates, and a backup server holding every VM's credentials and data is exactly the kind of box you do not want sitting unpatched and exposed.

The good news is that the data itself is not at risk. PBS has maintained backward compatibility across every major release — PBS 4.x will read the backups that PBS 3.4 wrote. So this migration is really about moving your workload to a supported, patched server, not about rescuing data from a dying format. If the basics of how the pieces fit together have blurred, the Automated Backups with Proxmox Backup Server article is a quick refresher before you start pulling levers.

How to Check Your Datastore Format Before Migrating

The datastore format is the gatekeeper. PBS stores backups in a binary format with a version number baked into each datastore, and PBS 4.x can read the format that PBS 3.4 produced. You can see the current format with the datastore info command on the PBS host:

$ pbs-datastore info /var/lib/pbs/datastore1
datastore: datastore1
uuid: 0a1b2c3d-4e5f-6789-abcd-ef0123456789
format: 2
total: 500000000000
used: 120000000000

The format: line is the one you are reading. In this example the datastore sits at format 2, which PBS 4.x reads without complaint. Before you trust a move, also run an integrity check so you are not chasing corruption mid-migration:

$ pbs-datastore check /var/lib/pbs/datastore1

Now the part people get wrong. The datastore upgrade command rewrites a datastore into the current format, and once you do that, older PBS versions generally cannot read the newer format:

$ pbs-datastore upgrade /var/lib/pbs/datastore1

Treat that upgrade as a commit, not a test. Verify everything on PBS 4.x first, and keep the PBS 3.4 server powered on until you are confident — upgrading the format on a datastore you have not yet proven works on 4.x is a reliable way to lose an upgrade weekend.

In-Place Upgrade vs Full Migration

The first decision is how far you move. Both paths reach PBS 4.x; they just cost different things.

Decision factor	In-place upgrade	Full migration to new hardware
Effort	Low — apt does most of the work	High — reconfigure clients, sync, and tape
Downtime	Minutes	Hours, depending on data size
Datastore format	Preserved as-is	Can upgrade to the current format
Risk	Low	Moderate — more moving parts
When to choose	Keep the same box, refresh the software	Retire the old server or move to better hardware

If your PBS 3.4 server is still healthy and fast enough, an in-place apt dist-upgrade to PBS 4.x is the lowest-risk option and it preserves your entire backup history. The catch is that you are only delaying the clock — the same server still hits August 31, 2026. If the hardware is aging or you want a clean slate, full migration is worth the extra work.

The PBS 3.4 to PBS 4.x Migration Checklist

Work through these in order. The goal is a PBS 4.x server that holds every backup and points your VMs at it cleanly.

1. Confirm the version and the date. Note the exact PBS 3.4 build before anything changes:

$ pbs --version
PBS server version 3.4-3

Write that build and the August 31, 2026 deadline against your calendar now so the deadline is concrete.

2. Inventory everything. List your datastores, clients, sync jobs, tape drives, and users. A quick pass over the Automate Proxmox VE: Essential Scripts for Homelab Backups, Health Checks & VLANs toolkit can pull this list for you instead of eyeballing the UI.
3. Run a restore test on PBS 3.4. Pick one representative VM and restore it now. If it fails today, it will fail after the move and you want to know before you start.
4. Pick your path. In-place or full migration, using the table above.
5. Move the data. For a full migration, run pbs-migrate from a Proxmox VE node for each VM:

pbs-migrate 101 --server pbs4.example.com:8007 --username root@pam --target datastore1

This transfers the VM's backups to the target datastore and updates the references so the VM knows where they live. Run it once per VM; skip one and that VM's history simply will not appear on the new server.

6. Repoint the clients. The actual repoint happens in /etc/pve/pbs.cfg on your Proxmox VE nodes, which the cluster syncs everywhere:

pbs-server pbs4.example.com
pbs-authkey "the-new-auth-key"

7. Verify and retire. Once every VM is on PBS 4.x and restores, then decommission PBS 3.4.

How to Verify Sync Jobs After Migration

Sync jobs are the ones that quietly break, because a job can "complete" while the target never actually received the chunks. If you offsite your backups, re-point the sync job at the PBS 4.x target and then confirm the target has the data, not just that the job reported success.

For a PBS-to-PBS sync, list the backups on the target server and compare against the source:

pbs backup 101

That lists the backups for VM 101 on the local (target) PBS. Read the listing against what the source should have sent. For an S3 offsite sync, check the bucket directly — the Configure Parallel Sync Jobs for S3 Offsite Backups guide covers the transfer statistics you want to eyeball. A sync job that reports success but shows an empty target is the classic silent failure, so always confirm on the receiving end.

One more detail: the sync user on the target needs the right permission, and a misconfigured sync user produces failures that look like network errors. Verify the sync user can list and read backups before you call the migration done.

Tape: The Step Most People Forget

Tape is where the upgrade weekend usually falls apart, because it lives in a different mental model than disk. PBS tape drives and their inventory are configured through the Backup Server web UI, and the inventory itself rides on the tape media — the index is written to the LTO cartridge, not stored on the server.

When you migrate, the tape drives are physical hardware, so you re-add them to the new PBS 4.x server in the Tape section of the UI. The old tapes still work: because the inventory is on the media, the new server reads the existing tapes without re-ripping anything. Before you pack the old server away, do a test restore from a tape to a scratch location and confirm the restore completes. If you skip that step, you will find out your tapes are unreadable on the new server at the exact moment you need them.

Gotchas That Ruin an Upgrade Weekend

• The datastore.conf name mismatch. When you copy a datastore by hand rather than using pbs-migrate, the datastore.conf file maps a datastore name to its path. If your new server calls the datastore something different, the VMs cannot find their backups. Match the name in datastore.conf before you reboot.
• Repoint before you reboot the old server. Updating /etc/pve/pbs.cfg is what repoints your VMs. Wipe PBS 3.4 first and your backup jobs break on the next run.
• The one-way format upgrade. The datastore upgrade command moves a datastore to the current format, and older PBS versions typically cannot read the newer format. Do it only after you have proven everything on PBS 4.x.
• Forget one VM in pbs-migrate. The migrator runs per VM. Skip VM 102 and its entire backup history disappears from the new server, even though the data is safe on the old one.
• Sync user without permissions. A sync user missing the read permission produces failures that look like network problems, not config problems.
• Assuming the tape inventory needs rebuilding. It does not — the inventory is on the media, so old tapes restore on the new server.

Conclusion

Migrating off PBS 3.4 before August 31, 2026 is really about moving your backups, sync jobs, and tape archives to a supported PBS 4.x server and proving each one restores — not about rescuing data, since PBS 4.x reads PBS 3.4 backups natively. Check the datastore format,