Managed Backups

Two different things protect a PBX in Sikurd, and they're easy to confuse:

• Native PBX backups are the 3CX server's own scheduled backups. Sikurd reads their status and alerts you when one fails or goes stale — see Backup status. Sikurd never changes that schedule; it just reports on it.
• Managed Backups are Sikurd's own service: we capture each enrolled PBX on a schedule, encrypt it, store it off-site in immutable storage, and then prove it can actually be restored. This page explains that service.

Managed Backups are enabled per instance. The native PBX backups keep running independently either way.

What it does

Every managed server gets an independent, encrypted, off-site copy of its PBX on a schedule — and, unlike most backup tooling, every copy is verified all the way up to a real restore. So "we have a backup" never quietly becomes "we had a backup that didn't restore" at the worst possible moment.

How it works

Each cycle runs the same pipeline:

1. Capture — Sikurd triggers a full 3CX backup on the PBX using a one-time, Sikurd-generated encryption password (never customer-supplied), so every copy is encrypted at the source and can be restore-verified.
2. Encrypt — the backup is encrypted by 3CX, on the PBX, before it ever crosses the network. The key is unique per tenant (~24 characters, well past 128-bit strength), is never stored in plain text anywhere, and is versioned so it can be rotated without orphaning older backups.
3. Store, immutably — the encrypted file is streamed to off-site object storage and written with Object Lock. It can't be overwritten or deleted before its retention date — not by an attacker with stolen credentials, and not by us. Write-once, tamper-proof.
4. Verify — Sikurd then checks the stored copy across three escalating levels (below). This is the step most backup products skip entirely.
5. Alert — if any step fails, the instance flips to Needs attention and a Backup Failed alert fires through your alert routing. A green fleet is one that's been proven recoverable — not just one that finished uploading.

The three levels of verification

Each managed backup climbs a verification ladder. You can see exactly how far each copy got on the instance's Backups tab and on the fleet-wide Managed Backups page.

• Secured — the stored copy is intact: it read back byte-for-byte and is sitting under Object Lock. The bytes are safe and tamper-proof.
• Verified — Sikurd opened the encrypted archive with your key and confirmed its internal structure is complete and readable — not a truncated or corrupt upload.
• Restore-Tested — the strongest level. Sikurd actually restores the backup onto a clean, network-isolated 3CX machine, confirms 3CX accepts it and the data lands (extensions, queues, IVRs, settings), then destroys that machine. This is proof the backup restores — not just that it exists.

A backup that reaches Restore-Tested has already been recovered end-to-end in a safe sandbox before you ever need it for real.

Why it's safe

• Encrypted before it leaves the PBX. The file is encrypted on the customer's own server with a key unique to that tenant. Sikurd stores that key sealed in a hardware-backed key manager (AWS KMS) — never in plain text — and versions it so it can be rotated without orphaning older backups.
• Immutable by design. Object Lock means write-once: stored backups can't be silently altered or deleted before their retention window. Ransomware (or a mistaken admin) can't quietly destroy the recovery copies.
• Isolation for restore tests. Restore-Tested verifications run on throwaway machines with no network access — a restored customer identity physically can't phone home, touch the live PBX, or reach the internet. The machine is destroyed the moment the test finishes.
• Off-site and independent. Backups live in storage separate from the systems that run your PBXs, so a failure or compromise of one doesn't take the other with it.
• We never see card data and never record call audio — see the Data & security FAQ and trust.sikurd.com.

What makes this different

Most backup tooling — including the "did the backup run?" checks built into many monitoring stacks — stops at the upload succeeded. That's the metric that lies: an upload can succeed while the archive is subtly corrupt, encrypted with a key nobody can find, or impossible for 3CX to ingest. You don't find out until a real outage, which is exactly when you can least afford to.

Sikurd is built on the opposite assumption: a backup isn't trustworthy until it's been restored. The Restore-Tested level does precisely that, automatically, on a cadence — so the answer to "can we recover this customer?" is already yes, with a timestamp, before anyone has to ask.

Downloading a backup

Any completed managed backup can be downloaded from the instance's Backups tab. Sikurd streams the encrypted file to you directly — never via a raw storage URL. When you restore it, 3CX prompts for the encryption password; the instance owner can reveal it from the same tab (the reveal is access-controlled and audit-logged).

Enabling or stopping Managed Backups

Enrollment is handled per instance by your Sikurd administrator. To turn Managed Backups on for a server — or to stop them for one — contact help@sikurd.com. When backups are stopped, no new copies are captured; copies already stored remain until their Object Lock retention period expires.