# Backup and recovery planning

Sydekyks user and operator guide. Check feature availability and release-specific installation requirements.

A database migration can make an older application image incompatible with the current data. The absence of a release-note warning does not establish that a downgrade is safe.

## ​Before an upgrade

Require a tested recovery plan for the exact source revision and image you deploy. Record the current and target image digests, migration history, database version, file-storage location, encryption key and environment configuration. Keep a pre-upgrade backup and verify that it restores into an isolated environment.

Back up the database, files and configuration together. A database dump does not include externally stored files or the encryption key needed to decrypt saved credentials. Protect backup access and retain the keys with your recovery records.

## ​PostgreSQL backup for the configuration example

The Compose example (https://docs.sydekyks.com/install/options/docker-compose) uses service postgres, database sydekyks and user sydekyks. These commands create a backup; they do not reverse migrations:

```
umask 077
mkdir -p backups
docker compose --env-file deployment/.env -f deployment/compose.yaml stop app
docker compose --env-file deployment/.env -f deployment/compose.yaml exec -T postgres \
  pg_dump -U sydekyks -d sydekyks --format=custom > backups/pre-upgrade.dump
docker compose --env-file deployment/.env -f deployment/compose.yaml exec -T postgres \
  pg_restore --list < backups/pre-upgrade.dump

```

Stop external writers and pause incoming work before taking the consistency point. Keep PostgreSQL running during the dump. Confirm each command succeeds; a created file alone is not evidence of a successful backup. Resume the application only under your upgrade or cancellation plan.

For an embedded PGLite deployment, stop the application before copying its entire configured storage directory and configuration. PostgreSQL commands do not apply to PGLite.

## ​Restoration and downgrade

Rehearse restoration on a separate deployment before an upgrade. Check account access, connected-account decryption, table records, files, mission execution and worker connectivity after restore. Disable outbound actions in the rehearsal so restored jobs do not send messages or change provider records.

A release-specific downgrade must establish which migrations can be reversed, whether any data is discarded, and how database and file versions remain consistent. The underlying source has migration rollback tooling, but this preview does not publish an untested downgrade command or a forced-migration procedure.

If the release does not supply a validated downgrade, recover the matching application image and data from the tested backup plan. Never substitute an upstream image for a Sydekyks fork merely because their version labels look similar.

## ​Recovery acceptance record

Record the release revision, backup identifier, restore environment, elapsed recovery time, data checks and approver. Release 1.0.4 acceptance included restoration of a 1.0.3 PostgreSQL backup into an isolated environment, with account, project and mission counts preserved. That check does not validate your own storage, keys or provider connections. Rehearse recovery for your deployment before upgrading.