A backup application can show a substantial snapshot, remove that snapshot from its list, and recover surprisingly little disk space. Those observations can all be consistent. The snapshot describes a saved state; some of the data needed for that state may also support other snapshots. Removing one saved state does not make its shared data unnecessary. Borg's 1.4.5 documentation explicitly distinguishes an archive's exclusive stored data from the repository's combined data. [2]

Three questions therefore need separate answers: how much file content does this snapshot describe, which stored pieces would become unnecessary if it disappeared, and how much space has actually been reclaimed? We will work through an original miniature repository to answer them. Every size counts only uncompressed data payload in MiB, with one MiB equal to 1,048,576 bytes. Metadata, indexes, encryption overhead, padding and filesystem allocation are excluded. This is an accounting example, not an observed backup run. Its purpose is to explain why a displayed size, a deletion decision and a free-space change need not match.

Distinguish logical snapshot payload, uniquely retained payload and physically reclaimed allocation. A snapshot can describe many bytes while referencing objects shared with other retained roots. Deleting that root removes references; it does not imply that every referenced object becomes unreachable. Borg 1.4.5 documents different meanings for per-archive and repository-wide deduplicated sizes. [2] These are separate measurements, not competing estimates of a single quantity.

The original model below assigns fixed uncompressed payload weights to five content objects. One MiB is 2^20 bytes. Every snapshot has a complete manifest whose ordering and file metadata are assumed correct but excluded from the size account. Each object occurs once within each snapshot's payload, so set union is sufficient for this example's sizing. There is no compression, padding, encryption expansion, index cost or filesystem allocation model. The resulting byte counts establish reference and packing relationships; they cannot predict a real application's total disk usage from a snapshot label alone.

Deduplication avoids storing another payload copy when the repository already has the same content piece. In Borg's documented approach, files are divided into content-defined, variable-length chunks and reuse can span different backups or machines within the same repository. Its explanation does not require filenames or chunk positions to stay unchanged. [1] A renamed document and a wholly new document therefore raise different storage questions, even when both appear as changes in a folder listing.

For our model, five content identities have fixed sizes: A is four MiB, B is three, C is two, D is one and E is five. The letters identify content, not filenames or backup dates. We stipulate that matching letters mean exactly the same bytes. A snapshot's manifest supplies the information needed to assemble its files from those pieces. Looking only at the manifest's name or creation date would conceal these sharing relationships. A later date does not, by itself, imply another physical copy of every earlier byte.

Borg describes content-defined variable-length chunking and deduplication across the contents of one repository, including different archives and machines. Its matching mechanism is independent of unchanged file paths and absolute chunk positions. [1] That documented mechanism motivates the model; the chosen object boundaries and sizes are our own. We are not reproducing Borg's chunker or asserting an identical internal representation for every backup format.

Let the content universe be U={A,B,C,D,E}, with weights w=(4,3,2,1,5) MiB in that order. Identity equality and correct manifest references are stipulated. A snapshot's reference set describes which objects it needs; the manifest additionally retains the ordering and file structure that a set cannot express. Separate these roles: set membership supports a storage calculation, while a reconstruction recipe requires more information. Renaming a manifest entry without changing its referenced payload is different from introducing a new content identity. Neither a path change nor chronological distance alone determines additional payload storage.

Give the first snapshot the pieces A, B and C. Its described payload is four plus three plus two, or nine MiB. The second snapshot needs A, B and D, totaling eight MiB. The third needs A, D and E, totaling ten. Adding the three snapshot sizes gives twenty-seven MiB, but that calculation counts A three times and counts B and D twice. Those repetitions describe references to the same stored pieces in our repository.

The combined stored payload contains A, B, C, D and E once each: four plus three plus two plus one plus five equals fifteen MiB. That is the amount needed to support all three manifests under the model's assumptions. The difference of twelve MiB reflects repeated references in the logical total; it is not a measurement of filesystem space saved. Compression, for example, would introduce another size boundary. Borg separately documents that individual archive deduplicated values do not simply add to its repository value. [2] Reading the column's definition matters before doing arithmetic.

Define reference sets R1={A,B,C}, R2={A,B,D} and R3={A,D,E}. Their weighted logical sizes are 9, 8 and 10 MiB. The sum is 27 MiB, but the live content set for all three roots is R1∪R2∪R3=U, with weight 15 MiB. Reference multiplicities are m(A)=3, m(B)=2, m(C)=1, m(D)=2 and m(E)=1. Thus the logical sum is Σm(x)w(x), whereas the live union is Σw(x) over objects with positive multiplicity.

This establishes a twelve-MiB difference between two defined payload accounts. It is not a compressed-size ratio, an empirical deduplication benchmark or an allocation measurement. A real report may also distinguish original, compressed and exclusive values; Borg's documented archive and repository deduplicated columns already have different scopes. [2] Within the toy account, every logical snapshot size remains valid: the manifest genuinely refers to that much payload. The mistake would be treating these valid per-snapshot descriptions as disjoint physical storage allocations.

Now remove the second snapshot from the set we intend to retain. It described eight MiB, but A is still needed by snapshots one and three. B is still needed by snapshot one, and D by snapshot three. Every piece it referenced remains useful. Its removal makes zero MiB of payload newly unnecessary. This does not say that its manifest occupies zero bytes; manifest storage sits outside the deliberately limited payload account.

The other snapshots behave differently. Only snapshot one needs C, so removing that snapshot alone makes two MiB unnecessary. Only snapshot three needs E, so removing it alone makes five MiB unnecessary. The initial exclusive amounts are therefore two, zero and five MiB. Together they total seven, leaving eight MiB shared across snapshots. This is why adding exclusive sizes does not recover the fifteen-MiB combined total. Borg's per-archive exclusive meaning illustrates the same distinction. [2] An archive can be useful as a restore choice even when it contributes no exclusive payload.

For retained-root set K, define live objects L(K)=∪i∈K Ri. The immediate payload eligibility from removing root j is the weight of L(K)∖L(K∖{j}). Initially K={1,2,3}. Removing root 2 leaves {A,B,C,D,E} unchanged, so its marginal payload amount is zero. The formula asks about objects losing their final live reference; it does not sum all references carried by the deleted manifest.

Initially the exclusive object sets are X1={C}, X2=∅ and X3={E}. Their weights are 2, 0 and 5 MiB. The remaining objects {A,B,D}, totaling 8 MiB, have multiple live references. Consequently Σw(Xi)=7 MiB rather than the union's 15 MiB. This original calculation explains the documented distinction between Borg's archive-exclusive and repository-wide measures. [2] A zero exclusive value is compatible with a complete, distinct restore root. It does not establish that removing the root is harmless to the desired history, nor does it measure metadata or immediate physical reclamation.

Suppose the retained set will contain only snapshot three. Removing snapshot one first makes C's two MiB unnecessary. Removing snapshot two afterward then makes B's three MiB unnecessary, because snapshot one no longer needs it. The total is five MiB. Reverse the order and the first removal, of snapshot two, contributes zero; the later removal of snapshot one contributes both B and C, totaling five. Both paths finish with A, D and E.

The order changes which step receives credit, but it does not change the final ten-MiB live payload. Adding the original individual estimates, two plus zero, would miss B's three MiB because B initially had two references. Once both referencing roots disappear, that shared piece becomes unnecessary too. This is a useful way to read an estimated saving: ask which other snapshots are assumed to remain. A size calculated for removing one item in isolation is not automatically an additive budget for removing a group.

For the joint removal J={1,2}, the relevant set is L({1,2,3})∖L({3})={B,C}, with weight 5 MiB. The sum of the initial singleton marginal values is only 2+0=2 MiB. The omitted object B becomes unreachable only when both of its roots are removed. Thus initial per-root exclusivity does not define an additive partition of all potential reclamation.

Sequential attribution depends on the changing retained set. Order 1 then 2 yields marginal amounts 2 and 3 MiB; order 2 then 1 yields 0 and 5 MiB. Both telescope to the same difference, 15−10=5 MiB. This order invariance concerns the final live union, not intermediate disk usage or implementation scheduling. A cleanup tool may process its work differently. The analytical lesson is to preserve the reference-set assumption attached to a size estimate: evaluating each proposed removal against the original set and summing the results can undercount shared objects that lose all references jointly.

It is tempting to imagine snapshot two as a patch that can only be opened through snapshot one. That is not how we defined these manifests. Snapshot two has its own complete recipe for A, B and D. If snapshot one disappears, the pieces that snapshot two still needs remain in the repository. Shared storage and a required chain of earlier snapshot files are different relationships. Our model explicitly assumes complete recipes, not a sequence of incremental patches.

The distinction explains what a retained root protects. Kopia's maintenance documentation describes identifying content that cannot be reached from any active snapshot. [5] In our model, retaining snapshot three protects its route to A, D and E even when older roots are absent. But a manifest alone is insufficient: the referenced pieces must still be present and usable. A useful reading of a backup inventory therefore connects a saved state to the data it actually depends on, rather than inferring dependency purely from the order of dates in the list.

Each toy root owns a complete manifest referencing content objects directly, with no edge to an earlier root required for reconstruction. Removing R1's manifest does not break R2's paths to A, B and D, provided those live objects remain available. This is a stipulated graph structure. It should not be generalized to every incremental or differential backup format merely because its user interface uses the word snapshot.

Kopia documents snapshot garbage collection in terms of content unreachable from active snapshots. [5] That provides a concrete reference-reachability concept, while the toy graph makes its dependency assumptions explicit. Root availability, reference correctness and object availability are separate conditions. Chronological adjacency proves none of them: a recent root can reference old content without requiring an old manifest. Conversely, a root whose referenced object is missing cannot reconstruct that object merely because its own metadata survives. This separation lets us reason about retained history without confusing content reuse with a chronological dependency chain.

Add a fourth snapshot whose payload recipe is identical to snapshot three: A, D and E. It describes ten MiB but introduces no new content pieces. The live payload stays fifteen MiB. There would still be new snapshot metadata in a real system; the zero refers only to the additional data payload in this model. The fourth snapshot can have a separate date or label without implying another stored copy of A, D or E.

Something less obvious happens to snapshot three. E used to belong only to it, giving it five MiB of exclusive payload. E is now shared with snapshot four, so snapshot three's exclusive amount falls to zero although none of its file content changed. Remove snapshot three alone and all its content remains needed. Remove both three and four while retaining one and two, and E's five MiB becomes unnecessary. Exclusivity describes a relationship with the current retained set; it is not a permanent property stamped onto a snapshot when it is created.

Extend K with R4=R3={A,D,E}. The live union is unchanged at 15 MiB, while the logical sum rises from 27 to 37 MiB. The additional payload weight is zero under the no-metadata account. Multiplicities for A, D and E each increase by one. Snapshot identities remain distinct even though their referenced content sets are equal.

Before the addition, X3={E}; afterward X3=∅ because R4 also reaches E. The marginal payload eligible from deleting root 3 has therefore changed from 5 MiB to zero without changing R3 itself. Removing roots {3,4} together, while keeping {1,2}, leaves {A,B,C,D} and makes E's 5 MiB unreachable. This demonstrates why an exclusive-size result requires a retained-set context or observation time. It cannot be treated as immutable provenance of a snapshot. Nor does equal payload imply equal whole-repository cost: manifest, index and any other accounting terms omitted here must be evaluated separately.

So far, “unnecessary” has meant that no retained snapshot needs a piece. It has not meant that the storage device has already recovered its space. Restic's 0.19.1 guide separates forgetting snapshots from pruning the underlying data that is no longer referenced. [4] Borg's 1.4.5 guide likewise distinguishes archive deletion from the compaction that recovers repository space. [3] The application may finish one stage while another still has work to do.

Kopia also documents maintenance safety delays, so a cleanup's effects need not appear immediately. [5] These are specific documented systems, not a universal timing promise. To interpret our example, keep a small ledger: roots one and two removed; live payload ten MiB; newly unreachable payload five MiB; physically reclaimed payload still to be established. Those entries can be simultaneously correct. Waiting for a number to change is not a substitute for identifying which stage that number reports, and a disappeared snapshot name does not prove that every former payload object has been erased.

Logical removal changes the root set; reachability analysis identifies objects with no retained path; physical reclamation changes stored allocation. Restic 0.19.1 distinguishes snapshot forgetting from pruning unused data, and Borg 1.4.5 describes compaction as the step that frees repository space after archive deletion. [3][4] These documented distinctions support separating the stages without asserting a shared implementation or identical completion event.

Kopia's maintenance guide additionally explains that safety rules can defer removal across time or maintenance cycles. [5] Thus eligibility and execution should not share a timestamp by assumption. After retaining only R3, our graph has 10 MiB live and 5 MiB unreachable, but neither figure alone specifies the allocation still occupied. A meaningful status record needs both a reference view and a reclamation view. Treating removal from a snapshot listing as proof of physical erasure would cross those views without evidence; treating temporarily occupied unreachable bytes as evidence that the root removal failed would make the opposite mistake.

Now add a separate packing rule to the same example. Pack one contains A and C, totaling six MiB. Pack two contains B and D, totaling four. Pack three contains E, totaling five. Together they hold the original fifteen MiB. After retaining only snapshot three, A, D and E remain needed, while B and C do not. Yet each of the three packs still contains at least one needed piece.

If this imagined storage layer can reclaim only an entire unused pack, it cannot reclaim any of these packs as they stand. Five MiB is unnecessary at the content level, but zero MiB sits in a wholly unnecessary pack. Restic describes distinguishing fully used, partly used and unused repository files, with partly used files potentially repacked. [4] Our small arrangement explains that distinction: recovering the unwanted space inside a mixed pack requires a different operation from dropping a completely unused pack. The content map and the packing map answer different questions.

Assign physical payload containers P1={A,C}, P2={B,D} and P3={E}, with weights 6, 4 and 5 MiB. After K becomes {3}, live objects are {A,D,E}; dead objects are {B,C}. P1 retains A, P2 retains D and P3 retains E. Every container has a nonempty intersection with the live set, although 5 MiB of their aggregate content is unreachable.

Under a whole-container-only deletion rule, directly removable container payload is therefore zero. That differs from unreachable object payload, which is 5 MiB. Restic's pruning description classifies stored files by full, partial or absent usage and allows partial files to be retained or repacked. [4] The toy mapping illustrates the need for that distinction without reproducing restic's pack format or policy. Object reachability determines what can be discarded logically; container layout determines whether discarding it requires rewriting retained content. A free-space estimate that omits the packing layer cannot infer the immediate effect of deleting roots.

Choose one explicit rewrite plan for the mixed packs. Write a new five-MiB pack containing the still-needed A and D. Keep pack three, containing E. During the write, leave the old packs in place. At that point the payload account contains the original fifteen MiB plus the new five, giving a temporary peak of twenty. Then retire old packs one and two, whose combined size is ten MiB. The final payload is ten MiB, as the retained snapshot requires.

The plan recovers five MiB overall but temporarily needs five MiB beyond the starting amount. That is not a contradiction: the surviving content exists twice during the transition. Restic documents storing repacked files before deleting obsolete files and notes the need for working space. [4] Our twenty-MiB peak belongs only to this declared rewrite order and payload-only model. Actual allocation and metadata can change the required headroom. The useful insight is that the final smaller state does not, by itself, show that every intermediate state will fit.

Declare a repacking schedule that writes P4={A,D}, weight 5 MiB, before retiring P1 and P2. P3 remains throughout. The accounted payload sequence is 15 MiB initially, 20 MiB while P4 coexists with P1–P3, and 10 MiB after the old 6+4 MiB containers are retired. Net recovery is 5 MiB; additional peak payload is also 5 MiB, for this particular schedule.

Restic's documented pruning order stores repacked files before obsolete-file deletion and can require scratch space. [4] The numerical peak here is independently assigned, not an implementation measurement or universal upper bound. Other packing, streaming, ordering and metadata rules would require a different occupancy trace. Even within this model, the equality of peak overhead and net recovery is incidental: one measures temporarily duplicated surviving payload, the other permanently removed dead payload. Keeping the transition ledger prevents a final-size calculation from being misread as a claim that a nearly full repository can always reach that final state without extra capacity.

Return to the original three snapshots. All of them depend on A. If the repository loses its only usable copy of A, each of those snapshot recipes is missing a required piece. Three visible restore choices do not create three independent physical copies of that shared content. This follows from the model's reference map; it does not assign a failure probability to any storage product or claim that a particular backup has been damaged.

Retention and integrity therefore ask different questions. Retention chooses which saved states remain available in the intended history. Integrity asks whether their required data and reconstruction information still work. The zero-exclusive second snapshot can preserve a useful historical combination of A, B and D, but it does not add an independent copy of A. Conversely, a repository with every shared piece intact may still lack a desired old state if its manifest has been removed. Counting snapshot labels alone cannot answer either question completely.

In the original graph, A has incoming references from all three roots but only one stipulated stored payload instance. Removing or corrupting that instance breaks every reconstruction that requires it. Reference multiplicity is not replica multiplicity. This is a graph consequence, not a reliability estimate: the model specifies neither device-failure statistics nor actual redundancy, repair or integrity mechanisms.

Root retention and object integrity are independent predicates. A retained root with an unavailable required object is insufficient for reconstruction; intact content objects without the needed manifest are insufficient to identify and assemble the intended saved state under this model. Snapshot 2 illustrates the distinction particularly well. Its zero exclusive payload does not make its historical combination redundant as a restore choice, yet its presence adds no separate payload instance of shared A. This is why a list of versions cannot establish the number of independent data copies, and a deduplication ratio cannot establish that any chosen version is recoverable.

A useful reading record begins with the unit and the kind of size: described file content, exclusive content, combined live content, stored pack payload or filesystem allocation. Next identify the snapshots assumed to remain. Then record whether the application has only removed references, identified unused content, rewritten mixed storage or actually reclaimed allocation. The distinctions come from documented reporting and maintenance behavior, but the numerical relationships need the account's own assumptions. [2][3][4][5]

Our original three snapshots describe twenty-seven MiB while sharing fifteen MiB of payload. Removing the eight-MiB second snapshot alone makes no payload unnecessary. Retaining only the third makes five MiB unnecessary, yet the chosen mixed packs initially permit no whole-pack deletion. The declared rewrite briefly reaches twenty MiB before ending at ten. Each number is correct for its own question. Preserve those questions alongside the figures, and a surprising free-space result becomes something you can interpret precisely rather than judge by the largest number on the screen.

A compact interpretation should bind each reported size to its population, representation and state. Population identifies the retained roots; representation identifies logical bytes, exclusive objects, the live union, packed payload or allocated storage; state identifies the completed point in removal and reclamation. Borg's differentiated size definitions and the documented maintenance stages of Borg, restic and Kopia show why those qualifiers are operationally meaningful. [2][3][4][5]

For the original root set, logical sum 27 MiB, live union 15 MiB and exclusive sum 7 MiB are simultaneously valid. Removing root 2 alone changes none of the live payload. Retaining only root 3 reduces the live union to 10 MiB, but mixed containers initially leave all 15 MiB stored. The specified repack peaks at 20 MiB and ends at 10. These are exact results of a declared model, with metadata and real allocation excluded. A snapshot label cannot replace the reference graph, and a final union size cannot replace the physical transition account.