An archive that becomes damaged (due to media failure, volume corruption, I/O failure, system crash, or similar calamity) can be repaired using the repair command.
If the archive has an up-to-date stack, you have the option of simply recovering from the stack, instead of trying to repair the archive.
This may be preferable to a repair if you have a fast connection to the stack.
Yet another approach is to repair the archive, and then surgically recover just the damaged/repaired layers.
See also the auto-repair topic and the repairing archives guide.
Before repairing an archive, it is strongly recommended that you repair the volume where the archive is stored, using Disk Utility or some similar tool.
A lot of problems—I/O errors and data corruption—can often be traced to a corrupted volume structure. Repairing the volume before repairing the archive ensures that the volume is not the cause of any further issues.
Be warned: repairing an archive on a corrupted volume may result in additional data loss.
QRecall's volume repair feature uses macOS's built-in disk diagnostic tool; the same tool employed by Apple's Disk Utility. You are, of course, free to use any alternative utility of your choosing and skip the built-in repair.
There are three types of repair: Reindex, Repair, and Recover. Select which type you wish to perform using the tabs at the top of the dialog sheet.
A reindex does not make any modifications to the archive's primary data storage file. Instead, it simply reads the records in the primary data file and uses that to reconstruct the archive's index files. These index files are necessary to efficiently access and update the contents of the archive.
If anything in the primary data file is found to be inconsistent, a reindex will fail. Perform a reindex if you are told to, or you have reason to believe that the problem is with an index file and all of the archive records are valid.
If the reindex is successful, it indicates that there was no lost or corrupted data in the archive.
This option is slightly faster than a regular repair.
A repair reads the primary data storage file and validates all of the records and data. Corrupted, inconsistent, and unreadable records are erased. Whatever valid records remain are stitched back together to form a usable archive.
Following a repair, the archive may be missing files or metadata. But all of the files remaining in the archive have been verified to be complete and undamaged. The folders and layers that have missing files are indicated as "repaired" in the browser.
The repair command offers a variety of options that affect how the archive is repaired. Under most circumstances, accept the default settings.
An archive is normally auto-repaired at the beginning of any command or action. Auto-repairing the archive (if possible) will allow the full repair to work more smoothly.
There are rare cases where auto-repair may interfere with the repair. If you are unable to repair an archive, QRecall support may instruct you to turn the Use auto-repair information option off.
If you suspect that the archive needs only to be auto-repaired, don't perform the repair command. Every (non-repair) action will first auto-repair the archive before it starts. The simplest method to test if auto-repair will do the trick is to open and verify the archive; if you can do that, the archive doesn't need a full repair.
When layers are merged, older and deleted item records are not immediately erased; they are simply abandoned. A subsequent compact action will scour the archive, identify all of the file records that no longer belong to any layer, and erase them—a process known as garbage collection.
The repair command normally performs the same garbage collection. If, however, one or more folder records are damaged, the files those folders contained will appear to be abandoned file records and will be erased along with the rest of the garbage. (Note that subfolders of a damaged folder are reconstructed using redundant information, so subfolders aren't affected by garbage collection.)
If the Recover lost files option is set, abandoned file records are not erased. Instead, they are reassigned to a special "Recovered" owner & volume, which will appear in the archive when the repair is complete. You can then browse and recall these files as needed.
Once you've restored the lost files you were interested in, you can delete the special "Recovered" owner.
Files in an archive consist of a file record and one or more data (quanta) records. A file record that is missing data records is considered to be damaged and is normally erased; the incomplete file is logged, and the folder that contained the file is marked as "repaired."
If you set the Recover incomplete files option, those damaged files will be retained and marked as "damaged" in the archive.
Note: this is a pretty desperate option. Damaged files are almost always unusable, as they will be missing an undetermined amount of data. For some file types, like plain text, this can still recover a significant amount of usable information.
This option determines how the archive's redundant data is repaired. (If the archive does not store redundant data, this option is ignored.)
The capture action includes special logic that forces the re-capture of any "suspicious" items found during the repair.
Following up a repair with a capture will ensure the archive has up-to-date copies of all your files and folders.
A recover reads an existing archive and uses whatever data is readable to construct a new archive. Use recover when the existing archive's media, volume, or device is failing, is unreliable, or can't be written to.
Recover also allows you to experiment with different repair options, without erasing any data in the existing archive.
When you start the recover, QRecall will prompt for the name and location of the new archive. This should be stored on a reliable volume with enough free space to hold the recovered data. The settings you choose here will also determine the amount (if any) of redundant data in the recovered archive.
These are the same options used by repair.
This option determines how the original archive's redundant data is treated. Normally, the archive's redundant data is used to correct any corrupted or unreadable data. Set this option to disable data correction.
Filesystems—like the Mac OS Extended file system used by macOS—are wonders of modern software engineering. They are blindingly fast and efficient, allowing us to quickly store and access the mountains of data we use on a daily basis.
But as great as they are to use, they are lousy for protecting your data. They have no means of determining if your files have been damaged or overwritten. They use hierarchical data structures that can misplace an entire folders worth of items if just one directory record is destroyed.
A QRecall archive, by contrast, is organized quite differently and has contrasting goals. The structure of an archive is fanatically protective of data; every single byte of information is verified by a checksum, every record is subjected to a battery of interlocking consistency tests (and these checks are tested every time the record is read). Layer, folder, and file records all contain redundant information, so the loss of one record won't sacrifice any more data than what was contained in that one record.
In addition, QRecall offers data redundancy which can be used to reconstruct small amounts of lost data. While some filesystems (ZFS, RAID5, and so on) offer similar error detection and correction, is it not a feature of most filesystems.
In other words, if the macOS filesystem is a convenience store, a QRecall archive is a bank vault, with guards, surrounded by barbed wire, and a moat.
The records in an archive are self-contained, reducing the "domino effect" of data loss where damage to one record destroys the context of other records.
Think of archive records like little islands. The index files in the archive link the records together, like bridges joining the islands, allowing you to navigate them as though they were a single land mass.
If some natural disaster occurs and some of the island are lost, the remaining islands can be linked together again with new bridges. Similarly, if archive records are damaged—and it doesn't matter how many are lost—the remaining records can be stitched back together to form a usable archive. That's the repair process in a nutshell.
This is what makes QRecall archives so robust. Regardless of how much data in an archive is lost due to physical media failure, destructive writes, or data corruption, the balance of the archive can always be reassembled into a usable archive again.
In broad terms, repairing an archive involves the following steps:
Recover changes this somewhat: