Preservation guide 03

Fixity: knowing nothing has changed

How a checksum proves a file is exactly what it was, and how Lazarus checks all 3.1 petabytes of the archive, continuously.

What fixity means

An archive must be able to say of anything it holds that it has not changed since it arrived, not by a single bit. That property is called fixity, and it is checked with a checksum: a short value calculated from every bit of a file. Change one bit and the checksum changes completely.

Nothing important has to fade away.

b8f9188ac4d28d24bfbe529e558d02207f5039e5ef3ea3742d73f4bb27daf4d4

nothing important has to fade away.

121f1952a3d3057ab3bddfa7fdc1e12a5eac018799c1bf0a57cf4606393ced9c
The same sentence with its capital letter made lower case, a difference of one bit. 59 of the 64 characters in its checksum are different.

SHA-256

Lazarus uses SHA-256, which produces a value 64 characters long, and every record in the catalog shows it. Older objects were also checksummed with MD5 or SHA-1 when they arrived. Those values are kept, and still checked, because they are part of each object’s history.

An extract from Vigil’s log. Each line is a complete re-read of the object and a comparison with the checksum recorded when it arrived.

Vigil

Every object in the archive is re-read and re-checked on a rolling schedule by Vigil, the archive’s fixity service. Vigil never stops. It works through the whole archive and then begins again, and a full pass of 3.1 petabytes takes about eleven weeks.

When the archive’s search index moved to new storage in August 2026, Vigil also made an extra pass over every object touched by the move. It found no mismatches. The incident is recorded on Frothly’s status page.

Three copies, two kinds of storage, two cities

Every object is kept in three copies: two in Vancouver, on different kinds of storage, and one at a partner site a long way away. When Vigil finds a copy that no longer matches its checksum, this is what happens:

  1. The mismatch is logged, and the copy is taken out of use.
  2. The other two copies are checked. If both match, one of them is used to replace the damaged copy.
  3. The replacement is checked again, and the event is added to the object’s preservation history.
  4. The storage that failed is examined, and retired if the fault could recur.

For an object to be lost, the same damage would have to appear in all three copies before Vigil next looked. In thirty-two years, it has not happened.

Doing it at home

Checksums are not only for archives. Most operating systems can calculate a SHA-256 value with a single command, and that is enough to look after a family collection.

Windows
In PowerShell: Get-FileHash photo.jpg. It shows the value in capitals, which makes no difference.
macOS
In Terminal: shasum -a 256 photo.jpg
Linux
In a terminal: sha256sum photo.jpg
  • Keep a list of checksums for your important files, stored alongside them.
  • Check the list once a year, at the same time as you check your backups.
  • If a file no longer matches and you have not changed it, restore it from another copy, and find out what happened.

The rest of a sensible plan is in Your own digital archive.

Check a file here