Backup and restore

What to copy, how often, and the one thing a restore cannot recover for you.

A certificate registry is a record other people rely on. Treat its backup like a financial record rather than like a website.

What to back up

What	Why	How often
The database	Every certificate, participant, decision and audit entry. Losing it loses the registry.	Daily, and before every upgrade.
`.env`	Database credentials and `APP_KEY`. Without the key, stored SMTP credentials, two-factor/webhook secrets and optional Gumroad licence/cache cannot be read.	On every change. Keep it somewhere private.
`storage/private/`	Certificate background images and your branding assets. These are not regenerable.	Weekly, and after uploading templates or a logo.
`storage/translations/`	Your wording and email edits. Not regenerable.	Weekly, and after editing text.
`storage/certificates/`	Stored PDFs. Regenerable from approved business values with current template appearance and verification, if the background assets are retained. See stored PDF guidance.	Optional.
`storage/logs/audit-archive/`	Archived audit years, if archiving is enabled. They have left the database.	With the database.

The application files themselves need no backup: keep the package ZIP you bought.

Taking a backup

In cPanel, phpMyAdmin exports the database and the File Manager compresses storage/. From a shell:

mysqldump --single-transaction --routines --default-character-set=utf8mb4 \
  -u DB_USER -p DB_NAME > certiflow-$(date +%F).sql
tar czf certiflow-storage-$(date +%F).tar.gz storage/private storage/translations
cp .env certiflow-env-$(date +%F).txt

--single-transaction matters: it takes a consistent snapshot without locking the site while people are issuing certificates.

Test one restore before you need one. An untested backup is a hope. Restore into a second database and a copy of the folder once, and confirm you can sign in and open a certificate.

Restoring

Upload the package files, as in installation, but do not open /install.
Create an empty database and import your dump into it.
Restore .env, then correct the database name, user and password if they have changed. Keep the original APP_KEY.
Restore storage/private/ and storage/translations/, and make storage/ writable again.
Create storage/installed.lock if it is missing, or the installer will still be open. Any text in it will do.
Sign in and open /admin/diagnostics. If the address changed, update APP_URL and ALLOWED_HOSTS before telling anyone.

What a restore cannot recover

A lost APP_KEY. The database restores, but the stored SMTP password and every enrolled two-factor secret stay unreadable. Enter the SMTP password again, and have every affected user pair their authenticator again. Replace webhook secrets with receivers and remove/re-enter the optional Gumroad licence from System diagnostics.
Recovery codes already used. Each one works once. A user with none left needs an Admin to reset their second factor.
A wrong APP_URL in already delivered certificates. Links and QR codes in PDFs that have gone out were built from whatever the address was then. Keep the old address answering, or reissue.

Moving to another server

A move is a restore into a different place. Do it in this order: put the new server up with the same data, confirm you can verify a certificate on it, then change DNS. Keep APP_URL the same if the domain is not changing, and add both the old and the new host name to ALLOWED_HOSTS while DNS propagates.