Manual verification with the OpenTimestamps client

You can check integrity.json.ots independently of T3Vault using the official OpenTimestamps command-line client. Combined with a hash check of the backup artefacts, this answers: has anything in this backup been changed since it was sealed?

Upstream project: opentimestamps-client.

For the recommended overall flow, see How to verify a backup (recommended).

Install the client

Python package (typical on Debian/Ubuntu):

sudo apt install pipx
pipx install opentimestamps-client
# or: pip install opentimestamps-client

Confirm the binary:

ots --help

What was stamped?

T3Vault stamps only integrity.json (not the ZIP files themselves). The ZIP digests are listed inside integrity.json. Therefore:

Confirm artefact hashes still match integrity.json (re-hash yourself or use Verify with T3Vault CLI).
Confirm integrity.json.ots is a valid OpenTimestamps proof for that exact integrity.json file.

Always keep integrity.json and integrity.json.ots side by side in the same directory (the ots client assumes the target file name by stripping .ots).

Check that files were not modified

Independently of ots, confirm that backup artefacts match the seal:

cd /path/to/backup_YYYYMMDD_HHMMSS_<id>
sha256sum integrity.json
# Compare with digests listed under "files" in integrity.json, e.g.:
sha256sum database.zip MANIFEST.json *_part_*.zip

If any artefact hash differs from integrity.json, the archive was modified after sealing — do not restore it, regardless of OTS status.

Prefer the bundled verifier for the same check:

php t3vault-verify.phar /path/to/backup_YYYYMMDD_HHMMSS_<id>

Verify the OpenTimestamps proof

ots verify checks that integrity.json still matches the proof and (when Bitcoin Core RPC is available) that the attestation is anchored in a Bitcoin block:

cd /path/to/backup_YYYYMMDD_HHMMSS_<id>
ots verify integrity.json.ots

Expected success:

Assuming target filename is 'integrity.json'
Success! Bitcoin block <height> attests existence as of <date>

Pass the target explicitly if needed:

ots verify -f integrity.json integrity.json.ots

Inspect the proof without a Bitcoin node:

ots info integrity.json.ots

Without installing ots, you can also use the browser verifier — see Verify in the browser (opentimestamps.org).

Verify in the browser (opentimestamps.org)

The official site opentimestamps.org can verify an .ots proof without Bitcoin Core or the ots CLI. Hashing runs in your browser (the stamped file content is not uploaded for hashing beyond what the page needs locally).

Steps:

Open the backup directory and keep both files ready: integrity.json and integrity.json.ots.
Open https://opentimestamps.org/ and use Stamp & Verify.
Drop (or select) integrity.json.ots as the proof (.ots).
Drop (or select) integrity.json as the stamped file when the page asks for it.

A successful chain confirmation shows the OpenTimestamps UI label Bitcoin Attestation (block / time). Pending calendars may still show Pending/Other Attestation until the proof is confirmed on the Bitcoin blockchain.

What to watch out for

Only integrity.json was stamped — never drop a ZIP, MANIFEST.json, or the whole .t3vault.tar as the stamped file. Those will not match the proof.
Use the exact integrity.json from the same backup as the .ots file. Any edit (whitespace, re-save) changes the digest and verification fails.
The website checks the seal (integrity.json ↔ .ots). It does not re-hash *_part_*.zip / database.zip. Always run Verify with T3Vault CLI (or the manual hash check above) as well if you need to know the archive contents were not modified.
Right after backup creation the proof may still be pending. That is not the same as “tampered”; wait for calendar → Bitcoin confirmation and try again, or rely on the hash check in the meantime.
Do not use the site’s stamp action on backup files — T3Vault already created the proof. You only need verify.

Bitcoin node for `ots verify`

Full CLI ots verify needs Bitcoin Core RPC (local node or remote URL). Without it you typically see:

Could not connect to Bitcoin node: Cookie file unusable
([Errno 2] No such file or directory: '/home/…/.bitcoin/.cookie')
and rpcpassword not specified in the configuration file: '…/bitcoin.conf'

That error means the Bitcoin-blockchain time stamp was not checked — it does not mean the backup files were modified. For the “unchanged files” question, rely on the hash check / Verify with T3Vault CLI. For the seal without a local node, use Verify in the browser (opentimestamps.org).

Local Bitcoin Core (default cookie auth under ~/.bitcoin/):

# bitcoind must be running and synced far enough for the attested height
ots verify integrity.json.ots

Explicit RPC URL (local or remote):

ots --bitcoin-node http://USER:PASS@127.0.0.1:8332/ verify integrity.json.ots

Recommended independent workflow

Open the backup directory (from .t3vault.tar if needed).
Confirm artefact SHA-256 digests match integrity.json (php t3vault-verify.phar . or manual sha256sum).
Optionally confirm the seal: Verify in the browser (opentimestamps.org), or ots verify with Bitcoin Core RPC.

This proves content integrity (hashes). The OTS step additionally proves the seal existed at a point in Bitcoin-blockchain time, without trusting the original TYPO3 server.

Troubleshooting

Symptom	Meaning / next step
Hash mismatch vs. `integrity.json`	Archive altered — do not restore
Web verifier: stamped file does not match	Wrong file dropped — use `integrity.json` from the same backup
Web verifier: pending / no chain time stamp yet	Proof not on-chain yet; hashes may still be OK
`Could not connect to Bitcoin node` / missing	Use
`.cookie`	Verify in the browser (opentimestamps.org) or configure RPC
`ots` not found under `sudo`	`pipx` installs for your user only — run without `sudo`