A backup you can't restore is worthless

Every backup tool on earth will happily tell you the backup “succeeded.” What almost none of them tell you is whether that file would actually come back to life if you needed it. A truncated archive, a silent corruption, a storage bit-flip, a backup of a half-broken configuration — they all report green. You find out the truth on the worst possible day, when a customer's phone system is down and you're watching a restore fail.

For an MSP, that is the nightmare: the one moment your client is judging you, and the safety net you sold them tears. So we built Sikurd's Verified Backups around a single, uncomfortable question — does this backup actually restore? — and we answer it with evidence, not assurances.

A backup you can't restore is worthless. So on a rotating schedule we take a real backup and actually restore it onto a throwaway server that's completely sealed off from the internet and from your live system — nothing about the test can touch your real PBX. We confirm the restore completed, count what came back, and issue a tamper-evident certificate with a unique ID and a public verification page. Your IT provider is emailed every result, pass or fail.

Three layers of verification

Verification isn't one check — it's three, each one stronger than the last. The first two run on every backup, continuously. The third — the real proof — runs per instance on a rotating schedule.

1. Integrity check — at capture

The moment a backup is taken, Sikurd records its exact size and computes a SHA-256 checksum— a cryptographic fingerprint of the file. That fingerprint becomes the reference every later check is measured against. If a single byte changes anywhere downstream, the fingerprint won't match.

2. Archive check — always on

This one runs continuously. Sikurd streams the backup back out of immutable cloud storage, re-computes its SHA-256, and confirms it still matches the fingerprint from capture. Then it validates the ZIP structure end to end — every entry, the central directory, the whole archive — so a file that is whole on the outside but corrupt on the inside can't slip through. This is what proves your backup is complete and untampered, every single day, without ever touching production.

3. Restore test — the real proof, on a rotating schedule

A checksum proves the file is intact. It does not prove the file will restore. Only one thing proves that: restoring it. So on a rotating schedule, Sikurd takes a real backup and actually restores it onto a brand-new, air-gapped server cloned from a golden 3CX image. It runs the official 3CXRestoreCmd, confirms from the restore log that the restore completed, then reads the restored system back and counts what's inside — calls, recordings, extensions, trunks, queues and routing rules. That run becomes a certificate.

• Integrity check — every backup, at capture

  Size and SHA-256 fingerprint recorded the instant the backup is taken.
• Archive check — every backup, continuously

  Streamed back from immutable storage, re-hashed, and the ZIP validated end to end. Proves the file is whole and untampered.
• Restore test — on a rotating schedule

  The backup is actually restored onto a sealed, throwaway server and the contents are counted. The real proof that it works.

That's the honest framing we hold ourselves to: continuously verified, and restore-tested on a rotating schedule — roughly every 30 days per instance. Any vendor that claims to fully restore-test everybackup is either redefining “restore” or stretching the truth.

How the restore test actually works

The restore test is deliberately paranoid, because the whole point is to be able to trust the result. Here is exactly what happens, and — just as importantly — what never happens.

A brand-new, air-gapped server every time

Sikurd spins up a fresh server cloned from a golden 3CX image — a known-good baseline. It is air-gapped: sealed off from the public internet and from your production network. Your real PBX is never contacted, no devices are registered, and not a single call is placed. When the test ends, the throwaway server is destroyed. Nothing about the test can reach, change, or disrupt your live system.

The official 3CX restore — judged by the log

On that isolated machine, Sikurd runs the official 3CXRestoreCmd — the same restore tool 3CX itself ships — and watches the restore log for the markers that mean the restore finished. Then it reads the restored data back and counts it against what your production footprint should be.

What you get: a certificate, not a checkbox

Every restore test produces a tamper-evident certificate with a unique verification ID and a public page anyone can open. Your IT provider is emailed the result — pass or fail — every time. Here is a real example of what one looks like:

The certificate shows the instance, the 3CX version it ran, when the backup was created and when it was restore-tested, how long the restore took, the backup size, and the full archive SHA-256. The data-set table lists what was counted — call records, recordings, extensions, trunks, queues, ring groups and inbound rules — production against what came back from the backup. The integrity line shows the hash chain resolving to AUTHENTIC, and the QR code opens the live verification page.

Honest by design

We're careful about what a certificate claims. Call-history and recording counts are read straight from the backup's own data. Configuration counts — extensions, SIP trunks, call queues, ring groups and inbound rules — are certified as of the backup date, because the configuration inside a 3CX backup is encrypted and represents the moment the backup was taken. If production has legitimately changed since, the certificate shows a neutral result rather than a misleading mismatch. The numbers on a Sikurd certificate mean exactly what they say.

The technology behind the trust

Verified Backups is built on infrastructure chosen specifically so the proof holds up to scrutiny:

• Immutable Backblaze B2 storage.Backups land in object-locked, immutable storage — they can't be silently overwritten or deleted, including by ransomware that compromises a connected system.
• Per-tenant AES-256-GCM encryption.Every tenant's backups are encrypted with their own key using authenticated AES-256-GCM, so data is unreadable at rest and tampering is detectable.
• SHA-256 fingerprints. Each backup carries a cryptographic checksum recorded at capture and re-verified continuously from immutable storage.
• Air-gapped restore VM. The restore test runs on a sealed, throwaway server cloned from a golden 3CX image — never connected to your live PBX or the public internet.
• Cryptographic hash-chained certificates. Each certificate links to the one before it for that instance. Alter a single character of any stored field and the chain breaks — the public page recomputes the hash live and flips the badge to FAILED.

Verified Backups is part of the Sikurd platform — one console to monitor, manage and verifiably back up every 3CX server in your fleet, billed simply per instance. See how pricing works, or read the rest of the 3CX fleet-management landscape.