Why Does a Deduplicated Backup Repository Act Read-Only After an Interrupted Prune?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Why Does a Deduplicated Backup Repository Act Read-Only After an Interrupted Prune? - Zima Store Online

A repository can act read-only after an interrupted prune when an exclusive lock, storage error, immutable backend, or incomplete maintenance state blocks changes.

“Read-only” may be the backup client’s safety response rather than the filesystem’s actual mount mode. A cancelled prune can leave an exclusive lock, unfinished pack or index work, insufficient cleanup workspace, or backend operations that permit reads but reject deletes. Separately, the operating system may remount the repository filesystem read-only after I/O or consistency errors. Identify which layer refuses the first write before removing locks or rerunning prune.

Capture the First Operation That Reports Read-Only

Run a repository list command, then one non-destructive check, and save the first error from the client, backend, and operating-system logs.

The Restic documentation explains that prune rewrites repository data and needs exclusive access because it removes unreferenced content and can repack partially used files.

If listing works but every operation that creates a lock or writes metadata fails, distinguish stale lock, backend write permission, and object retention.

Check for an Exclusive Lock Left by the Interrupted Prune

List repository locks through the backup tool and identify the host, process, creation time, and command that owns each lock.

Borg documents that repository-changing commands use repository locks to prevent concurrent writers, and warns that breaking a live lock can damage repository state.

Remove a stale lock only through the supported command and only after proving the owner is gone.

Determine Whether the Filesystem Remounted Read-Only

Check the mount table, kernel log, filesystem health, storage-pool state, and recent USB, SATA, network, or controller errors.

The Linux ext4 documentation lists errors=remount-ro as a safety policy, showing how a storage fault can make the repository genuinely read-only.

Do not force a read-write remount while hardware or filesystem errors continue. Preserve logs and repair the storage first.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

Inspect Partial Prune, Compact, or Index State

Determine which phase was interrupted: selecting expired snapshots, deleting references, repacking data, rebuilding an index, or committing metadata.

The Borg prune reference notes that prune and compact are separate steps, so archives may remain valid while space reclamation is incomplete.

Use the repository check command before another destructive run. Never delete packs, indexes, or segments manually.

Check Object Lock, Immutability, and Backend Credentials

For cloud repositories, inspect object retention, legal hold, bucket policy, versioning, delete permission, and credential rotation.

AWS states that S3 Object Lock prevents deletion or overwrite during a protected retention period, allowing reads while prune fails.

Do not weaken immutable retention merely to make prune pass. Use a repository design supported by the backup tool.

Verify Free Space, Inodes, and Prune Workspace

Check filesystem bytes, inodes, quotas, snapshot reserves, temporary directories, object-store limits, and local cache space.

GNU Coreutils explains that df can report blocks and inode usage, separating a full filesystem from a repository-level lock or permission failure.

If the filesystem is full, add temporary capacity or remove unrelated verified data rather than deleting repository objects.

Recover With Check, Unlock, and One Controlled Maintenance Run

Protect the last known-good restore points, stop schedules, run a supported check, clear only a proven stale lock, and perform one logged maintenance run.

The ZimaSpace guide to recovering a full backup destination provides the adjacent rule: treat a repository as a managed structure, not independent files.

The issue is resolved when list, check, backup, retention, and a test restore all succeed without forced unlocks or manual deletion.