RAID, snapshots, thin provisioning, TRIM · Proxmox VE

Why this matters in production

Four common misconceptions cause most storage-related production incidents:

“RAID is a backup.”
“Snapshots are a backup.”
“Thin provisioning is free.”
“SSDs don’t need TRIM.”

Each is wrong in a specific, dangerous way. This lesson clarifies all four.

RAID protects against disk failure. Not against anything else.

RAID (redundant array of independent disks) mirrors or stripes data across multiple disks so that one (or more, depending on the level) disk failures do not cause data loss.

RAID does not protect against:

File deletion (operator mistake).
Ransomware or other malicious activity.
Software bugs that corrupt files.
Site loss (all disks in the same rack).
Controller failure that takes the whole array down.
Bit-rot (silent data corruption) — ZFS detects this; hardware RAID typically does not.

Snapshots are not backups.

A snapshot is a point-in-time reference to a filesystem’s state. It usually takes no additional storage initially (copy-on-write); space is consumed as the live data diverges from the snapshot.

Snapshots protect against:

An upgrade that goes wrong (rollback to the pre-upgrade snapshot).
A bad configuration change (rollback to the pre-change snapshot).
“What did this file look like last week?” forensic questions.

Snapshots do NOT protect against:

Disk failure (a snapshot lives on the same disk as the data).
Site loss (same failure domain).
Ransomware that corrupts the snapshots too.
Long-term retention (snapshots grow as data changes).

Thick vs thin provisioning

Provisioning	What it is	Trade-off
Thick (eager-zeroed)	Allocate full size up front; zero all blocks	Best performance; size committed immediately
Thick (lazy-zeroed)	Allocate full size up front; zero on first write	Performance similar to eager-zeroed after first write
Thin	Allocate on demand; grow as data is written	Capacity savings; risk of “out of space” surprise

lvs -a -o lv_name,lv_size,pool_lv,data_percent,lv_metadata_percent | head -20

zpool list -o name,size,alloc,free,capacity,health

TRIM / discard

SSDs write in 4 KB pages but erase in 256 KB or larger blocks. After many writes, deleted pages still consume erase blocks until TRIM tells the SSD they are free.

Without TRIM:

Write amplification increases over time.
Performance degrades after sustained writes.

With TRIM:

Guest OS issues fstrim (or continuous discard).
Hypervisor passes the discard to the host.
Host passes it to the SSD.
SSD reclaims the blocks, restoring performance.

Enable discard at three levels:

VM disk (scsi0: ...,discard=on) — the VM guest sees discard support.
Guest filesystem — fstrim.timer enabled (systemd), or mount -o discard (not recommended for performance).
Host storage — ZFS understands TRIM automatically; LVM thin needs issue_discards=1.

systemctl enable --now fstrim.timer

Production considerations

Common mistakes

Treating RAID as a backup.
“I have a snapshot, so I’m safe.” No — snapshots and backups are different things.
Running a thin pool without monitoring. Surprise: it’s full.
Disabling TRIM “to save CPU.” The SSD performance cost is worse than the CPU savings.

Key takeaways

RAID protects disks; not files, not sites.
Snapshots are for short-term rollback; backups are for everything else.
Thin provisioning is great until the pool is full.
TRIM is mandatory for SSD performance over time.