Backup archives are encrypted with AES-256-GCM and are available only to administrators. Backups capture the database plus the on-disk key and certificate files.

What Gets Backed Up

Each backup includes projects, vaults (restricted and standard), secrets with full history, keys, certificates, access keys, permissions, users, roles, RBAC configuration, system settings, and all log types (audit, request, user, MCP).

Backup Protection

For every backup:

• The archive is encrypted with AES-256-GCM
• A manual backup generates a 256-bit key and shows it once. Each scheduled backup uses its own key. A passphrase can be used instead, and Secryn derives the AES key with PBKDF2-HMAC-SHA256 (310,000 iterations)
• The generated key stays available from Recent Operations for about 24 hours. Store it outside Secryn
• Inside the encrypted archive, private-key files are stored as plain PEM/OpenSSH data. Secryn unwraps their SECRYN-PRIVATE-V1 envelopes at backup time, so the backup key or passphrase is what protects them, and on restore they are sealed again with the restoring instance's APP_KEY. Secret values in the database dump stay encrypted with the original APP_KEY. So does any private-key envelope Secryn could not decrypt when the backup was taken. To restore, you need the backup file, its key or passphrase, and the original APP_KEY (or the same key listed in APP_PREVIOUS_KEYS) for secret values. Treat the backup key or passphrase as sensitive as your private keys themselves: anyone who has it and the backup file can read every private key in it

Manual Backups

Admins can create backups on demand. Each backup is a timestamped point-in-time archive. AES-256-GCM authenticates the ciphertext. Multiple backups can coexist.

Scheduled Backups

Automated backups support configurable frequency, execution time, and retention (keep last N backups or purge after N days). Retention rules run after each backup to prune older copies. Backup key material exposed during the workflow should be captured and stored through the same recovery process you use for manual backups.

Restore Behavior

Restoring a backup fully replaces the current database, restoring all projects, vaults, resources, users, and configuration as captured. Restores are destructive. You need the backup file, its key or passphrase, and the original APP_KEY (or the same key listed in APP_PREVIOUS_KEYS) for secret values. Private keys from the archive are sealed again with the restoring instance's APP_KEY.

Access Control & Auditing

• only admins can create, schedule, or restore backups
• all backup/restore actions are logged
• restore activity remains visible through Secryn's audit controls

Best Practices

• store backup key material securely outside Secryn
• maintain multiple restore points
• test restores in non-production environments
• treat backup files and keys as highly sensitive assets

Backups support disaster recovery for a self-hosted instance. See the security model for what the archive encrypts and what it does not.