Skip to main content
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 creates two backups in deployment/backups/ before it applies the update: a database dump and, with local file storage, an archive of the uploaded files. Both are kept for 7 days and then removed automatically. They are a safety net for rollbacks, not your primary backup strategy.
deployment
backups
collabase-20261013-064318.sql.gz
collabase-files-20261013-064319.tar.gz
  • collabase-<date>-<time>.sql.gz is the database dump.
  • collabase-files-<date>-<time>.tar.gz holds attachments, avatars and shared files. With STORAGE_DRIVER=s3 there is no such archive, because the files live in the bucket.
If the database backup fails, the update stops before changing anything. If only the file archive fails, the update continues and the script warns that the database dump alone is not a complete backup.

​
Backups before database changes

Whenever a new version brings database changes, Collabase backs up the database once more, right before it applies them. This also happens when the update runs on its own at night, without update.sh. A restart without database changes takes no backup. These backups are kept inside the application’s storage, not in deployment/backups/. Collabase keeps the three most recent. To restore one, copy it out first, then restore it as described below:
If this backup or the check before it fails, Collabase does not start the new version and the database stays unchanged. Start the previous version again with bash update.sh rollback.
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

​
Backing up the database

​
Manual backup

Run the following command on your server to create a compressed backup of the database:
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:
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:
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.)
Remote server via rsync
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

For the full procedure, including restoring onto a new server, checking the result and what to do when a restore fails, follow the Restore runbook.
Restoring overwrites all current data in the database. Only proceed if you intend to roll back to a previous state. This cannot be undone.
1

Stop the application (keep the database running)

2

Restore the database backup

Replace the filename with your actual backup file:
3

Restore uploaded files (if applicable)

Copy your file backup back to the storage location:
Skip this step if you use S3 storage — the files remain in your bucket.
4

Start the application

5

Verify the restore

Open Collabase in a browser and confirm that content, users, and settings are as expected.

​
Trash

Before you restore a backup to get back something one person deleted, look in the trash. Go to Administration → Data & Backup → Trash. It lists deleted Spaces, projects, pages and work items, and you can filter it by type. Deleted projects and work items stay in the trash for 30 days. The list shows for each of them the date on which it is deleted for good. A maintenance job that runs every night removes the items whose date has passed. Until the job reaches an item, you can still restore it.

​
What comes back

A restored project comes back with its phases, gates and gate decisions, milestones, members, sprints, groups, status reports, web links and costs.

​
When a restore is refused

The trash tells you why it cannot restore an item instead of failing without a message: Deleting an item from the trash removes it for good. After that, only a full restore brings it back.

​
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

Last modified on October 13, 2026