## 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.

<div class="my-stack-md overflow-x-auto">
<table class="w-full min-w-[42rem] border-collapse text-left">
<thead><tr><th scope="col" class="border border-outline-variant bg-surface-container-low px-4 py-3 text-left font-label-md font-semibold text-on-surface">Backend</th><th scope="col" class="border border-outline-variant bg-surface-container-low px-4 py-3 text-left font-label-md font-semibold text-on-surface">Pros</th><th scope="col" class="border border-outline-variant bg-surface-container-low px-4 py-3 text-left font-label-md font-semibold text-on-surface">Cons</th><th scope="col" class="border border-outline-variant bg-surface-container-low px-4 py-3 text-left font-label-md font-semibold text-on-surface">Good For</th></tr></thead>
<tbody><tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant"><strong>local-lvm</strong> (LVM-Thin)</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Fast allocation, storage-layer snapshots, simple ops</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Not human-readable files; resize/migrate steps differ from file storage</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">General-purpose VM disks on single-node or small clusters</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant"><strong>Directory</strong> (ext4/xfs)</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">File-level access, easy standard-tool backup, good for ISOs/templates</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Snapshot capability depends on image format; filesystem overhead under heavy I/O</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">ISOs, templates, backup targets, light VM disks, PBS datastore mountpoints</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant"><strong>ZFS</strong> (datasets/zvols)</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Checksums, snapshots, clones, send/receive; strong integrity</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">RAM-hungry; needs write cache/sync tuning</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">VMs needing higher integrity, easy snapshots, replication workflows</td></tr></tbody>
</table>
</div>
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:

- 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) 

- Baseline the VM

 qm config 100
 pvesm status 
 Ensure you have 20% headroom on target storage.

- Snapshot and backup

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

- 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).

- 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.

- 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.