A stack is updated using the cascade action. This is the most common stack action, and one of the few you can automate. A cascade performs two tasks, as needed:

New archive layers that are not yet in the stack are appended to the stack. Each layer become a new slice.

A merged layer in the archive replaces multiple, equivalent, layers in the stack. This is referred to as "updating a slice."

To get started, you'll want to transfer the initial set of existing layers to the stack. Open the archive and choose Layers > Stack Slices from the menu.



This is the slices window. All direct interaction with your stack is performed through this window.

The action to perform is selected at the top of the window, and should default to "Cascade to". If it isn't, select the cascade action now.

To the right of the action is the destination stack. If you have more than one stack, select the stack you want to work with now.

In the middle is the list of slices (matched groups of layers) you can work with. Slices are enabled or disabled depending on what action is selected. The slices that are recommended for updating will be pre-selected automatically.

In the beginning, all you'll see are the layers in your archive. The stack side (on the right) is empty.

If you want to transfer all of your layers to the new stack, select them and click Update. And then be patient...

You can also select a different set of layers to update. Note that when you select (or deselect) a slice in the list, QRecall may select (or deselect) other slices too. There are rules about which slices can be transferred, and in what order, and the window will enforce those rules.

Automating updates

Updates are automated using the new cascade action.

Create the action and then specify the archive and stack you want to update. There are no options in the action; the slices to be transferred are chosen automatically based on those stack settings you set in the stack's configuration.

You can schedule the action like any other action. Run it twice a day or once a month. It's your choice.

About those settings....

Stack settings can temper when (or if) slices are transferred. This can reduce the amount of I/O, with the trade-off that the stack isn't as up-to-date as it could be.

Unlike an archive, which is assumed to be directly accessible and can be randomly modified, stacks are organized into clusters of data objects that are written once and never change. They may later be deleted, but that is their entire lifecycle.

This design means stacks will work efficiently with object storage services (AWS S3), filesystems that copy whole files (WebDAV), file/drive synchronization software (rsync), and cloud drives.

Another consideration is that stack containers may be expensive to access. This includes storage fees and metered I/O. It also might be expensive in terms of time (slow access). And there may be other considerations, such as data caps.

Finally, keep in mind that every update to a stack is a single, often large, transfer operation. Layers in stack are never randomly modified; they are replaced in their entirety.

Most of the settings offer ways to reduce how often slices are transferred, which reduces the amount of I/O that has to be performed to keep the stack in sync with the archive. They can also curtail how current the stack is.

Copy After [ 8] [Days]

The "Copy after" settings prohibits newly captured layers from being appended to the stack for a period of time.

As an example, let's take an archive that captures files hourly during the day. At the end of a week, there could be a hundreds of small layers. But let's say you have a rolling merge action that, after a week, merges those hourly layers in a single layer for each day. Setting a "Copy after 8 days" preference would wait for those small layers to be merged, before uploading a single (day) layer to the stack. Rather than uploading hundreds of small layers, only to replace then again in a week.

The disadvantage is that your stack will always be at least 7 days behind your archive.

Preserve for [ 2] [Months]
Update [saves at least 30%]

The next two settings reduce how often slices are updated. Once a slice has been added, these settings delay it from being replaced with a merged slice either by time or relative size.

The "Preserve for" setting prevents it from being replaced by an update for a specific period of time. Using the previous example, it would allow hourly layers to be added, but not replace them until the those layers had been merged into far more compact daily, weekly, or even monthly layers. The stack is always up-to-date, but the work needed to consolidate the layers is postponed so it's more efficient.

Similarly, the "Update saves" setting blocks a slice from being updated unless it is expected to reduce the size of the slice in the stack by a certain percentage.

Using a setting of "Update saves at least 30%," individual hourly stack layers may persist in the stack indefinitely. But once the archive has an equivalent layer that is at least 30% smaller, all of those stack layers will be replaced. Once replaced, it won't be replaced again until there's a newly merged layer that is, again, at least 30% smaller than the first replacement, and so on.

Save Forever...

Finally, note that there's an Update never option. With this setting, slices in the stack are never (automatically) replaced. This would be for archives that capture sensitive document changes which, for legal or regulatory reasons, must be maintained forever.

You can continue to merge and reuse space in the archive for new captures, but the layers and stack detail will never be reduced and will grow forever. Well, not *forever*. Years from now you may reach the limits of the archive index and have to start a new stack; but it's effectively forever.

Cascade strategies

On one extreme, if your stack container is a document on a fast local drive or server, set all of these settings to their minimum and run the cascade action regularly.

At the other extreme, you may delay the transfer of new slices to the stack for a month or more, choosing only to upload weekly layers.

In between these extremes, consider your bandwidth costs and your storage costs. If storage is expensive but I/O is cheap, set the "Update always" to keep your stack size a its minimum. If I/O is expensive or slow, set "Update saves at least 50%" or more, to minimize how often slices are replaced.

Manual Updates

These settings only apply to automatic cascade actions. These are the slices that QRecall will suggest when you open the slices window, and the set of slices the cascade action will copy automatically.

You can always open the slices window and update whatever slices you choose (within the rules, of course).