Backup

Regular backups are essential for protecting your POS data. This guide covers backup strategies for both HQ and store databases, automated scheduling, and restoration procedures.

PostgreSQL Backup with pg_dump

The primary backup method is pg_dump, which creates a consistent snapshot of the database. For the HQ database:

pg_dump -h localhost -U pos -d pos_hq -F custom -f backup_hq_$(date +%Y%m%d_%H%M%S).dump

For a store database:

pg_dump -h localhost -U pos -d pos_store -F custom -f backup_store_$(date +%Y%m%d_%H%M%S).dump

The -F custom flag produces a compressed, custom-format dump that supports selective restoration. Each backup file is timestamped to avoid overwriting previous backups.

Automated Backups with Cron

Set up a cron job to run backups automatically. Edit the crontab with crontab -e and add:

# HQ database backup at 2:00 AM daily
0 2 * * * pg_dump -h localhost -U pos -d pos_hq -F custom -f /backups/hq/backup_$(date +\%Y\%m\%d_\%H\%M\%S).dump

# Retain only the last 30 days of backups
0 3 * * * find /backups/hq -name "*.dump" -mtime +30 -delete

Create the same pattern for each store database. Ensure the /backups directory has sufficient disk space and is on a separate physical drive or network mount from the database data directory. Backups on the same drive as the database offer no protection against hardware failure.

Offsite Backup

For disaster recovery, copy backups to an offsite location. You can use rsync, scp, or a cloud storage tool like rclone:

# Sync backups to a remote server
rsync -az /backups/hq/ backup-server:/pos-backups/hq/

# Or upload to S3-compatible storage
rclone sync /backups/hq/ s3remote:pos-backups/hq/

Schedule offsite transfers to run after the local backup completes. For critical HQ data, consider running offsite transfers daily. Store backups can be transferred less frequently since transaction data also syncs to HQ.

Restoring from Backup

To restore a database from a custom-format dump:

# Drop and recreate the database
dropdb -h localhost -U pos pos_hq
createdb -h localhost -U pos pos_hq

# Restore the dump
pg_restore -h localhost -U pos -d pos_hq backup_hq_20260310_020000.dump

After restoring, restart the HQ server or store server to reconnect to the database. For store databases, a restore may trigger a re-sync of data that was generated after the backup was taken. The sync engine handles this automatically by comparing timestamps.

Best Practices

• Test your backups regularly. Restore a backup to a separate database and verify the data is intact. A backup that has never been tested is not a backup.
• Back up before upgrades. Always take a manual backup before applying system updates or database migrations.
• Monitor backup size. A sudden decrease in backup file size may indicate a problem. Set up alerts if file sizes drop below expected thresholds.
• Encrypt sensitive backups. If backups contain customer data subject to privacy regulations, encrypt the backup files before transferring them offsite. Use gpg or your organization's approved encryption tool.