Backup & Disaster Recovery

Truetask includes automated backups, manual backup creation, and optional S3 offsite storage — built for enterprise environments where data loss is not an option. This guide covers backup scheduling, restore procedures, and disaster recovery planning.

Automated backups

By default, Truetask creates a backup every day at 4:00 AM and keeps the last 7 backups. This is configured during initialization and can be changed in Settings > Server > Backups.

Schedule configuration

The backup schedule uses cron syntax with five fields:

Field	Allowed Values	Example
Minute	0-59, *, */N	0 (on the hour)
Hour	0-23, *, */N	4 (4 AM)
Day	1-31, *, */N	* (every day)
Month	1-12, *, */N	* (every month)
Weekday	0-6, *, */N	* (every day)

Common schedules:

Schedule	Cron	Description
Daily at 4 AM	0 4 * * *	Default — good for most teams
Every 6 hours	0 */6 * * *	Higher frequency for active teams
Every 12 hours	0 */12 * * *	Twice daily
Weekly (Sunday 3 AM)	0 3 * * 0	Low-activity instances

Retention policy

The Max Keep setting controls how many backups are retained. Older backups are automatically deleted when a new one is created. Set to 0 to keep all backups (not recommended — disk usage will grow indefinitely).

Recommended retention

Keep at least 7 backups for daily schedules, or 14 for twice-daily. This gives you a week of recovery points.

Manual backups

Create a backup at any time from Settings > Server > Backups by clicking Create Backup. Manual backups are named manual_YYYYMMDDHHMMSS.zip and count toward the retention limit.

Create a manual backup before:

• Major configuration changes
• Bulk data imports or deletions
• Version upgrades

What's included in a backup

Each backup is a ZIP file containing:

Component	Included	Notes
Database (SQLite)	Yes	All collections, records, settings
Uploaded files	Yes	Attachments, avatars, cover images
Hooks & migrations	No	Part of the application code, not data
Environment variables	No	Stored outside PocketBase

S3 offsite storage

For production deployments, configure S3-compatible storage to automatically store backups offsite. Once enabled, all backups (automatic and manual) are stored in S3 instead of local disk.

See the S3 Storage guide for setup instructions and compatible providers.

WARNING

When S3 backup storage is enabled, backups are stored only in S3, not locally. Ensure your S3 bucket has its own versioning or lifecycle policy as a safety net.

Restore procedure

Before you start

• Access to the backup ZIP file (download from UI or S3)
• Access to the server filesystem (SSH or Docker exec)
• The Truetask application stopped

Step-by-step restore

1. Stop the application

cd truetask
./truetask-stop.sh

2. Back up the current state (safety net)

cp -r data/pb_data data/pb_data_pre_restore_$(date +%Y%m%d)

3. Extract the backup

# Remove current database files
rm -f data/pb_data/data.db data/pb_data/data.db-shm data/pb_data/data.db-wal
rm -f data/pb_data/auxiliary.db data/pb_data/auxiliary.db-shm data/pb_data/auxiliary.db-wal

# Extract backup (contains data.db and storage/ directory)
unzip backup_file.zip -d data/pb_data/

4. Restore uploaded files

If the backup includes a storage/ directory, it contains all uploaded files:

# The unzip above should place storage/ in the correct location
# Verify it exists:
ls data/pb_data/storage/

5. Start the application

./truetask-start.sh

6. Verify the restore

• Log in to the application
• Check that boards, tasks, and files are intact
• Verify the data matches the expected backup point in time

Disaster recovery scenarios

Scenario 1: Corrupted database

Symptoms: Application errors, blank pages, 500 errors on API calls.

Recovery:

1. Stop the application
2. Download the most recent backup from S3 or local storage
3. Follow the restore procedure above
4. Data between the last backup and the corruption event is lost

Scenario 2: Accidental data deletion

Symptoms: Missing boards, tasks, or lists.

Recovery:

1. Identify which backup predates the deletion (check backup dates in Settings)
2. Download that specific backup
3. Follow the restore procedure
4. Alternatively, if the deletion was recent, check if the data is archived (Settings > Audit Log can confirm when the deletion occurred)

Scenario 3: Server failure / migration

Recovery:

1. Provision a new server with Docker
2. Run the installer to set up a fresh instance
3. Run the setup wizard with the same configuration as the original
4. Stop the services: ./truetask-stop.sh
5. Download the latest backup from S3
6. Place the backup contents in data/pb_data/
7. Start the services: ./truetask-start.sh

Scenario 4: Ransomware / compromised server

Recovery:

1. Do NOT use local backups (they may be compromised)
2. Provision a clean server
3. Download the last known-good backup from S3
4. Follow Scenario 3 steps
5. Rotate all credentials (admin password, API tokens, S3 keys, SMTP password)

Best practices

1. Enable S3 backups — Local-only backups don't protect against disk failure or server compromise
2. Test restores periodically — Download a backup and restore it to a test environment quarterly
3. Monitor backup health — Check the backup status indicator in Settings to ensure backups are running on schedule
4. Keep environment config separately — Store your .env file in a password manager or separate secure location
5. Use appropriate retention — Balance storage costs against recovery needs. 7 daily backups covers most situations
6. Create manual backups before changes — Always snapshot before upgrades, bulk operations, or configuration changes
7. Secure S3 credentials — Use dedicated IAM users with minimal permissions (PutObject, GetObject, ListBucket, DeleteObject on the backup bucket only)