Storage and backups

New in the next release

This is on the dev and qa builds now, and in the next release.

Storage fills differently from CPU and memory, and it's usually what runs out first. Besides the forecast, Ferrule explains where growth comes from, how backup stores will settle, and what adding disks would give.

Where storage growth comes from

The Where storage growth comes from panel compares the newest inventory with the one about a month before it, for each datastore:

Column	What it means
Grew	How much its used space changed, and over how many days
From VMs already there	Growth from VMs that existed a month ago getting bigger
From new VMs	Space taken by VMs that arrived since
Grew most	The three VMs that grew most, new ones marked
Snapshots	How many, and the oldest

A VM's used space is spread over the datastores its disks are on, in proportion to their sizes. It needs two inventories at least a week apart; until then only the snapshots column fills in.

So "datastore full in 40 days" comes with "and these three VMs are doing it."

Backup stores and retention

A Proxmox Backup Server datastore's row says what it keeps and how far along it is:

main Backup store · pbs1 keeps 7 daily, 4 weekly, 6 monthly (prune job daily-main) · retention 40% filled · 2.7× dedup

Where the policy comes from

In order:

1. A PBS prune job for that datastore (PBS 2.2 and later).
2. The datastore's own keep settings (older PBS).
3. A Proxmox VE backup job writing to it, when PBS sets none of its own. Many homelabs set retention on the PVE side: the backup job's Retention tab, or the PBS storage's. Ferrule reads both from any Proxmox VE source it watches, and matches the PBS datastore by server and datastore name, or by datastore name alone when only one matches.

The row says which it used. A storage set to keep all has no policy to fill. A disabled job doesn't count.

Filling, then level

A backup store grows until it holds everything its policy keeps, then levels off. Retention filled compares each backup group backed up in the last week with the snapshots its policy keeps for a group backed up daily. Groups not backed up for a week (a deleted VM's) aren't counted.

While retention is under 90% filled, a straight line through the history would forecast growth forever. So the row is amber, and the forecast note and any runway alert say the date may be early, because growth slows as retention fills.

Deduplication

The ratio is the data the backups hold over the space they take on disk, from the datastore's last garbage collection. When it can't be read, the row says why. Usually the token lacks the Audit role on that datastore, or garbage collection has never run.

NAS backup shares have no retention Ferrule can read; they get the plain disk forecast.

Pool layouts

The add-disks what-if needs each pool's layout. Each NAS reports what it can:

Source	Layout read
TrueNAS	Each data vdev's type (RAIDZ1/2/3, MIRROR, a single disk), how many disks wide, and its smallest disk. Cache, log and spare devices aren't counted. Disks installed but in no pool are counted as spare.
Synology	The storage pool's RAID type (SHR, SHR-2, RAID 5, 6, 10, 1, Basic) and the sizes of the disks in it
QNAP	The volume's RAID level, and empty bays
Proxmox VE, Ceph	The OSD count, and so the average OSD size; replicas taken as three, Proxmox VE's default

A layout Ferrule doesn't recognise says so instead of guessing.

Thin provisioning

A datastore's Disk row forecasts what's really used. Its Disk provisioned row adds up every VM disk's full size, thin or not, against capacity × 1.5 by default (CAPACITY_RATIOS disk=). A datastore can be 60% used and 140% provisioned: fine until the thin disks fill. See forecasts.