Automated Database Backups: Never Lose Data Again

# Automated Database Backups: Never Lose Data Again

Data loss events are rare — right up until they happen to you. A misconfigured migration, a runaway delete query, a disk failure, a developer running a command against the wrong environment: any of these can destroy months of data in seconds. Automated backups are not optional for production databases.

Here is how to set up automated, tested, and reliable database backups on PandaStack.

1. Why Manual Backups Are Not Enough

The problem with manual backups is that they require humans, and humans forget, get distracted, and cut corners under pressure. The day you most need a backup — right after a disaster — is precisely when you discover the last manual backup was three weeks ago.

Automated backups run on a schedule without human intervention. If configured correctly, you never think about them until you need them, at which point they are there.

2. Built-in Backup Features for PandaStack Managed Databases

PandaStack managed databases (PostgreSQL, MySQL, Redis, MongoDB) include backup functionality accessible from the dashboard:

1. 1Log in to [dashboard.pandastack.io](https://dashboard.pandastack.io)
2. 2Go to Databases → select your database
3. 3Click Backups

From here you can:

• View recent automatic backups
• Trigger a manual backup (useful before major schema changes)
• Restore from a specific backup point

Configure backup retention and schedule from the database settings panel.

3. Custom Backup Cronjobs for Advanced Control

For custom backup schedules, encryption, or offsite storage, use a PandaStack cronjob with a container that runs your backup script.

PostgreSQL Backup with pg_dump

FROM python:3.12-slim

RUN apt-get update && apt-get install -y postgresql-client awscli && rm -rf /var/lib/apt/lists/*

COPY backup.sh /backup.sh
RUN chmod +x /backup.sh

CMD ["/backup.sh"]

backup.sh:

#!/bin/bash
set -euo pipefail

DATE=$(date +%Y-%m-%d-%H%M)
FILENAME="backup-${DATE}.sql.gz"

echo "Starting backup: ${FILENAME}"

# Dump and compress
pg_dump "$DATABASE_URL" | gzip > "/tmp/${FILENAME}"

# Upload to S3-compatible storage
aws s3 cp "/tmp/${FILENAME}" "s3://${BACKUP_BUCKET}/postgres/${FILENAME}"     --endpoint-url="${S3_ENDPOINT_URL}"

echo "Backup complete: ${FILENAME}"

# Clean up local file
rm "/tmp/${FILENAME}"

Environment variables for this cronjob:

DATABASE_URL=postgresql://user:password@host:5432/dbname
BACKUP_BUCKET=your-backup-bucket
S3_ENDPOINT_URL=https://your-s3-endpoint.com
AWS_ACCESS_KEY_ID=your-key
AWS_SECRET_ACCESS_KEY=your-secret

MySQL Backup with mysqldump

Replace the pg_dump line with:

mysqldump --single-transaction --routines --triggers     --host="${DB_HOST}" --user="${DB_USER}"     --password="${DB_PASSWORD}" "${DB_NAME}" | gzip > "/tmp/${FILENAME}"

4. Schedule with PandaStack Cronjobs

Create a cronjob that runs your backup container on a schedule:

1. 1Dashboard → Cronjobs → New Cronjob
2. 2Connect the GitHub repository with your backup Dockerfile
3. 3Set the schedule:

0 2 * * *    # Daily at 2am UTC
0 2 * * 0    # Weekly on Sunday at 2am
0 */6 * * *  # Every 6 hours

1. 1Add your environment variables
2. 2Click Create

5. Test Your Backups — Regularly

A backup you have never tested is a backup you cannot trust. Schedule a monthly restore drill:

1. 1Take a backup (trigger a manual backup from the dashboard or cronjob)
2. 2Restore to a test environment
3. 3Verify data integrity — run a query count, check recent records
4. 4Document the restore time (useful for RTO planning)

Make the restore drill a recurring calendar event. This is the only way to know your backups actually work.

6. Retention Policy

Not all backups need to be kept forever. A sensible retention policy:

• 7 daily backups: Keep the last 7 daily backups
• 4 weekly backups: Keep one backup per week for the last 4 weeks
• 12 monthly backups: Keep one backup per month for the last year

This gives you fine-grained recovery options for recent incidents and coarser recovery for older events.

7. Alert on Backup Failure

Set up an alert in PandaStack monitoring if your backup cronjob fails:

• Dashboard → Monitoring → Add Alert
• Alert type: Cronjob Failure
• Notification channel: email or Slack webhook

A backup that silently fails is worse than no backup at all — at least with no backup you know the risk.

Full docs: [docs.pandastack.io](https://docs.pandastack.io).