A dead server should never take its own backups with it. Sikurd provisions an encrypted SFTP destination per instance, so 3CX's scheduled backups stream straight offsite.
The failure mode nobody prices in
Most 3CX instances back up faithfully to their own disk. That covers a fat-fingered config change, and nothing else. The events that actually destroy a PBX, a dead VPS, a ransomware hit, a hosting account lockout, a filesystem that fills and corrupts, all take the local backup folder down with the server. The one moment you need the backup most is exactly the moment it is gone.
The standard fix is remote archiving to SFTP. The reason many MSPs never finish the job is operational: you need an SFTP server somewhere, a credential per customer, and someone who notices when uploads quietly stop. That is three ongoing chores per instance, times your whole fleet.
What Sikurd does with the click
Turn on remote storage for an instance and Sikurd provisions a dedicated SFTP user on its gateway, scoped to that instance's own prefix in encrypted object storage, then configures the PBX's remote archiving to use it. From that point, every scheduled 3CX backup lands offsite automatically. The credential is generated for you, stored encrypted, and removed when the instance goes away.
The Backups tab for one customer PBX: native schedule, offsite storage, and capture status side by side. Demo data shown.
Offsite is step one. Proof is step two.
Offsite storage answers "do we still have a backup if the server dies?" It does not answer "does the backup actually restore?" For instances where that question matters, Sikurd's managed verified backups go further: captures are restore-tested on isolated hardware and each test issues a certificate. You can see a real one here: sample restore certificate (PDF). Both layers are opt-in per instance and included in the flat price, and they compose: offsite for everything, verification for the customers who ask you to prove it.
Frequently asked questions
How is this different from configuring SFTP in 3CX myself?
Mechanically it uses the same 3CX remote-archiving feature. The difference is everything around it: Sikurd provisions the SFTP endpoint, generates and stores the credential encrypted, points the PBX at it, and keeps monitoring that backups actually keep landing. You skip standing up and patching an SFTP server, managing per-customer credentials, and discovering six months later that one PBX silently stopped uploading.
Where does the data live, and is it encrypted?
Backups stream through Sikurd's SFTP gateway into encrypted object storage, isolated per instance with its own credential and prefix. Credentials at rest in Sikurd are AES-256-GCM encrypted. When you delete an instance or your account, the SFTP user and stored data are removed as part of erasure.
Is it really included in the flat price?
Yes. SFTP remote storage is included in the per-instance price and is opt-in: flip it on for the instances you want it on, leave it off elsewhere. If you want backups that are also restore-tested with a certificate to show for it, that is the separate managed verified backups option, also opt-in.
Get every customer PBX backing up offsite this week.
One click per instance, included in the flat price. See the whole backup story, native, offsite, and restore-verified, in the live demo.
