Recover Archive

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.

Recover an Archive Steps

To recreate an archive from a stack:

Choose File ➤ Recover from Stack….
Specify the stack container type and details, exactly as you did when the stack was first created. An AWS stack, for example, will require an access key, secret, region, and bucket name.
Click Next….
Select the stack to recover from.
Choose where to store the recovered archive and click Create.

A new, empty, archive is created with the same settings as the original, connected to this stack.

In the slices window, select the layers from the stack that you want to recover (most likely, all of them).
Click Recover

The selected layers are copied from the stack back to the archive.

If the original archive was connected to other stacks, reconnect those stacks now.

That's it! The recovered archive is a functional duplicate of the lost one, and is ready to use.

Archive Doppelgängers Warning

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:

take the archive's volume off-line
make the volume read-only
relocate the archive to a folder without read permission
or similar steps so the original is not reachable

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/recovered

If the recovered archive has already been deleted, then your choices are down to:

Delete the existing stack container and create a new stack for the archive
Delete the archive and recover it again from the stack

Recover Slices

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.