Proxmox VE Storage and Backup Basics: A Practical Guide for Safe VM Operations

Introduction

Storage choices and backup discipline in Proxmox VE determine how safely you can run, modify, and recover virtual machines. This guide gives you a practical path to:

• Understand local-lvm, directory storage, and ZFS tradeoffs
• Map VM disks to storage backends and pick the right fit
• Use snapshots effectively before changes
• Verify backups and test restores before touching production VMs
• Run a safe single-node pilot before wider rollout

The goal is predictable changes and reliable recovery without surprises.

Workflow Overview

Follow these steps from inventory to safe change.

1) Inventory Current Storage and Health

Identify what you have and whether it is healthy.

Commands:

pvesm status
pvesm list local
pvesm list local-lvm

For LVM details (local-lvm uses LVM-Thin by default):

vgs
lvs -a -o+lv_size,lv_attr,lv_time,segtype,thin_count

For ZFS pool health:

zpool status
zpool list
zfs list -o name,used,avail,mountpoint

For filesystem capacity on directory storage (ext4/xfs):

df -hT

Checklist:

• Record free space, thin pool usage percentage, and ZFS pool health state
• Note any read/write or checksum errors (ZFS)
• Confirm TRIM/discard is enabled on underlying SSDs

2) Map VMs to Disks and Snapshots

Understand where each disk lives and what safety nets exist.

VM config and disk mapping:

qm config 100

Look for lines like:

• scsi0: local-lvm:vm-100-disk-0,size=40G
• scsi1: zfspool:vm-100-disk-1,size=200G
• sata0: local:iso/ubuntu-22.04.iso,media=cdrom

Existing snapshots:

qm listsnap 100

3) Choose the Right Storage for Each Role

Each backend has tradeoffs. Use a simple rule of thumb first, then tune.

Keep roles separate where possible:

• VM runtime disks on local-lvm or ZFS
• ISOs and templates on directory storage
• Backups on dedicated directory or ZFS dataset with enough capacity

4) Backups First, Then Changes

Backups are your safety net. Create, verify, and test before any risky action.

On-demand backup (snapshot mode where supported):

vzdump 100 --mode snapshot --compress zstd --storage backupdir

Scheduled backups (GUI):

• Datacenter → Backup → Add
• Select storage, schedule, and retention (prune rules)
• Prefer snapshot mode for minimal downtime

Verify and test-restore:

pvesm list backupdir | grep vzdump
qmrestore /var/lib/vz/dump/vzdump-qemu-100-*.vma.zst 200 --storage local-lvm --unique 1

Do test restores to a non-production VM ID (e.g., 200) on an isolated network. Verify the guest boots and the application responds — for a web server, confirm HTTP 200 on the expected endpoint.

5) Safe Disk Moves and Resizing

When moving or resizing, drain risk with snapshots and backups.

Create a pre-change snapshot:

qm snapshot 100 pre-change --description "before storage move"

Move a disk to another storage (plan downtime unless you have validated online move support for your storage combination):

qm stop 100
qm move_disk 100 scsi0 zfspool
qm start 100

Verify the move:

qm config 100
pvesm list zfspool | grep vm-100

Resize a disk safely:

qm stop 100
qm resize 100 scsi0 +20G
qm start 100

Then grow the filesystem inside the guest OS (e.g., resize2fs /dev/sda1 or xfs_growfs / depending on the guest filesystem).

Roll back if needed:

qm stop 100
qm rollback 100 pre-change
qm start 100

6) Operational Checks and Monitoring

• Capacity guardrails: keep at least 20% free on LVM-Thin pools and ZFS pools
• Health: check zpool status, lvs usage, and syslog for I/O errors daily
• Backup success: review daily job logs and prune results; alert on failures
• Change windows: schedule storage changes during maintenance windows only

Local Pilot Plan

Start small and measurable on a single node. Pick a non-critical VM or create a test VM.

Pilot objectives (example):

• Two successful snapshot-mode backups for the test VM
• One successful test restore to a new VM ID that boots and serves a basic check (e.g., HTTP 200)
• One successful disk move between storages with no data loss
• Collected timings for backup, restore, and move operations

Pilot steps:

Create a directory storage for ISOs/backups:

1. Prepare storage

   mkdir -p /mnt/backupdir
   # mount via /etc/fstab as needed, then add in Datacenter → Storage (type: Directory)

Optionally create a small ZFS pool (two SSDs in mirror) for testing:

   zpool create zfspool mirror /dev/nvme0n1 /dev/nvme1n1
   # add in Datacenter → Storage (type: ZFS or ZFS pool)

1. Baseline the VM

   qm config 100
   pvesm status

Ensure you have 20% headroom on target storage.

1. Snapshot and backup

   qm snapshot 100 pilot-start --description "pilot baseline"
   vzdump 100 --mode snapshot --compress zstd --storage backupdir

1. Test restore

   qmrestore /mnt/backupdir/dump/vzdump-qemu-100-*.vma.zst 200 --storage local-lvm --unique 1

Boot the restored VM (ID 200), isolate networking if needed, and run a basic service check (e.g., curl -I http://<ip> returns 200).

1. Disk move trial

   qm stop 100
   qm move_disk 100 scsi0 zfspool
   qm start 100

Verify the VM runs correctly, then remove any stale volumes on the source storage if not auto-cleaned.

1. Record results and decide

Capture:

• Durations for backup, restore, and move
• CPU and disk impact during operations
• Any errors or operator friction

Use these to set realistic RPO/RTO and schedule windows for production.

Conclusion

A safe Proxmox VE storage practice starts with clear roles for each backend, reliable backups, and small, measurable pilots. Keep VM runtime disks on local-lvm or ZFS, store ISOs and backups on directory or a dedicated dataset, and verify backups before any change.

Pre-change checklist:

• Recent successful backup exists and is test-restored
• A VM snapshot is created and documented
• At least 20% free space on source and target storage
• Storage health is green (pvesm status, zpool status, lvs)
• Maintenance window and rollback steps confirmed
• Post-change verification plan defined (boot, services, logs)

With these guardrails, you can evolve storage layouts, move or resize disks, and keep production VMs safe.