Manage Proxmox storage, visually
Storage on Proxmox is powerful but scattered: ZFS lives in one place, LVM in another, and what a disk is really doing lives on the command line. When a pool says degraded, the first questions are always the same: which disk, how bad, what now? This page covers two things: storage decisions that hold up on any setup, and how Atlas shows a disk from pool to data path on a single map.
Why storage gets confusing
The layers live on separate screens: physical disk, RAID/pool, dataset/LV, and the VM disk on top. To see which layer a problem lives in, four places have to be checked.
ZFS, LVM-thin or Btrfs? The decision made at install time is the hardest one to change later, and most guides spend one sentence on it.
Health is invisible: when did the last scrub run, why is the pool degraded, where is capacity heading? On most setups the answer arrives when something breaks.
A solid storage routine
Whatever filesystem is picked, these do not change:
Choose the layer deliberately: LVM-thin for a single disk and flexibility; ZFS for integrity, compression and snapshots.
Build redundancy from the start: the mirror/raidz decision is made at pool creation; converting later means moving data.
Put scrubs on a schedule (monthly is a good rhythm) and read the result; a scrub error is the early warning.
Take disk signals seriously: growing reallocated sectors are a disk’s goodbye letter; replace it before it fails on its own terms.
A snapshot is not a backup: it lives in the same pool and dies with it. Keep a copy on a separate device (e.g. PBS) for disasters.
Leave headroom: ZFS starts slowing past 80 percent; plan expansion before the pool fills.
Atlas puts storage on one map
Disk → pool → data path, on a single flow map:
Four layers, one screen
ZFS, LVM, Btrfs and mdadm in the same interface: pools, datasets, LVs and disks in one picture instead of separate tabs.
Pool creation wizard
A new pool, step by step: disk selection, redundancy, naming; what will happen is clear before it is applied.
Redundancy badges on the map
Every pool sits on the flow map with its badge (mirror, raidz, or single disk), so it reads at a glance instead of being memorized.
Dataset explorer
Walk the ZFS dataset tree: sizes, usage, which VM writes where.
Health is visible
Pool state (online/degraded) and capacity at a glance; when something is wrong, the map shows which layer it lives in.
Safe operations
Destructive steps (wipe, format) require explicit confirmation; what can be undone is honestly separated from what cannot, with no fake undo.
Frequently asked questions
- Should I pick ZFS or LVM-thin?
- LVM-thin is practical on a single disk with limited RAM. For integrity, compression and flexible snapshots, ZFS is the pick. ZFS likes RAM, but pays it back in integrity.
- My pool says degraded. What should I do?
- Stay calm: degraded means redundancy dropped; the data is still accessible. Identify the failed disk, replace it, avoid stressing the pool until the resilver finishes, and verify the backup against a second failure in the meantime.
- How often should a scrub run?
- Monthly is a common and sufficient rhythm for home and lab use. What matters is that it runs regularly and someone reads the result; scrubs are what catch silent corruption.
- Does a snapshot count as a backup?
- No. A snapshot lives in the same pool; if the pool or disk dies, the snapshot goes with it. Snapshots are for fast rollback, a copy on a separate device is for disasters.
- Where do I set up RAID on Proxmox?
- Without hardware RAID, the cleanest path is a ZFS mirror or raidz. mdadm works too, but with ZFS available it is usually an extra layer. Atlas exposes both paths in the interface.
- How full is too full for a pool?
- Treat 80 percent as the threshold on ZFS: past it, fragmentation and slowdown begin. If the pool is close, clean old snapshots first, then plan the expansion.
Related entries
- How to arrange the disks: mirroring or distributed parity The question is not which is faster. It is which failure you want to survive, and what the machine will be forced to do after that failure.
- Adding a disk and growing a pool: the step that quietly ends redundancy Adding a disk is two separate jobs: getting the system to see it, and deciding where it belongs. A mistake in the second can end redundancy for good.
- Orphaned disks: the question to ask before deleting You deleted the machine but the space did not come back. Leftover disks stay behind for three different reasons, and they are not the same. The list itself is a delete list, so its reliability is a separate matter.
- The disk is full: where the space went and what is safe to delete On a full storage the first move is not deleting but finding where the space went. Snapshots, old backups and orphaned disks are the three usual culprits, and deleting them does not carry the same risk.