Storage and Snapshots

Disks are where virtualization stops being abstract. Every clean demo stays easy right up until storage gets slow, full, or inconsistent.

The quiet truth is that most Proxmox opinions are really storage opinions wearing a virtualization hat.

Pick The Backend Before You Pick The Disk Format

The backend decides what features are native, what tradeoffs are acceptable, and what recovery will feel like later.

• Local storage is the fastest way to get moving on one box. It is also the fastest way to discover that host failure means everything important lived in one place.
• ZFS is popular in homelabs because it gives you snapshots, checksumming, compression, and a strong local storage story without bolting together extra layers by hand.
• LVM and LVM-thin are perfectly workable when you want simpler block-backed storage and do not need the full ZFS feature set.
• Network storage matters once backups, migration, or multi-node growth enter the picture.

The First Decision Is The Storage Layer

On file-based storage, you usually have a choice between raw and qcow2 images.

On block-backed storage such as LVM, ZFS, or Ceph, the story changes. Raw volumes are common there, and snapshot behavior often comes from the storage layer rather than from the VM image format itself.

That is why "qcow2 vs raw" is not a universal religious war. It depends on where the disk actually lives.

QCOW2 Vs Raw In Practice

QCOW2

QCOW2 is flexible. It supports thin provisioning, copy-on-write behavior, and convenient snapshot workflows on file-backed storage.

That makes it a strong fit for labs where rollback speed matters more than squeezing the last few percent out of storage throughput.

Raw

Raw is simpler and can be a little faster. On storage backends that already provide snapshots and thin allocation, raw is often the right answer because the backend is doing the heavy lifting.

Controller Choices Matter More Than People Expect

For modern Linux guests, Proxmox recommends VirtIO-based controllers for good reason.

The default that ages well is usually:

• VirtIO SCSI single
• IO Thread enabled for busy disks
• Discard enabled when the storage and guest support trim

IDE and other legacy controllers still exist mostly for compatibility work, imports, or very old guests.

Snapshots, Templates, And Backups Are Different Tools

Snapshot

A snapshot is a fast "let me come back here" point. It is perfect before risky changes.

It is not a real backup plan.

Template

A template is a reusable starting image. Use it when you want repeatable clones without reinstalling the OS every time.

Backup

A backup is for recovery after something genuinely bad happened: storage trouble, host failure, corruption, or your own impatience.

If the host disappears and your plan dies with it, that was never a snapshot problem. It was a backup problem.

That is why separate backup storage matters so much. If the copy lives on another pool, another box, or a dedicated backup target, the recovery story stops depending on the same failure domain that just let you down.

Copy-On-Write Is Why Snapshots Feel Instant

The reason snapshots are so useful is that they usually avoid copying the whole disk up front.

Instead, the base state is preserved and new writes are stored separately. That is why snapshots are quick and why leaving too many of them around quietly becomes its own storage problem.

Trim And Discard

If your storage supports thin provisioning, enable discard where it makes sense and make sure the guest can issue trim.

Otherwise guests will happily free space internally while the backend keeps believing the old blocks are still in use.

Guest Agent Helps Here Too

The QEMU Guest Agent is not just a convenience feature. It improves the storage story:

• better shutdown behavior
• filesystem freeze and thaw for consistent snapshot-style operations
• optional guest trim after some move or clone operations

That is especially useful once the lab stops being toy-sized.

A Storage Layout That Ages Well

I like fast local storage for active guests and separate storage for backups, archives, or bulk data.

Guest disks usually want low latency. Backup repositories and media libraries usually want capacity and separation. Those are different jobs, and giving them different homes keeps the platform easier to reason about.

If there is even a decent chance you will add another node later, it is worth thinking about shared or network-backed storage early. You do not need to build for a cluster on day one, but it helps to avoid painting yourself into a single-host corner by accident.

Continue Through The Series

• Proxmox Fundamentals — the higher-level reference on snapshots, templates, nodes, and migration.
• Networking Models — how those guests should join the LAN once their disks are in order.
• Resource Allocation — how to size CPU, RAM, and disk without starving the host.