Backups and upgrades

A database backup alone is not a complete recovery plan. Keep the encryption key and server agent identity with your recovery materials. Test recovery before you need it.

Know what to preserve

For the supplied Compose installation, preserve these items:

• durpdeploy-data volume: The SQLite database, including projects, releases, logs, users, and settings.
• secrets/durpdeploy_key: The matching server encryption key.
• durpdeploy-agent-identity volume: The server identity trusted by paired agents.
• Configuration: Your Compose files, environment files, public URL, and backup configuration.
• Remote agent state: Each agent’s private state directory, when you need to preserve its enrolled identity.

Keep keys and credentials separately with restricted access. Preserve older keys needed by older backups after key rotation. Script-created files on target machines need their own backup plan.

Check SQLite replication

The Compose stack uses Litestream 0.3 to replicate SQLite to your configured storage. Check its logs and uploaded data:

docker compose logs --tail=100 litestream
docker compose run --rm --no-deps litestream snapshots \
  -config /etc/litestream.yml /data/durpdeploy.db
docker compose run --rm --no-deps litestream wal \
  -config /etc/litestream.yml /data/durpdeploy.db

Make a known change in DurpDeploy, then check that uploaded WAL entries advance. An empty listing or a successful command alone does not prove that backups are current. Replication is asynchronous and can fall behind when storage is unavailable.

Do not copy only a live SQLite database file. Recent committed data can still be in its WAL file. Use the backup and restore guide for consistent backups and restore commands. PostgreSQL and SQL Server installations use their native database backup tools.

Test a restore

Restore into an isolated environment before replacing production data. Keep that environment disconnected from production agents and execution runtimes. Disable schedules and prevent outgoing notifications before starting the restored server.

Verify login, projects, releases, history, and access to encrypted settings. Test a harmless script on a disposable target. Check the identity materials needed to preserve agent trust. Use the detailed runbook for file promotion, ownership, and WAL handling.

Prepare an upgrade

1. Disable deployment and runbook schedules.
2. Finish or cancel active work.
3. Wait for agent cleanup and buffered logs to finish.
4. Record the installed version and source revision.
5. Verify backups and preserve configuration, keys, and identities.
6. Review the new version’s compatibility and migration notes.

Record software identity with these commands:

docker compose exec app /usr/local/bin/durpdeploy version
git rev-parse HEAD

Test the chosen revision against an isolated restored database first. Database migrations run automatically on startup. Do not assume an older binary can read a migrated database.

Upgrade a Compose installation

From the original checkout, fetch the source and select the revision you tested:

git fetch origin
git checkout <tested-tag-or-commit>
docker compose build app
docker compose up -d app
docker compose ps
docker compose logs --tail=100 app

Replace <tested-tag-or-commit> before running the command. Preserve your deployment files and compare them with any changed examples. Check login, agents, and a harmless deployment before re-enabling schedules. Record the installed version again after the upgrade.

If startup fails, keep schedules disabled and inspect the logs. Follow the recovery guide instead of deleting volumes or generating a new key.