> ## Documentation Index
> Fetch the complete documentation index at: https://docs.collabase.ch/llms.txt
> Use this file to discover all available pages before exploring further.
> How to back up your Collabase data and restore it when needed. There is no built-in backup UI — backups are run from the command line.
# Backup
All Collabase data — pages, tasks, users, settings, automations, test cases, and uploaded files — is stored in two places: a **PostgreSQL database** and a **file storage location**. A complete backup covers both.
There is no built-in backup screen in Collabase. Backups must be created by running commands on your server or through a scheduled job. Plan for this before going into production.
Run backups daily for any production deployment. Store backup files off-server — on a network share, cloud storage, or a separate machine — so that a server failure does not destroy your backups at the same time as your data.
***
## Automatic pre-update backups
Every time you run `bash update.sh`, Collabase automatically creates a database backup in `deployment/backups/` before applying the update. These backups are kept for 7 days and then removed automatically. They are intended as a safety net for rollbacks, not as your primary backup strategy.
Pre-update backups cover the database only. Uploaded files are not included. Set up your own regular backup schedule (see below) that covers both the database and file storage.
***
## What to back up
| Data | Where it lives | How to back up |
| ------------------------------------------------------------- | ----------------------------------------- | --------------------------------------------- |
| **All structured data** (pages, tasks, users, settings, etc.) | PostgreSQL database | `pg_dump` command |
| **Uploaded files** (images, attachments) | Local filesystem or S3-compatible storage | Copy the files folder, or sync your S3 bucket |
***
## Backing up the database
### Manual backup
Run the following command on your server to create a compressed backup of the database:
```bash theme={"dark"}
docker exec collabase-postgres pg_dump -U collabase collabase | \
gzip > "backup-$(date +%Y%m%d-%H%M%S).sql.gz"
```
This creates a timestamped `.sql.gz` file in your current directory.
### Scheduled daily backup
For production systems, set up a daily automated backup using cron. Open the cron editor with `crontab -e` and add:
```bash theme={"dark"}
0 2 * * * docker exec collabase-postgres pg_dump -U collabase collabase | \
gzip > /backups/collabase-$(date +\%Y\%m\%d).sql.gz && \
find /backups -name "collabase-*.sql.gz" -mtime +30 -delete
```
This runs at 2:00 AM every night and automatically removes backups older than 30 days. Adjust the retention period to match your requirements.
***
## Backing up file storage
### Local filesystem
If files are stored locally (the default), copy the file storage directory to your backup destination:
```bash theme={"dark"}
rsync -az /var/collabase/uploads/ /backups/uploads/
```
Run this as part of the same cron job as your database backup so the two are always in sync.
### S3-compatible storage
If you use S3 or a compatible provider (Cloudflare R2, MinIO, etc.), use your provider's sync or versioning features. Enable **object versioning** in your bucket settings so previous versions of files are retained automatically.
***
## Copying backups off-server
Always store backups in a second location. Some common options:
**Cloud storage (AWS S3, Cloudflare R2, etc.)**
```bash theme={"dark"}
docker exec collabase-postgres pg_dump -U collabase collabase | \
gzip | aws s3 cp - s3://your-bucket/collabase-$(date +%Y%m%d).sql.gz
```
**Remote server via rsync**
```bash theme={"dark"}
rsync -az /backups/collabase-$(date +%Y%m%d).sql.gz user@backup-server:/backups/
```
**Network-attached storage (NAS)**
Mount your NAS share on the server and set the backup destination path to the mount point.
***
## Restoring from a backup
Restoring overwrites all current data in the database. Only proceed if you intend to roll back to a previous state. This cannot be undone.
```bash theme={"dark"}
docker compose -f deployment/docker/docker-compose.release.yml stop collabase-app
```
Replace the filename with your actual backup file:
```bash theme={"dark"}
gunzip -c backup-20260101-120000.sql.gz | \
docker exec -i collabase-postgres psql -U collabase collabase
```
Copy your file backup back to the storage location:
```bash theme={"dark"}
rsync -az /backups/uploads/ /var/collabase/uploads/
```
Skip this step if you use S3 storage — the files remain in your bucket.
```bash theme={"dark"}
docker compose -f deployment/docker/docker-compose.release.yml start collabase-app
```
Open Collabase in a browser and confirm that content, users, and settings are as expected.
***
## Testing your backups
A backup you have never tested is not a reliable backup. Perform a test restore on a separate (non-production) machine at least once a month to confirm the backup files are valid and the restore process works.
***
## Backup checklist
| Task | Recommended frequency |
| ----------------------------------------------- | --------------------- |
| Database backup | Daily |
| File storage backup | Daily |
| Copy to off-server location | Daily |
| Test a full restore on a non-production machine | Monthly |
| Review backup retention and storage space | Quarterly |