Backups and restore

Your data is on your server, so your backups are your job. Eddyline makes the first part easy: one dump is the whole install, because attachments live in the database too.

The nightly dump #

The installer sets up a cron job that runs eddy backup every night. It writes a timestamped pg_dump -Fc file into backups/ under the install folder and keeps the newest 14. Change that with BACKUP_KEEP in .env.

Take one by hand any time:

eddy backup

eddy update always takes a backup first.

Copy it off the server #

A backup on the same disk is not a backup. Set BACKUP_HOOK in .env to a command that runs after each dump and copies the backups/ folder somewhere else. Examples:

# rclone to a bucket
BACKUP_HOOK='rclone copy /opt/eddy/backups remote:eddy-backups'

# s3 with the AWS CLI
BACKUP_HOOK='aws s3 sync /opt/eddy/backups s3://my-bucket/eddy/'

Keep a spare .env #

.env is not in the dump. Keep a copy somewhere safe, because AUTH_SECRET is needed to keep sessions and tokens valid after a restore.

Restore #

eddy restore backups/<file>

It asks for confirmation, stops the app, restores, and starts the app again. With the bundled database it recreates the database first. With an external database it restores into the existing database, because the database role often cannot create databases.

If an update fails, eddy update puts the old version back and offers to restore the backup it just took, because migrations do not roll back.

External databases #

If you run your own Postgres, your provider’s backups are usually the main ones. Turn the nightly dump off with BACKUP_NIGHTLY=false. eddy update still takes one first.