The primary purpose of a stack is to act as a backup of the archive. Should an archive be lost or become irreparably damaged, you can use the stack to recover it.
To recreate an archive from a stack:
A new, empty, archive is created with the same settings as the original, connected to this stack.
The selected layers are copied from the stack back to the archive.
That's it! The recovered archive is a functional duplicate of the lost one, and is ready to use.
All data in an stack is compressed, and that data does not get expanded when it is copied back to an archive.
So it is not unusual for a recovered archive to be substantially smaller than the original.
In the 19th Century, some people believed that if you met your Doppelgänger, you would die. A similar—but far less dramatic—fate could befall your archive. You need to be aware of this pitfall and how to avoid or rectify it.
Every archive has a unique identifier. This identifier is used to bind the stack with its archive; this prevents a stack from being contaminated with the content of a different archive. A stack cannot be used with an archive with a different identifier.
The key word here is "unique". Proper archive management is based on the assumption that every archive has a unique identifier. If QRecall ever encounters two archives with the same identifier (say, if the archive document was duplicated), one of the archives is automatically assigned a new identifier.
This can be a problem should you decide to test the archive recovery feature, by extracting the stack to a new archive, which is essentially a duplicate of the original and has the same identifier. As soon as QRecall becomes aware of both archives, it will reassign one of the archives a new identifier.
If that happens, one of the archives will no longer be connected to the stack.
This is not to suggest that you shouldn't test the recovery feature; it's important to test, and verify, every step of disaster recovery. But you could end up in a situation where your primary archive is no longer usable with its stack. There are some ways to avoid this. The simplest method is to make sure the original archive is not accessible when recovering a copy from the stack:
If this does happen and your original archive is no longer connected to its stack, there is a command line utility that will manually exchange the identifiers of two stacks:
qrecall migrate xchngid /path/to/original /path/to/recoveredIf the recovered archive has already been deleted, then your choices are down to:
It is not always necessary to recover an entire archive. Following a repair, an archive might have incurred a modest amount of data corruption which impact only a limited number of layers (these will be labeled "repaired" in the layer browser).
Following a repair, those specific layers can be recovered from the stack, likely using a fraction of the data required to recover the entire stack.
In the example below, corrupt file records have resulted in the lost of a few files and the repair of a folder that contained them. Opening the slices window and selecting the Recover from command automatically identifies the repaired layer and suggests the slice to recover:
Recovering just that slice will completely restore the state of the repaired archive.