Backups

Slick keeps everything in two places: a SQLite database and a files directory. Back up both, and do not copy the database file while the server is running.

The database

node dist/index.js backup /backups/slick-$(date +%F).db

This takes a consistent online snapshot with VACUUM INTO, which is safe while the server is serving. Copying slick.db directly is not, because the write-ahead log may hold committed data the main file does not have yet.

In Docker:

docker exec slick node dist/index.js backup /data/backup.db
docker cp slick:/data/backup.db ./slick-$(date +%F).db

The files

rsync -a ./data/files/ /backups/files/

Take the files copy after the database snapshot. In that order a restored backup may reference a file that was uploaded after the snapshot, which shows as one broken attachment. The other order loses the file for a message that exists, which is worse and harder to spot.

Restoring

Stop the server, put the database at DATA_DIR/slick.db, put the files back at DATA_DIR/files, and start it. There is no import step, because there is no format other than the one on disk.

Rehearse this once, on a machine that is not the production one, before you need it. A backup you have never restored is a hypothesis.

On Postgres

backup is SQLite only. Use pg_dump for the database and the same rsync for files.