During offloads and Backups, Silverstack compares byte by byte the source file with all of its backup copies to ensure that no file has been corrupted during the copy process. If the verification process result is positive, Silverstack is configured per default to create a hash manifest file in the main folder of each backup destination. A hash manifest contains (among other information) the path and checksum of each copied file and serves as a seal of file integrity of all copied files and folders. It allows to to ensure completeness and consistency of a backup at a later point manually or with third party applications. You can find more information about hash manifests in our blog article “Completeness of Data with Manifest Files“.
The default hash manifest in Silverstack is the Media Hash List (Classic MHL). For more information about the MHL project, you can visit its website at http://mediahashlist.org.
Silverstack 8.4 introduced support for the new ASC MHL standard. Among other useful additions, this standard allows to create and continue histories of hash manifests for many generations of file backups. For more information, please check the ASC MHL One-Sheet page. A command line tool is available via the ASC MHL GitHub repository. You can choose your preferred manifest type in the “Copy&Job” preferences.
During offload of files without existing ASC MHL history on the source volume (i.e., when offloading camera cards), a new history is created on the destination volume.
If an ASC MHL history is already on the source volume, the history is continued on the destination volume. There are some cases where an existing history cannot be continued (for example, if the hash formats of the existing history and the offload settings don’t match). In this case the fallback behavior is to start a new history on the destination.
Backing up media
During backup of already ingested material, Silverstack generally continues any existing history. Again there are some cases (for example, if clips from different cards / histories are backed up) when existing histories cannot be continued. In this case the fallback behavior is to start a new history on the destination.
- Silverstack indicates in the offload wizards if the source volume contains an existing ASC MHL history, checks if any files are missing and if a compatible checksum method is selected for offloading
- Cascading copy creates a first generation on the first run’s destionation and an additional second generation on the second run’s destination.
- There is always an option to create a new ASC MHL history on offload and backup.
- You can choose in Silverstack’s preferences if ASC MHL histories or the classic MHL manifests shall be created.
- The job detail view shows which manifest format (“ASC MHL” or the previous Classic “MHL”) has been created, and allows to reveal the manifest file in Finder.
- If during offload an existing history has a different hash format than the selected hash format in the wizard, a new history will be created without warning.
- Silverstack is currently not creating directory hashes.
- Currently there is no option to create ASC MHL collections and packing lists (“flattened” manifests).
This feature was introduced before the new ASC MHL standard was developed. ASC MHL covers many of the use cases that Sealing was initially intended for.
Since version 5.2 Silverstack is able to “seal” volumes to ensure consistency and completeness even after multiple following copy generations. Learn more about the sealing functionality in Silverstack and the verification of seals and checksums with Pomfort SealVerify from the articles Sealing Drives in Silverstack and Verifying Sealed Drives in Pomfort SealVerify.