Skyrsoft CertOps backs up to a single file — a portable, passphrase-encrypted archive with the extension .certopsb — rather than a folder of database dumps and key exports to keep track of separately. Restoring is a matter of installing CertOps on the target machine and pointing it at that one file with the right passphrase; nothing else needs to travel with it.
What’s actually in the archive
A raw copy of the data directory would not restore on another machine, which is the reason the archive exists in this shape at all: the CA private keys are encrypted to the local machine, the Data Protection key ring that protects every field-encrypted value in the database (the server’s TLS certificate, stored ACME account keys, DNS and mail secrets, deployment credentials) is itself bound to the host, and the installation’s Site ID is machine-scoped. The archive holds all three, re-wrapped so they travel:
- The complete database — every CA, certificate, device, setting and audit log entry, plus the Site ID — as a
pg_dumpcustom-format dump. - Every in-use CA, OCSP and SCEP-RA private key, exported to PEM and re-encrypted under the passphrase you set for the archive.
- The Data Protection key ring itself, so the field-encrypted values in the restored database are readable again on the new host.
The whole archive is then encrypted as a unit — not just the keys inside it — with chunked AES-256-GCM under a passphrase-derived key. Creating one is an admin-only action from Settings → Backup, and it’s recorded in the audit log.
Restoring is offline only
Restore is deliberately not a console button — running it against a live database while the service is still serving requests would overwrite the database mid-flight, so it’s a command-line verb you run with the service stopped:
# install Skyrsoft CertOps normally first, then stop the service
$ net stop "Skyrsoft CertOps Web"
$ set CERTOPS_RESTORE_PASSPHRASE=<passphrase>
$ cd "C:\Program Files\Skyrsoft\CertOps\Server"
$ Skyrsoft.CertOps.Web.exe --restore "C:\path\to\backup.certopsb"
Restore succeeded: <N> CA key(s) re-imported (<N> skipped), SiteId=<site-id>.
Start the Skyrsoft CertOps Web service to finish
(migrations run on next normal startup).
$ net start "Skyrsoft CertOps Web"Each key is re-imported at the exact reference it was exported from, so the restored database’s own key-reference columns resolve without any further editing, and the Data Protection key ring is put back so the values it protects decrypt correctly. The restored Site ID and FQDN come back with the database, so existing agents keep connecting once DNS for that FQDN points at the new machine — their mTLS trust is pinned to the restored Agent Identity CA, not to the hostname.
Scheduled backups
Automatic backups are off by default and are turned on in server configuration rather than the console, with an interval, output directory, passphrase and retention count. If enabled without a passphrase set, the scheduler logs a warning and produces nothing — it will not write an unencrypted archive under any configuration.
Limits
There is no passphrase recovery. Anyone holding both the archive and its passphrase can restore the entire PKI, including every private key in it — store the two separately, and treat losing the passphrase as losing the backup.
Restore genuinely requires the service to be stopped, and runs from a command line on the target machine rather than through the console. It is designed for disaster recovery and migration, not as a live rollback you trigger while the server keeps serving requests.
Scheduled backups need a passphrase configured to do anything at all. An operator who enables the schedule without setting one gets silent no-op runs rather than an error, so confirm a real backup lands where you expect after turning it on.