CyberSygn Backup and Recovery: The Honest Version

Most backup pages tell you what a system promises. This one tells you what CyberSygn actually has, which is less than you would probably guess.

Backups are the thing nobody thinks about until something breaks, and by then a vague promise is worse than no promise at all. So here is the state of CyberSygn backup on the day you are reading this: there is no automated backup running. A daily export job is written and sitting in the codebase, but no storage bucket is attached to it, so it has never executed once. Your documents live in encrypted Cloudflare KV under a thirty-day timer, and nothing is copied anywhere else. Over the next two minutes you will see exactly what that covers, what it does not, and the two habits that give you a recovery story you actually control.

What Actually Exists Today

Let me give you the whole inventory, because it is short. Every document record, every signer state, and the signed PDF and audit certificate all live in **Cloudflare KV**, encrypted at rest, each carrying a **thirty-day expiry** measured from the last write. Cloudflare replicates KV internally so the service stays available, and that is worth having, but it is Cloudflare keeping its own store online rather than CyberSygn holding a second copy of your contract on your behalf. Those two things are easy to blur and they are not the same. One thing is permanent. When a document completes, CyberSygn writes a verification record keyed by the SHA-256 fingerprint of the signed document, with no expiry. It stores the fingerprint, the signer count, and the created and completed timestamps, and nothing else: no name, no email, no content. That record is what lets you prove a saved PDF is the file that was signed, long after the thirty days have run out. That is the complete list. There is no object archive, no nightly export, and no restore procedure, because today there is nothing to restore from.

The Job That Has Never Run

I would rather you read this here than discover it. There is a scheduled function in the codebase that would, at 03:00 UTC, walk the KV namespace and write every entry into a dated file in object storage. It is real code. What it does not have is a bucket bound to the Worker, so the first thing it does on every invocation is report that storage is unbound and stop. It has never written a byte. Even once a bucket is attached, it would not cover the files you care about most. The list of key prefixes it walks does not include the namespace that holds signed PDFs and audit certificates, so those would sit outside the export until that list is fixed too. An earlier version of this page described that job as running nightly and described your signed documents as mirrored across data centers forever. Both claims were false. If and when the bucket is attached and the prefix list is corrected, this page changes, and the change ships with the feature rather than ahead of it.

The Two Habits That Give You a Real Recovery Story

So what should you actually do? Two things, and neither takes a minute. First, **download the signed PDF and the audit certificate the day a deal closes.** Your dashboard links both as soon as the last signer finishes, and the completion email carries the same links. Filed alongside the rest of that client's paperwork, your copy becomes the authoritative one and the thirty-day window stops being a risk you are carrying. Second, **keep the pair together.** The PDF is the contract; the audit certificate is the record of who signed it, when, and from where, and it carries the fingerprint. If a dispute ever arrives, paste that fingerprint into the checker at /verify/ and the permanent record confirms the document completed, with the signer count and the timestamps. That still works long after the document record itself has expired, which is the whole reason the fingerprint is kept permanently and the file is left with you. Between those two habits you have a recovery story that depends on nothing CyberSygn has not built yet, which is the only kind worth relying on.