I did some backup maintenance and deleted some items from different archives.

Several times after that it happened that some layers became "incomplete". What does this mean? Waht msut I do now? Verify run okay.

The archive size remained the same (I delete about 50 GB). The status window tells me that 52 GB are unused. But the Inspector window says free = undetermined. Shouldn't give it the same number?

Is it normal that a simple delete of an item is not enough to recover space but I have to compact too?
When does QRecall calculate the unused/free space in archive? It seems that I need a verify to get the number.

Johannes

Johannes wrote:I did some backup maintenance and deleted some items from different archives.
Several times after that it happened that some layers became "incomplete". What does this mean?

An "incomplete" layer is one created by a capture action that was interrupted (canceled, stopped, ...) before it could finish.

Waht msut I do now?

Nothing. Just be aware that when recalling folders from that layer, that a folder may contain a mixture of captured and uncaptured files. This is normally not a big deal, but it can be in certain circumstances. For example, restoring a partially captured application bundle or system folder could have profoundly unpleasant results.

An incomplete folder/layer will go away when it's merged with a subsequent layer that has fully captured all of the same items.

The archive size remained the same (I delete about 50 GB).

The physical space occupied by deleted data is not recovered until it is reused (during a subsequent capture) or by compacting the archive.

The status window tells me that 52 GB are unused. But the Inspector window says free = undetermined. Shouldn't give it the same number?

The status window shows an estimate/likely value for free space in an archive. Some actions, like verify, update this estimate. The inspector window shows the actual amount, but that figure is much more difficult?and time consuming?to calculate, and it is not always practical to have it up-to-date.

Is it normal that a simple delete of an item is not enough to recover space but I have to compact too?

Reclaiming the physical space occupied by unused archive records is a time consuming and expensive task. So this process is deferred for as long as possible, to be as efficient as possible.

Here's how QRecall handles recovery of unused archive space:

- Determining what archive records are unused is an expensive task (many minutes). To avoid doing this work unnecessary, it is only performed (by default) by the compact action following a merge or delete action.

Once the unused space is identified, the unused records are erased (written with zeros), the actual amount of free space appears in the archive's inspector window, and subsequent capture actions will reuse this space to capture new data, avoiding the need to expand the archive.

- Recovering the disk space occupied by empty archive records is an extremely expensive task (several hours). To avoid doing this unnecessary, it is only done with the compact action sees that the empty space in the archive exceeds a minimum threshold, which defaults to 4%.

By using a minimum threshold, the compact action can usually avoid physically compacting the archive in most cases. Under normal use, an archive rarely contains more than 4% of unused space. When data is purged (through a merge or delete action), the next compact identifies and erases that space, and the next capture action will reuse it. So the empty space tends to fluctuate up and down, but QRecall can often avoid completely compacting the archive for months (even years).

The recommended procedure is to infrequently schedule a compact action to run automatically, say once a week or once a month. The compact action will free and erase any unused data, calculate the unused space, and (possibly) physically compact the archive.

Note: the free-space threshold is ignored if you perform the compact directly (from the Archive menu). Running the Archive > Compact command will always compact the archive, in full.

There are two advanced settings that affect this behavior. Setting QRCaptureFreeSpaceSweep to "true" will cause every capture action, that follows a delete or merge, to sweep the free space in the archive. It means that capture will immediately erase and use any unused space in an archive, and the free space value for the archive will be much more up-to-date, but it will radically slow down the capture actions that have to perform this calculation.

The other setting you can change is kCompactFreeSpaceMinimumRatio. You can set a ratio (between 0.0 and 0.9) to indicate the amount of free space (0% to 90%) that must be in the archive before a compact action will physically compact the archive. Setting it to zero causes the compact action to always compact the archive (not recommended).

Thanks for the detailed explanation.

Johannes