You just finished setting up your first VM in Proxmox VE, and it's running great. Then it hits you: if that disk dies tomorrow, everything is gone. No Proxmox Backup Server, no NAS, no cloud budget — just a spare USB hard drive sitting in a drawer. Good news: that drive is enough to get real, working backups going tonight.
This guide walks through plugging in a USB drive, formatting it correctly, and telling Proxmox VE to treat it as proper backup storage — the same vzdump engine used for Proxmox Backup Server, just writing to a drive sitting on your desk instead.
What You Will Learn
- How to identify, partition, and format a USB drive for Proxmox VE
- How to mount it reliably so it survives a reboot
- How to add it as backup storage without accidentally filling up your root disk
- How to create a scheduled backup job with sane retention
- The exact error messages you'll hit if any step goes wrong, and how to fix them
What Is This Feature?
Proxmox VE backs up VMs and LXC containers using a built-in tool called vzdump. It packages a guest's configuration and disk data into a single archive file — usually compressed with .zst — and drops it wherever you point it. Point it at Proxmox Backup Server and you get deduplication and incremental backups. Point it at a plain folder — including a folder on a USB drive — and you get a straightforward archive file per backup, no extra software required.
That plain folder is what Proxmox calls directory storage. It's the simplest storage type Proxmox VE supports: a path on disk, registered in /etc/pve/storage.cfg, that Proxmox is allowed to write VM disks, ISOs, or backups into. A USB hard drive, once mounted at a path like /mnt/usb-backup, is just another directory as far as Proxmox is concerned.
Why Would You Use It?
Proxmox Backup Server is the better long-term answer — it deduplicates data across backups, so a weekly full backup of a 32 GB VM doesn't actually cost you 32 GB every week. But PBS is its own installation, and for a lot of homelabs, a single Proxmox node with one or two VMs, that's overkill.
A USB drive gets you something that matters more than any of that: a copy of your data that lives on a device you can physically unplug and put in a different room. If your Proxmox host's boot disk fails, a backup sitting on the same machine's internal storage does you no good. One on a USB drive, updated last night, does.
It's also the cheapest possible starting point. A $40 external drive from three years ago is plenty for a couple of VMs and containers. You can always add Proxmox Backup Server later — nothing here locks you out of that.
Prerequisites
- A working Proxmox VE installation (8.x or 9.x — the steps here apply to both)
- Root or sudo access via SSH or the Shell console in the web UI
- A USB hard drive or SSD with enough free space for your backups — figure at least 2-3x the total disk size of what you're backing up, since you'll want more than one backup on hand
- A free USB port on the Proxmox host itself (not on a client machine — the drive needs to be physically connected to the server)
One thing worth deciding upfront: this guide formats the drive as ext4. If it currently has photos or files on it from a Windows or Mac machine, back those up elsewhere first — formatting wipes the drive.
Step-by-Step Tutorial
Step 1: Plug In the Drive and Find Its Device Name
Connect the USB drive to the Proxmox host, then open a shell (via SSH, or Datacenter → your node → Shell in the web UI) and run:
lsblkYou'll see a list of block devices. Your Proxmox boot disk is probably sda, and the USB drive will show up as the next letter — commonly sdb — with a size that matches the drive you plugged in. Note that exact name. If you're not sure which one it is, unplug the drive, run lsblk again, and see which entry disappeared.
Step 2: Partition and Format the Drive
If the drive is brand new or you're fine wiping it, create a single partition and format it as ext4. Replace sdb with whatever lsblk showed you — get this wrong and you'll format the wrong disk.
fdisk /dev/sdbInside fdisk: press g to create a new GPT partition table, then n to create a new partition, accept the defaults by pressing Enter three times, then w to write the changes and exit.
Now format that new partition as ext4:
mkfs.ext4 /dev/sdb1ext4 isn't the flashiest filesystem choice, but it's the right one here. It's well supported by the Linux kernel Proxmox runs on, handles large files (your backup archives) without drama, and doesn't have the permission quirks that NTFS and exFAT bring when Linux tries to write to them. Skip those two for this use case.
Step 3: Create a Mount Point and Find the Drive's UUID
Create a directory where the drive will live:
mkdir -p /mnt/usb-backupNow find the partition's UUID — a unique identifier that stays the same even if the drive gets assigned a different /dev/sdX name after a reboot (which happens more often than you'd expect, especially if you add or remove other USB devices):
blkid /dev/sdb1Copy the UUID value from the output. You'll use it in the next step instead of the device name.
Step 4: Mount It Automatically at Boot
Open /etc/fstab:
nano /etc/fstabAdd a new line at the bottom, using the UUID you copied:
UUID=your-uuid-here /mnt/usb-backup ext4 defaults,nofail 0 2The nofail option matters more than it looks. Without it, if this drive is ever unplugged when the server boots, Proxmox VE can hang at startup waiting for a mount that will never come. With nofail, the system just boots normally and skips the mount if the drive isn't there.
Save the file, then mount everything in fstab and confirm it worked:
mount -a
df -h /mnt/usb-backupYou should see your drive listed with its full capacity available.
Step 5: Add It as Storage in Proxmox VE
In the web UI, go to Datacenter → Storage → Add → Directory. Fill in:
- ID — a short name, like
usb-backup - Directory —
/mnt/usb-backup - Content — check only VZDump backup file (no need for ISO images or disk images here)
Before clicking Add, there's one setting hiding a real trap. By default, Proxmox's directory storage doesn't actually check whether /mnt/usb-backup is a real mounted drive or just an empty folder. If the USB drive ever gets unplugged or fails to mount, Proxmox will happily create the folder structure on your root disk instead and keep backing up there — silently — until your boot drive fills up and the whole host grinds to a halt.
The fix is a hidden option called is_mountpoint. You can't set it from the Add dialog, so add the storage first, then run this from the shell:
pvesm set usb-backup --is_mountpoint yesNow Proxmox VE will refuse to use that storage — and tell you clearly — if the USB drive isn't actually mounted, instead of quietly writing to the wrong disk.
Step 6: Create a Scheduled Backup Job
Go to Datacenter → Backup → Add. Set:
- Node — your Proxmox host (or "All" if you have a cluster)
- Storage — the
usb-backupstorage you just created - Schedule — for a homelab, once a night is usually plenty, e.g.
02:00 - Selection mode — choose specific VMs/containers, or "All"
- Mode — leave this on Snapshot if your storage supports it (it keeps the guest running during backup); use Stop only if you need maximum consistency and can tolerate a short downtime
Then set retention under the job's Retention tab. This decides how many old backups get kept before Proxmox prunes them automatically — without it, your USB drive fills up eventually and every backup after that fails. A reasonable starting point for a homelab:
| Setting | Value | What it keeps |
|---|---|---|
| keep-last | 3 | The 3 most recent backups, no matter what |
| keep-daily | 7 | One backup per day, for the last 7 days |
| keep-weekly | 4 | One backup per week, for the last 4 weeks |
Save the job. That's it — backups now run on their own.
Step 7: Run a Manual Backup and Test It
Don't wait until 2 AM to find out if this actually works. Pick a VM in the UI, click Backup in its sidebar, then Backup now, and select the usb-backup storage. Watch the task log — a small VM should finish in a couple of minutes.
Then do the part almost everyone skips: restore it. Go to the storage's Backups tab, pick the backup you just made, and click Restore into a new, throwaway VM ID. A backup you've never restored is a guess, not a backup.
Commands Explained
| Command | What it does |
|---|---|
lsblk | Lists block devices (disks and partitions) so you can identify the USB drive |
fdisk /dev/sdX | Opens the partitioning tool for the given disk |
mkfs.ext4 /dev/sdX1 | Formats a partition with the ext4 filesystem |
blkid | Shows the UUID and filesystem type of a partition |
mount -a | Mounts everything listed in /etc/fstab that isn't already mounted |
pvesm set <storage> --is_mountpoint yes | Tells Proxmox to only use this storage if the path is genuinely a mounted filesystem |
vzdump <VMID> | Runs a manual backup of a specific VM or container from the command line |
Common Errors
"unable to activate storage 'usb-backup' - directory is expected to be a mount point but is not mounted"
This is is_mountpoint doing exactly its job — the USB drive isn't currently mounted. Check that it's plugged in, then run mount -a and try again. Annoying in the moment, but far better than a silently failed backup.
Backup job fails with "no space left on device"
Either your retention settings aren't pruning old backups, or the drive genuinely doesn't have room for what you're backing up. Check df -h /mnt/usb-backup and tighten your keep-* values if needed.
The drive shows up as sdc instead of sdb after a reboot
This is exactly why Step 3 has you use the UUID in fstab instead of the device name. Device letters aren't guaranteed to stay the same between boots, especially with more than one USB device attached. UUIDs don't change.
Permission denied writing to the mount point
Usually means the drive was previously formatted and mounted with different ownership. Confirm it's actually ext4 (blkid will show the filesystem type) and that the mount point isn't still owned by a leftover user from a prior setup.
Troubleshooting
If a backup job silently stops appearing in the task log, check Datacenter → Backup and confirm the job's schedule hasn't been accidentally disabled — it happens more than you'd think when someone's clicking around the UI.
If the drive mounts fine manually but not on boot, double-check the fstab line for typos. A single wrong character in the UUID will make the mount fail silently at startup, and you won't notice until a backup job errors out hours later. Run mount -a right after editing to catch mistakes immediately instead of waiting for a reboot.
If backups are taking far longer than expected, it's often the drive itself — older USB 2.0 drives cap out around 30-40 MB/s, which turns a 20 GB VM backup into a 10-plus minute job. USB 3.0 drives on a USB 3.0 port are worth the upgrade if you're backing up more than a couple of guests nightly.
Best Practices
- Always set
is_mountpoint yeson removable storage — it's the single most common thing that saves people from filling up their root disk - Use UUIDs in
fstab, never raw device names like/dev/sdb1 - Set retention (
prune-backups) on day one, not after the drive fills up - Test a restore at least once — ideally right after setting the job up, and again every few months
- Rotate two USB drives if you can — keep one plugged in and one stored somewhere else, and swap them weekly. A backup that lives next to the server it's protecting doesn't help much if there's a fire or a theft
Frequently Asked Questions
Can I use exFAT instead of ext4?
You can, but I wouldn't. exFAT doesn't support Linux file permissions properly, and vzdump archives can exceed exFAT's practical file size handling on some setups. ext4 just works and avoids both problems.
Do I need Proxmox Backup Server for this to work?
No. Directory storage with vzdump works completely independently of PBS. PBS adds deduplication and incremental backups, but a USB drive backup is a real, restorable backup on its own.
How much space do I actually need?
Depends on your retention settings and how much of each VM's disk is actually used (vzdump backups compress and typically skip unused space). As a rough starting point, multiply your total used VM disk space by the number of backups your retention policy keeps, then add some headroom.
What happens if the USB drive fails?
You lose that copy of your backups, same as any other drive. This is exactly why a USB backup should be one layer, not your only layer — pair it with an offsite copy or a second rotated drive if the data actually matters.
Can I back up to the same USB drive I'm using for VM storage?
Technically yes, but don't. If that drive fails, you lose your VMs and your backups of them in the same event, which defeats the entire point.
Conclusion
None of this requires expensive hardware or a second server. A spare USB drive, ten minutes of setup, and a scheduled job get you from "no backups" to "automated nightly backups with retention" — which puts you ahead of a lot of homelabs out there. Set the is_mountpoint flag, use UUIDs, test a restore, and you've got a backup system that'll actually be there when you need it.