Self-hosting

Backups

What DDM backs up itself, what else you should back up and how to restore a backup.

What DDM backs up itself

Before every update, the CMS backs up the database – under /data/backups on the volume, or in the S3 bucket if one is set. The last three backups are kept.

This does not replace a backup of your own: these backups live on the same server.

What you should back up

  • The database, regularly and on another system. You take a backup by hand with:
    docker compose exec cms bun run db:backup
    
  • The documents – the ddm_data volume (with Kubernetes ddm-data) or the bucket, with your platform's tools: snapshots, a copy to a second bucket.
  • .env, or config.env and secrets.env – without BETTER_AUTH_SECRET, stored credentials (directories, external sources) can no longer be read.

Restoring

This shows the backups DDM knows about:

docker compose exec cms bun run db:restore

You restore the newest one with:

docker compose exec cms bun run db:restore latest --yes

Before that, DDM backs up the current state, so a restore can be undone too. Afterwards the database is exactly as it was when it was backed up; files uploaded since then stay where they are, but no longer belong to any document.

With Kubernetes, run the same commands with kubectl -n ddm exec deploy/cms -- bun run ….