2026 Proxmox Backup Server 4.2 Datastore Full: Clean Up or Expand First?

PBS 4.2 was released on April 29, 2026, according to the official release announcement. If your datastore looks full, do not delete chunk files or expand storage on the strength of one screen alone. First check whether prune and garbage collection (GC) ran as expected, then compare the PBS datastore view with the underlying storage’s actual usage. If maintenance cannot run or the backend is genuinely short of space, use a recovery path appropriate to that backend before changing data or capacity.

This week: preserve task logs, confirm the storage type and mount, and decide whether you are fixing a job, correcting retention, or addressing real capacity pressure.

This guide is for administrators running a standalone PBS instance whose datastore keeps growing.
It is also for MSPs responsible for backup policies and alerts across customer environments.
Small hosting operators managing storage for multiple tenants can use it to separate incident handling from capacity planning.

Last updated October 28, 2026. Version and storage guidance checked against the PBS 4.2 release information and the official maintenance and storage documentation.

Start by separating snapshot retention from disk usage

A snapshot list, a deduplication figure, and filesystem free space describe different things. Don’t treat them as interchangeable measures of space you can recover.

Prune applies a retention policy to snapshots. Removing a snapshot does not necessarily remove every chunk it used: chunks can remain necessary for other backups. GC is a separate maintenance task that identifies chunks no longer referenced and reclaims them. The PBS maintenance documentation describes these functions; use it rather than assuming a particular amount of space will be reclaimed.

That distinction answers a common operational puzzle: backups can disappear from the visible snapshot list while the filesystem still appears full. It may mean GC has not run, has failed, or has not found unreferenced chunks to reclaim. It may also mean the storage is being used by other data or by another datastore. The symptoms alone do not identify the cause.

A high deduplication value is not a free-space forecast either. It describes how data is shared in the backup store, not how much space an upcoming prune or GC run will certainly return. Treat reclaimable space as unknown until maintenance has completed and the backend reports its current capacity.

For a standalone administrator: verify the jobs before changing storage

Start with the PBS task history and the maintenance schedule. For each relevant prune and GC task, record its last result, completion state, error text, and datastore. A schedule that exists in configuration is not proof that its job completed successfully.

Then compare two views:

• In PBS, inspect the datastore and its task history. Check whether the intended retention policy is attached to the correct backup groups and whether the relevant maintenance jobs completed.
• On the host, inspect the filesystem or storage pool that actually contains the datastore. For a mounted filesystem, use findmnt -T /path/to/datastore to identify the mount and df -hT -- /path/to/datastore to see its type and available space. Replace the example path with the real datastore path. These checks show the backend’s state; they do not diagnose which PBS job caused it.

If the datastore is on ZFS, distinguish the dataset’s reported usage and available space from pool capacity; use the ZFS tools and documentation that match your local layout. If it is backed by S3, inspect the datastore’s documented capacity view and the object-storage account’s bucket and quota information. Don’t apply filesystem commands to an object-store backend as if it were a local mount. PBS lists its supported storage arrangements and their relevant constraints in the storage documentation.

If the result is unclear, preserve the task logs and the before-change output. Avoid cleanup until you know whether the issue is retention, a failed job, a full mount, a constrained pool, or an external storage limit.

For an MSP: keep diagnosis separate from customer-data changes

When you manage multiple customer environments, first identify which datastore and customer policy are involved. A shared operational view can hide different causes: one customer’s prune task may not have run, another may have an incorrect retention policy, and a third may be approaching the limit of the underlying storage.

Keep the following evidence with the incident:

• Datastore and customer or tenant identifier.
• Prune and GC task results, including error details and completion status.
• The configured retention policy and the backup groups it is intended to cover.
• The PBS datastore view and the matching filesystem, pool, or object-store capacity view.
• The change approval, maintenance window, and the person who authorized any destructive or capacity-changing action.

Do not use a cleanup action intended for one customer’s backup policy against a shared datastore without confirming its scope. A policy change can affect what remains available for other customers. If you can’t establish ownership or expected retention, pause the change and get confirmation from the responsible customer contact.

A community thread dated September 22, 2026, discusses a full-disk case, but it is an individual report, not proof of a general PBS 4.2 defect. You can review the community discussion as a case report, but keep its suggestions separate from the official maintenance guidance. A post or reply does not establish that the same root cause applies to your environment.

For a small hosting operator: identify the storage boundary

Before assigning responsibility or changing capacity, establish exactly where the datastore lives and which limit is binding. PBS’s datastore information is only one part of the picture; the backend may have its own capacity, quota, pool, or mount constraints.

For ext4 or XFS, confirm the mount that contains the datastore and check free space on that mount. A directory’s apparent size is not a substitute for checking the filesystem that can accept writes. For ZFS, check both the relevant dataset and its pool: a dataset may have its own constraints even when the pool view looks different. For an S3 datastore, check the object-store capacity and any applicable account or bucket limits through the documented backend controls. Match each check to the storage type rather than applying one generic “disk full” procedure.

Don’t manually remove, move, or rename files under .chunks. That bypasses PBS’s knowledge of references and can damage recoverability. Don’t turn a forum command into a standard operating procedure unless the official documentation explicitly supports it for your PBS version and backend. Before a risky change, confirm that you have a separate usable backup or another documented recovery route, schedule a maintenance window, and record how you will reverse the change if validation fails.

For exact PBS command syntax, use the official command reference for your installed version. Do not copy a command from another release or backend without checking its scope and effect.

Follow this response order for the condition you actually found

The next action depends on the evidence, not on whether the interface simply says “full.” Use the table to select a diagnostic path; it is not a promise that a particular action will free a particular amount of space.

If the task failed, treat the error as evidence, not as permission to delete data. If the backend is full, determine whether adding capacity is supported without changing the datastore’s expected layout. If you cannot verify the storage boundary or recovery route, stop before a destructive operation and consult the relevant PBS documentation or your storage provider’s procedures.

Use a checkable sequence before you close the incident

• [ ] Record the datastore name, backend type, mount or pool, and the PBS version shown in your environment.
• [ ] Review the prune and GC schedules, then inspect their most recent task results and error details.
• [ ] Confirm that the retention policy covers the intended backup groups and matches the approved customer or service policy.
• [ ] Compare PBS’s datastore state with the filesystem, ZFS pool and dataset, or S3 capacity view that actually limits writes.
• [ ] Save the before-change task logs and capacity output. Keep them with the incident record.
• [ ] Before a risky change, confirm a separate usable backup or recovery method, obtain approval where required, and schedule a maintenance window.
• [ ] Make only the documented change that addresses the diagnosed cause. Never manually delete .chunks.
• [ ] Rerun the relevant maintenance task and review its complete result.
• [ ] Confirm that PBS and the backend report the resulting state, then check that the next scheduled backup completes.

A successful cleanup or expansion is not verified just because an error disappears. Confirm both the maintenance task result and the storage view, then check subsequent backup activity. If the next backup fails, reopen the diagnosis rather than assuming the capacity issue is resolved.

Plan capacity from retention and observed growth

Once service is stable, estimate future requirements from your own backup history and retention rules. Don’t extrapolate a growth rate or expected space recovery from a single community report. Track how the datastore changes over time, account for the data you retain, and plan operating headroom around the workload and backend limits you actually observe.

When deciding whether to extend a datastore or use a separate backup target, consider the current storage layout, failure boundaries, backup traffic, and how you would restore data if the primary environment were unavailable. An extra disk in the same server is not automatically an independent backup: it may share the same host, power, or operational failure. Keep an off-machine backup plan where your recovery requirements call for one.

If you are planning a dedicated backup host, map your measured retention needs to the disks, redundancy approach, and bandwidth you actually require. OVN Cloud’s current server configuration options are the place to confirm available hardware; use the current product information rather than assuming a particular capacity or price. Also check the service boundaries: renting a server provides a host to operate, not a managed PBS backup service.

FAQ

Why can the disk remain full after PBS deletes backups?

Prune removes snapshots according to retention rules, but the chunks they referenced may still be needed by other snapshots. GC then identifies chunks that are no longer referenced and reclaims them. Review both task results and compare the datastore view with the actual backend capacity. Don’t use the visible snapshot list alone to predict reclaimable space.

How do prune and GC differ?

Prune applies retention rules to backup snapshots and removes those that no longer qualify. GC operates on the underlying chunk store and can reclaim chunks only when they are no longer referenced. They are separate maintenance jobs, so a successful prune does not prove that filesystem space has been returned.

Should you clean up or expand a nearly full datastore?

First confirm whether prune and GC ran as expected, inspect their task logs, and identify the backend. If retention is wrong or maintenance failed, address that cause first. If the backend is genuinely short of space, plan a supported expansion or separate target, with an understood recovery path. Avoid assuming that cleanup will free enough space.

What should you do if GC cannot run because the disk is full?

Do not delete files from the chunk store. Preserve the failed task details, confirm the actual filesystem or storage pool, and follow the official maintenance guidance for that backend. If GC cannot proceed, use a documented way to restore operating headroom or add capacity, then rerun and verify maintenance. Stop and escalate if you cannot confirm a safe recovery route.

If your current storage is a shared VPS or cloud instance, account for possible noisy-neighbor contention, CPU overcommit, opaque bandwidth or storage charges, and limited control over disk layout; whether those apply depends on the provider and plan. If you need a separately controlled host for sustained backup workloads, compare the measured capacity and redundancy requirements with OVN Cloud’s current dedicated AMD server options. Check the configuration and billing terms before choosing; if your workload is temporary, very light, or needs rapid elastic scaling, a dedicated physical server may not be the right fit.

Common questions

1. Why can the disk still look full after PBS deletes backups? Prune removes snapshots according to retention rules, but the chunks they referenced may still be needed by other snapshots. Garbage collection then identifies chunks that are no longer referenced and reclaims them. Check the prune and GC task results, then compare the datastore view with the actual backend capacity. Do not infer reclaimable space from the snapshot list alone.
2. What is the difference between PBS prune and garbage collection? Prune applies retention rules to backup snapshots and removes snapshots that no longer qualify. Garbage collection works on the underlying chunk store and can reclaim chunks only when they are no longer referenced. They are separate maintenance jobs, so a successful prune does not by itself prove that filesystem space has been returned.
3. Should I clean up or expand a nearly full PBS datastore? First confirm that prune and GC ran as expected, inspect their task logs, and identify the actual storage backend. If retention is wrong or a maintenance task failed, address that cause before changing capacity. If the backend is genuinely short of space, plan a supported expansion or a separate backup target with a verified recovery path.
4. What if GC cannot run because the PBS disk is full? Do not delete files from the chunk store to make room. Record the failed task, confirm the mounted filesystem or storage pool, and check the official PBS maintenance guidance for the backend in use. If GC cannot proceed, use a documented way to restore operating headroom or add capacity, then rerun and verify maintenance. Escalate before taking an irreversible action.