Every disk-based backup strategy shares the same weakness: it is still online. A datastore on spinning rust, an SSD array, or even an air-gapped S3 bucket is reachable from the network that a ransomware payload or a misbehaving script is also running on. Tape does not have that problem. A cartridge sitting in a fireproof safe three buildings away cannot be encrypted by malware, cannot be silently corrupted by a bad ZFS pool, and cannot be deleted by an attacker who has compromised your admin account. That is why, even in 2026, tape remains the backbone of long-term retention for regulated industries, managed service providers, and homelab users who take the 3-2-1 backup rule literally.

Proxmox Backup Server (PBS) has shipped native tape backup support for several release cycles now, built directly into the web interface and the proxmox-tape command-line tool. It is not a bolt-on script — it understands media pools, retention policies, encryption, and cataloged restores the same way it understands disk datastores. This guide walks through the entire process: from detecting your tape hardware, to labeling your first cartridges, to running a tape backup job and restoring a VM straight from tape.

How Tape Backup Fits Into the PBS Architecture

Before touching any hardware, it helps to understand where tape sits in the backup chain. A PBS tape backup job does not back up your Proxmox VE guests directly. Instead, it reads existing snapshots that are already stored in a PBS datastore and streams them to tape. In other words, tape is a second tier: your VMs and containers back up to a disk-based datastore as usual (deduplicated, compressed, verified), and a separate tape job then copies selected snapshots from that datastore onto cartridges for offline, long-term, or offsite retention.

This two-tier design matters for planning. You still need a working PBS datastore with regular backup jobs before tape becomes useful — tape is not a replacement for your primary backup target, it is the archival layer on top of it. If you haven't set up a datastore yet, do that first; this guide assumes a functioning PBS instance with at least one datastore already receiving backups from Proxmox VE.

Supported Hardware

PBS talks to tape hardware over the standard SCSI Stream Commands (SSC) and SCSI Medium Changer (SMC) protocols, so compatibility is broad rather than tied to a specific vendor list:

  • Drive generation: LTO-5 and newer are fully supported. LTO-4 works on a best-effort basis — some LTO-4 hardware needs a firmware update or lacks a feature PBS relies on, so test before relying on it in production.
  • Standalone drives vs. libraries: A standalone drive works for small environments where you swap a single cartridge by hand. A tape library (autoloader) adds a robotic changer that can hold and shuffle multiple cartridges without operator intervention, which is what most production setups use.
  • Connectivity: Tape hardware is almost always attached via SAS or Fibre Channel HBA. USB-attached drives exist but are rare in server contexts and not recommended for anything beyond testing.
  • Virtual tape libraries: If you don't have physical hardware yet, Proxmox documents how to stand up a virtual tape library (VTL) using software like mhvtl for testing the entire workflow before buying real drives.

Step 1: Getting Tape Hardware Visible to PBS

If Proxmox Backup Server runs on bare metal, the SAS/FC HBA and everything attached to it will simply show up under the Linux SCSI subsystem. If, like a lot of homelab and MSP setups, PBS runs as a virtual machine inside Proxmox VE, you need to pass the physical HBA controller through to that VM — passing through the tape drive alone rarely works cleanly because changers and drives typically share a controller and need to be presented as a unit.

To pass through the HBA:

  1. Confirm IOMMU is enabled in the BIOS and on the kernel command line (intel_iommu=on or amd_iommu=on).
  2. Identify the HBA's PCI address with lspci -nn | grep -i sas (or fibre for FC cards).
  3. Check that the HBA sits in its own IOMMU group with find /sys/kernel/iommu_groups/ -type l | grep <pci-address>. If it shares a group with unrelated devices, you may need the pcie_acs_override kernel parameter, understanding the tradeoffs that come with it.
  4. Add the device to the PBS VM via Hardware → Add → PCI Device in the Proxmox VE UI, selecting "All Functions" and enabling "PCI-Express" if the card supports it.
  5. Boot the PBS VM and confirm the OS sees the controller with lspci inside the guest.

Once the controller is visible, scan for tape devices:

# List detected tape changers
proxmox-tape changer scan

# List detected tape drives
proxmox-tape drive scan

Both commands return the SCSI path (for example /dev/tape/by-id/scsi-...) that you will use when registering the device in PBS. If nothing shows up, double check cabling, that the changer/drive is powered on, and that the kernel loaded the st (SCSI tape) and sg (SCSI generic) modules — run lsmod | grep -E 'st|sg' to confirm.

Step 2: Registering the Changer and Drive in PBS

With the hardware detected, register it through the web UI under Tape Backup in the left-hand menu, or via CLI.

Via the UI:

  1. Navigate to Tape Backup → Changers and click Add. Give it a name and select the detected SCSI path.
  2. Navigate to Tape Backup → Drives and click Add. Select the drive's path and, if it lives inside a library, associate it with the changer you just created.

Via CLI, the equivalent commands are:

# Register a changer
proxmox-tape changer create lib0 --path /dev/tape/by-id/scsi-XXXXXXXX-sg

# Register a drive tied to that changer
proxmox-tape drive create drive0 --path /dev/tape/by-id/scsi-YYYYYYYY-nst --changer lib0

Verify PBS can talk to the hardware end to end:

proxmox-tape status --drive drive0
proxmox-tape changer status lib0

The changer status output lists every slot, whether it's occupied, and which slot (if any) is currently loaded into the drive — useful for confirming your library's slot numbering before you start loading cartridges for real jobs.

Step 3: Creating a Media Pool

A media pool is a logical container that groups a set of tapes and defines the rules PBS uses to write to and reuse them. Every tape backup job targets exactly one media pool, and a job will only ever read from or write to tapes that belong to that pool. Create one under Tape Backup → Media Pools → Add, or via CLI:

proxmox-tape pool create offsite-weekly \
  --allocation "3600@0/0..6" \
  --retention 8w

Two settings define the pool's behavior:

  • Allocation policy controls when a backup job is allowed to start writing to a fresh tape instead of continuing to append to the currently loaded one. You can set it to always continue on the current tape, always start a new tape per job, or use a calendar event (for example, a new tape every Monday) so that each rotation cycle gets its own physical cartridge.
  • Retention policy controls how long PBS protects a tape from being overwritten once it's full or its allocation period ends. A tape under retention cannot be reused for a new backup job even if you try to force it, which is your main safety net against accidentally erasing an archive you still need.

Most environments run more than one pool — for example a daily-onsite pool with a short retention that recycles tapes weekly, and a monthly-offsite pool with a much longer retention (or "keep forever") for cartridges that leave the building for cold storage.

Step 4: Labeling Tapes

Every cartridge that PBS writes to must be labeled first — this writes an identifying header to the tape and, if barcodes are in use, associates the physical barcode with PBS's internal record. If your library reads barcodes automatically, PBS will pick them up during an inventory scan; if you're hand-labeling a standalone drive, use an 8-character Code 39 label, matching the LTO Ultrium Cartridge Label Specification.

Label a tape and assign it to a pool:

proxmox-tape label --drive drive0 --pool offsite-weekly --label-text OFFW0001

For a library, run an inventory pass so PBS reconciles what it thinks is in each slot with what's physically loaded:

proxmox-tape changer inventory lib0

Do this labeling step for every cartridge you plan to rotate before scheduling your first job — running out of labeled, pool-assigned media mid-rotation is the single most common reason a scheduled tape job fails silently overnight.

Step 5: Creating a Tape Backup Job

With drive, changer, and at least one labeled tape in place, create the job itself under Tape Backup → Backup Jobs → Add:

  • Source datastore — the PBS datastore whose snapshots this job will copy to tape.
  • Drive and Media Pool — the hardware and tape group this job writes to.
  • Schedule — a standard PBS calendar event, for example sat 22:00 for a Saturday night offsite run.
  • Export group filter (optional) — restrict the job to specific backup groups (namespaces, VM IDs, or container IDs) rather than the entire datastore, useful when only a subset of workloads needs tape-tier retention.
  • Notification target — reuse any notification endpoint you already have configured (email, Gotify, or a generic webhook), so a failed or degraded job doesn't go unnoticed.

The equivalent CLI job creation looks like this:

proxmox-tape backup-job create offsite-weekly-job \
  --store main-datastore \
  --pool offsite-weekly \
  --drive drive0 \
  --schedule "sat 22:00" \
  --notify-user root@pam

Run a manual test before trusting the schedule:

proxmox-tape backup offsite-weekly-job

Watch the task log in the UI (Tape Backup → Backup Jobs → Log). A healthy run shows PBS loading the correct tape, writing each backup group, updating the catalog, and — if the pool's allocation policy calls for it — ejecting the tape at the end so an operator (or the library's autoloader) can move it offsite.

Step 6: Understanding the Catalog

Every time PBS writes to a tape, it records a catalog entry describing exactly what's on it: which datastore, which backup groups, which snapshots, and their position on the tape. This catalog is what makes restores fast — PBS doesn't need to shuttle through an entire cartridge to find one VM's backup; it consults the catalog, seeks to the right position, and streams only what's needed. Catalogs live on the PBS host itself, not just on the tape, so a full local catalog rebuild (proxmox-tape catalog) is only needed if you're importing tapes from another PBS instance or recovering from a lost catalog database. Keep a note of this: if you ever rebuild PBS from scratch after a disaster, restoring the tape catalog is a required step before you can browse and restore individual snapshots from your offsite tapes.

Step 7: Restoring From Tape

Restores happen through Tape Backup → Content, or from the CLI, and come in two flavors:

  • Single snapshot restore — pull one VM or container's backup off tape and back into a PBS datastore, from which you restore into Proxmox VE exactly as you would any disk-based backup.
  • Full tape restore — restore every backup group cataloged on a given tape back into a datastore, typically used for disaster recovery scenarios where the original datastore is gone entirely.
# Restore everything on a specific tape into a datastore
proxmox-tape restore OFFW0001 main-datastore

# Restore a single backup snapshot from tape
proxmox-tape restore-snapshot OFFW0001 vm/100/2026-07-10T22:00:00Z main-datastore

Once the snapshot lands back in a datastore, restoring the actual VM or container into Proxmox VE uses the same restore workflow as any other PBS-backed snapshot — nothing tape-specific happens at that final step.

Encrypting Tapes That Leave the Building

A cartridge riding in someone's car to an offsite storage facility is a physical device that can be lost or stolen, so encryption matters more for tape than for a datastore sitting behind your firewall. PBS supports encrypting tape backups with a key independent from any datastore encryption key you may already use.

Generate and register a tape encryption key, then attach it to a media pool so every tape written to that pool is encrypted automatically:

proxmox-tape key create --hint "offsite-2026"
proxmox-tape pool update offsite-weekly --encryption-key <key-fingerprint>

Back up the resulting key file somewhere other than the PBS host itself — if you lose both the host and the key, every encrypted tape becomes permanently unreadable. Print the recovery key and store it in the same physical safe as your most sensitive documents, not in a password manager entry that depends on infrastructure the tape backup exists to protect you from losing.

Media Rotation and Retention Strategy

PBS gives you the mechanics; you still need a rotation policy. A common, well-tested approach is Grandfather-Father-Son (GFS):

  • Son — daily or weekly tapes, short retention, recycled quickly.
  • Father — one tape per month, kept for a year.
  • Grandfather — one tape per year, kept for as long as compliance requires (often five to seven years, sometimes indefinitely).

Map this onto separate media pools with matching retention policies (for example daily-son, monthly-father, yearly-grandfather), each with its own allocation calendar, so PBS enforces the rotation instead of relying on a human to remember which cartridge is safe to overwrite. For ransomware resilience specifically, physically eject and store grandfather/father tapes offline and offsite — a tape sitting in a drive or an online slot in the library is not meaningfully different from a networked disk in terms of attack surface.

Monitoring and Notifications

Tape jobs fail in ways disk backups don't: a jammed changer, a dirty tape head throwing read/write errors, a cartridge left in the wrong slot, or simply running out of labeled media for the night's rotation. Configure notification targets on every tape backup job so failures surface immediately rather than being discovered during an actual restore attempt — which is the worst possible time to learn a job has been silently failing for three weeks. PBS's tape job history also tracks per-tape write counts and error rates, worth a periodic glance to catch a drive or cartridge that's degrading before it fails outright.

Troubleshooting Common Issues

Drive or changer not detected after passthrough

Confirm the HBA is bound to the host driver inside the VM, not still claimed by vfio-pci on the Proxmox VE host. Check dmesg | grep -i lto and dmesg | grep -i "scsi.*changer" inside the guest for enumeration errors, and confirm the st and sg kernel modules are loaded.

"Tape is write protected" errors

Most LTO cartridges have a small physical write-protect tab. Verify it's set to the unlocked position — this is by far the most common cause of this error and is easy to overlook when reusing cartridges.

Catalog out of sync with the tape's actual contents

This can happen if a tape was written to by a different PBS instance or if the catalog database was restored from an older backup. Run a catalog rebuild against the specific tape (proxmox-tape catalog <label>) to re-read its contents directly and regenerate an accurate local record.

Changer times out mid-job

Robotic changers can take longer to complete a load/unload cycle under load or as they age. If jobs intermittently fail during tape swaps, check the library's own diagnostic logs for mechanical errors before assuming it's a PBS-side issue — a changer reporting slow or failed moves is often a maintenance problem, not a software one.

Backup job skips tape and falls back to no tape available

Confirm the media pool actually has a tape in "free" state — a pool where every tape is either under retention or full will stall the job waiting for you to insert new media. Check proxmox-tape pool show <pool> to see the state of every tape currently assigned to it.

Frequently Asked Questions

Do I still need a disk-based PBS datastore if I use tape?

Yes. Tape backup jobs in PBS copy from an existing datastore; they don't back up Proxmox VE guests directly. Tape is an archival tier on top of your normal disk-based backups, not a replacement for them.

Can I use a USB LTO drive instead of SAS or Fibre Channel?

Technically yes for a single standalone drive, but it's uncommon in production because USB doesn't reliably handle the sustained throughput and command set that autoloaders and heavy write workloads need. SAS or FC is the standard for anything beyond casual testing.

What happens if I lose the tape encryption key?

Any tape encrypted with that key becomes permanently unreadable — there is no recovery path built into PBS for a lost key. Store the exported key file (and its printed recovery sheet) somewhere independent of the PBS host and the tapes themselves.

Can PBS write to more than one tape drive at once?

Yes, if you have multiple physical drives (common in larger libraries), you can register each as a separate drive and run independent backup jobs against them concurrently, which shortens the backup window for large datastores.

How do I test the whole workflow without buying tape hardware?

Proxmox documents setting up a virtual tape library using software such as mhvtl, which emulates SCSI tape drives and changers on disk. It behaves identically from PBS's point of view, making it a practical way to validate your media pool and job configuration before hardware arrives.

Conclusion

Tape's reputation as legacy technology undersells what it actually does well: it is the one backup medium that can be physically disconnected from every network your infrastructure touches, which is precisely the property that defeats ransomware, insider threats, and cascading storage failures that a purely disk-based strategy can't fully protect against. Proxmox Backup Server's native tape support means you don't need a separate, bolted-on backup product to get there — media pools, retention policies, encryption, and cataloged restores are all handled inside the same tool you're already using for disk backups. Once your drives are detected, your pools are defined, and your first cartridges are labeled, tape backup becomes just another scheduled job — one that happens to produce an archive nothing on your network can touch.