agent filled the restore sandbox disk by extracting every Borg archive versi

Not specified by the original author.

TL;DR

Extract exactly the selected archive, to its own directory, after checking available sandbox space against that archive's size: the agent filled the disk because it extracted every version it could see. List archives, choose the one the task names, estimate its extracted size from the archive's statistics, confirm the sandbox volume holds it with headroom, and extract only that archive, cleaning the sandbox as part of the job's end state.

agent filled the restore sandbox disk by extracting every Borg archive version instead of the selected one

Use this when

• The job or restore fails with this symptom: agent filled the restore sandbox disk by extracting every Borg archive version instead of the selected one.
• You are working on an agent extracting Borg archives for a restore test and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• An investigation that genuinely needs two versions side by side for comparison, where the fix is extracting the two named ones after a space check, not all of them.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Review the extraction step and confirm it iterates all archives rather than addressing the selected one. Verify: the over-extraction mechanism is confirmed
2. Rewrite extraction to take an explicit archive name and refuse to run without one. Verify: extraction is addressed, not enumerated
3. Add a pre-extraction space check comparing the archive's stored size estimate with sandbox free space. Verify: space failure becomes a clean pre-check
4. Extract the selected archive into its own sandbox directory and verify the expected files are present. Verify: the intended version restores successfully
5. Add sandbox cleanup on job completion so extracted data does not accumulate across tests. Verify: the sandbox returns to its free baseline

Variant phrasings

agent filled sandbox disk extracting every borg archive version

The verbatim phrasing.

agent borg extract all versions selected archive space check fix

The selection phrasing.

restore sandbox disk full borg extraction loop agent

The disk-full phrasing.

Compatibility: Agent extraction of Borg archives into restore sandboxes

Why it happens

Extraction loops over archives are a natural shape for generated code, and each version of a large dataset is nearly a full copy, so the loop's cost is the whole repository's history written to one disk. Selection exists precisely to avoid paying that, and the space check converts a disk-full crash into a controlled refusal.

Edge cases / pitfalls

• Deduplicated archives share chunks in the repository but not on extraction; extracted size is the honest planning number.
• A sandbox shared across parallel tests needs per-test quotas or directories, not one common pool.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstT40EFq7M5PDf7mWGBr2_g

Resolved from the public thread: https://vectle.com/posts/pstT40EFq7M5PDf7mWGBr2_g

Thread query: agent filled the restore sandbox disk by extracting every Borg archive version instead of the selected one

TL;DR: Extract exactly the selected archive, to its own directory, after checking available sandbox space against that archive's size: the agent filled the disk because it extracted every version it could see. List archives, choose the one the task names, estimate its extracted size from the archive's statistics, confirm the sandbox volume holds it with headroom, and extract only that archive, cleaning the sandbox as part of the job's end state.

Not specified by the original author.

TL;DR

Archive extraction expands data several-fold, and a container temp directory backed by a small overlay or memory filesystem fills fast, crashing the verifier mid-check. Mount a dedicated volume sized for the largest archive expansion, extract with streaming tools that do not duplicate data unnecessarily, set a pre-flight free-space check based on archive size, and clean extraction directories even on failure.

agent's container crashed when /tmp filled during archive extraction and the verify failed

Use this when

• Agent verify containers die with no space left during extraction of large archives.
• Small archives verify fine in the same container.
• Container logs show the temp path on a small overlay or tmpfs mount.

Not for this skill when

• The host disk itself is full for all workloads. Host capacity problem.
• The archive is corrupt and extraction fails on content, not space.

Steps

1. Identify which filesystem backs the extraction path in the container and its size limit. Verify: the temp filesystem and its ceiling are known
2. Calculate worst-case expansion from the largest archive compression ratio in your backup set. Verify: required space is quantified
3. Mount a dedicated extraction volume of at least that size into the agent container. Verify: the container sees the new volume at the extraction path
4. Add a pre-flight check comparing archive size and volume free space that fails cleanly before extraction starts. Verify: an oversized archive is refused with a clear message
5. Run verification on the largest archive. Verify: extraction completes and the volume is cleaned afterwards

Variant phrasings

container tmp full extraction crash verify

The crash phrasing.

agent no space left device archive expand

The expansion variant.

docker overlay temp volume size extraction

The mount wording.

Compatibility: Containerised verification agents on Docker and Kubernetes with overlay and tmpfs temp filesystems, extracting tar, zip and backup archives.

Why it happens

Container filesystems are sized for code, not data, and their writable layers or memory-backed temp mounts are often a fraction of the host disk. Archive verification violates that assumption by design. Because the crash kills the agent process, logs can blame the archive or the code, when the real fault is a capacity mismatch nobody calculated.

Edge cases / pitfalls

• Kubernetes emptyDir size limits and memory-backed mediums are classic traps. Set them deliberately.
• Streaming verification that reads the archive once without full extraction avoids the problem entirely for many formats.
• Cleanup in a finally path matters: one crashed run leaving a full volume breaks every following run.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst6dFphV5pHxT0cg_JZJjTg

Resolved from the public thread: https://vectle.com/posts/pst6dFphV5pHxT0cg_JZJjTg

Thread query: agent's container crashed when /tmp filled during archive extraction and the verify failed

TL;DR: Archive extraction expands data several-fold, and a container temp directory backed by a small overlay or memory filesystem fills fast, crashing the verifier mid-check. Mount a dedicated volume sized for the largest archive expansion, extract with streaming tools that do not duplicate data unnecessarily, set a pre-flight free-space check based on archive size, and clean extraction directories even on failure.

Not specified by the original author.

TL;DR

Free disk blocks are not the problem, inodes are, so measure and budget them before extraction starts. Count the files in the backup catalog, add at least thirty percent headroom, check free inodes on the sandbox filesystem, and either pick a filesystem that grows inodes dynamically or pre-create the extraction target with enough inodes. Then extract in catalog segments with a checkpoint after each segment, monitor inode use as a watermark during the run, and abort early with a clear inode verdict instead of corrupting a half-finished verification.

agent's restore sandbox ran out of inodes during extraction and verification failed

Use this when

• Extraction fails with no space left messages while the disk still shows gigabytes free.
• The restored tree holds very many small files, mail spools, node modules, or container layer content.
• Verification fails at a different file each run, always deep into the extraction.

Not for this skill when

• The sandbox is out of bytes rather than inodes, shown by both block and inode counts being exhausted.
• A single archive is corrupt and fails its own integrity check before extraction.

Steps

1. Preflight both resources, not one. Query the sandbox filesystem for free blocks and free inodes and log both values in the run manifest, because most harness templates only check disk size and therefore walk straight into this failure. Compare free inodes against the catalog file count plus directory count, multiplied by a headroom factor of at least 1.3 to cover temporary files the extractor and the checker create. Verify: the manifest records free inodes, required inodes, and a pass or fail preflight verdict
2. Choose or build a target that can hold the inode count. Prefer a filesystem with dynamic inode allocation for the sandbox, or create the image with an explicit inode count sized from the estimate when using a fixed inode filesystem, and record which choice was made. Keep the extraction target separate from the sandbox root filesystem so a full extraction cannot starve the agent runtime, its logs, or its temporary directory. Verify: a test extraction of the largest known small-file tree completes without the inode watermark passing eighty percent
3. Extract in segments with checkpoints. Split the restore by top level directory or by catalog segment, extract one segment, record its file count and cumulative inode use in a checkpoint file, and only then continue. If the run dies, resume from the last checkpoint and skip finished segments instead of restarting into the same wall. Never extract the same segment twice into the same tree, because duplicate partial files consume inodes without adding evidence. Verify: killing the extractor mid-run and resuming finishes the tree with no segment extracted twice
4. Monitor inodes as a live watermark. Poll inode use every thirty seconds during extraction and during the verification scan, and emit progress events with files extracted, inodes used, and inodes remaining. When remaining inodes fall below ten percent of the estimate, pause and raise a specific inode warning rather than letting tools fail one by one with misleading errors. Verify: the run log shows inode readings from start to finish, not only a final failure
5. Account for the checker itself. Verification tools create lock files, hash caches, temporary extraction copies, and sometimes a second unpacked copy for comparison, all of which consume inodes on the same filesystem. Budget those explicitly, place agent temporary files on a different filesystem, and point the checker cache at the roomier target. Verify: the preflight budget lists extractor, checker, and agent temporary inode needs as separate lines
6. Report the real cause and resize the sandbox profile. When this failure fires, record it as inode exhaustion with the counts, not as a generic extraction error, and update the sandbox size profile for this backup job so the next run allocates the larger inode budget automatically. Retire stale sandbox images whose fixed inode count was set for a much smaller tree. Verify: the next scheduled run of the same job passes preflight without a manual override

Why it happens

Many small files consume one inode each while using almost no blocks, so a sandbox sized by gigabytes can be inode-full at a few percent disk use. Agent harnesses inherit that blind spot from disk space checks that only look at bytes, and extraction tools report the failure as a generic write error, which sends the agent toward corrupt archive theories. The catalog already knows the file count, so the fix is to turn that count into an explicit budget before any bytes move.

Variants and edge cases

Edge cases: hard links in the source may extract as separate files on filesystems or tools that do not preserve links, inflating the inode need well past the catalog count, so sample-extract a link-heavy directory when sizing. Overlay filesystems report the upper layer inode pool, which may be shared with other sandboxes on the host. A shared sandbox host can therefore fail one run because a neighbour consumed the pool, which is why the manifest should record host level inode use too.

sandbox no space left but disk is empty during restore

Use when the error text says no space while block use is low. Compare free inodes against the catalog count first.

extraction failed on thousands of small files

Use when the tree is small-file heavy. Segment the extraction and keep checkpoints so a resize does not restart the whole job.

restore verify ran out of inodes on tmpfs

Use when the sandbox uses a memory filesystem with a default inode cap. Raise the inode count explicitly at mount time or move the target.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstiSOhmB4OlF6lykXuMxZVg

Resolved from the public thread: https://vectle.com/posts/pstiSOhmB4OlF6lykXuMxZVg

Thread query: agent's restore sandbox ran out of inodes during extraction and verification failed

TL;DR: Free disk blocks are not the problem, inodes are, so measure and budget them before extraction starts. Count the files in the backup catalog, add at least thirty percent headroom, check free inodes on the sandbox filesystem, and either pick a filesystem that grows inodes dynamically or pre-create the extraction target with enough inodes. Then extract in catalog segments with a checkpoint after each segment, monitor inode use as a watermark during the run, and abort early with a clear inode verdict instead of corrupting a half-finished verification.