Database Backups

DanubeData provides automatic daily backups for all managed databases, restore to a new instance for every engine, and point-in-time recovery for PostgreSQL. This guide covers backup management, restoration procedures, and best practices for disaster recovery.

Overview

Database backups are critical for:

• Disaster Recovery: Recover from hardware failures or data center outages
• Data Protection: Protect against accidental deletion or corruption
• Compliance: Meet regulatory requirements for data retention
• Testing: Create copies for testing and development
• Migration: Transfer data between environments

Automatic Backups

Default Backup Schedule

All managed databases include automatic daily backups:

• Frequency: Once per day by default; a backup policy can choose weekdays or once a week
• Time: 2:00 AM UTC by default for MySQL; PostgreSQL and MariaDB take their scheduled backup in an early-UTC window of their own; a backup policy sets the time and timezone for any engine
• Retention: 3 days by default for MySQL, 30 days for PostgreSQL, MariaDB and operator-managed MySQL. A backup policy sets 1 to 90 days, or 1 to 30 days for those three. Managed PostgreSQL also keeps continuous backups for point-in-time recovery
• Storage: Within the Falkenstein datacenter (MySQL backups additionally get a second copy in the platform backup store)
• Included: No additional cost for standard retention

Backup Process

1. Snapshot Creation: Consistent snapshot of the database is created (MySQL) or a physical backup is taken by the database operator (PostgreSQL, MariaDB)
2. Second copy: MySQL backups are copied to the platform backup store; PostgreSQL and MariaDB backups are stored in the platform's object store
3. Verification: Second copies are re-verified against the backup store every hour, and the protection label on each backup says what is there
4. Retention: Old backups automatically deleted per retention policy
5. Notification: Dashboard updated with backup status

What's Included in Backups

• All Databases: All databases within the instance
• Users and Permissions: Database users and privileges
• Configuration: Custom database parameters
• Schemas: All tables, indexes, and constraints

Note: Backups do not include application code, OS-level configurations, or files outside the database.

Backup Configuration

Adjusting Backup Schedule

Configure when backups occur with a backup policy:

1. Navigate to your database
2. Click the Backups tab
3. Choose Set your own schedule
4. Pick the time, the timezone, how often, and the retention
5. Click Save policy

Choose a time when database activity is lowest to minimize impact. Turning automated backups off keeps the policy and every existing backup until its retention ends.

Retention Period

Automated backups are retained at no additional cost: for 3 days by default on MySQL, and for 30 days on PostgreSQL, MariaDB and operator-managed MySQL. A backup policy sets any retention from 1 to 90 days, or from 1 to 30 days for those three, whose backup store keeps nothing longer. Managed PostgreSQL databases additionally keep continuous backups for point-in-time recovery. There are no paid retention tiers.

Manual Backups

Creating On-Demand Backups

Create manual backups anytime:

1. Navigate to your database
2. Click Backups tab
3. Click Create Manual Backup
4. Provide a descriptive name
5. Click Create Backup

Manual backups are created within minutes and do not count against automatic backup retention.

When to Create Manual Backups

• Before major application deployments
• Before database schema changes
• Before running data migrations
• Before upgrading database versions
• Prior to risky maintenance operations

Manual Backup Retention

Manual backups are retained separately:

• Retention: Indefinite (until manually deleted)
• Cost: Charged based on backup size (€0.073/GB/month)
• Management: Can be deleted anytime via dashboard

Restoring from Backups

Restore Options

You have two restoration options:

1. Replace the Existing Database (MySQL only)

Puts the backup's data back into the current database:

• Availability: MySQL databases only, and opened per account by the platform; PostgreSQL and MariaDB restore to a new database
• Downtime: Database will be unavailable during restore (typically 5-30 minutes)
• Data Loss: Everything written after the backup is lost; a safety backup of the current data is taken first unless you decline it
• Use Case: Recovery from data corruption or accidental deletion when a new database is not an option

2. Restore to New Database

Creates a new database instance from backup:

• No Downtime: Original database remains operational
• Separate Instance: New database with its own connection details
• Use Case: Testing, development, data analysis

Restoration Process

Replace the Existing Database

1. Navigate to your database
2. Click Backups tab
3. Select the backup and choose Replace existing
4. Keep or decline the safety backup of the current data
5. Read the data-loss cutoff in the review step
6. Type the database name to confirm
7. Follow the operation page until the database is verified running again

Warning: Everything written after the backup is lost. The safety backup is your way back.

Restore to New Database

1. Navigate to your database
2. Click Backups tab
3. Select the backup to restore
4. Click Restore
5. Choose Restore to New Database
6. Configure the new database: its name and resource profile
7. Review the server's check of the request (name, plan, storage, monthly cost and warnings)
8. Click Start restore

You land on the operation page, which follows the restore until the new database is verified running. Creation typically takes 10-20 minutes depending on size.

Point-in-Time Recovery

DanubeData supports point-in-time recovery (PITR) for managed PostgreSQL; MySQL and MariaDB restore from their backups only:

• Resolution: 1-second increments
• Window: Within the continuity window, while continuity is healthy
• How It Works: Combines the latest base backup with the archived transaction log
• Destination: Always a new database

When available to your account, the Point-in-time recovery control on the database's Backups tab lets you keep the default window, choose a shorter one, or turn point-in-time recovery off while retaining your backups. See choosing your recovery window for what is kept, how widening the window works, and why WAL archiving continues.

By default, PostgreSQL switches active WAL segments for archiving at least every 5 minutes. Set archive_timeout to 1min in a parameter group to reduce that interval to 1 minute. With healthy archiving, this limits how much recent activity is waiting to reach the backup store; the latest recoverable point also depends on archive transfer completing. Restore targets still have 1-second granularity within the healthy continuity window.

Using Point-in-Time Recovery

1. Navigate to the Backups tab and click Restore
2. Choose A moment in time in the first step and enter it in your local time; the wizard shows the UTC equivalent
3. Name the new database and pick its plan
4. Review the check and click Start restore

Example: If you accidentally deleted data at 3:45 PM, you can restore to 3:44 PM.

Backup Verification

Testing Backups

Regularly test backups to ensure they work:

1. Monthly Tests: Restore a backup to new database
2. Verify Data: Check that data is intact and accessible
3. Test Application: Connect application to restored database
4. Document Results: Keep records of test results
5. Cleanup: Delete test database after verification

Backup Integrity

What the platform verifies automatically today:

• Second copies: MySQL backup copies are re-verified against the backup store every hour, and a copy that disappeared or failed is flagged on the backup and, with a backup policy that requires a second copy, in your team's notifications
• Operator backups: PostgreSQL and MariaDB backups are reported with the status their operator gives them
• Restore tests: Not yet automated — restoring to a new database is the reliable test, and every restore records a health verification before it counts as successful

External Backups

In addition to automatic backups, you can create external backups for additional redundancy.

PostgreSQL Export

Using pg_dump

# Export entire database
pg_dump -h db-postgres-123456.danubedata.ro \
  -U admin \
  -d danubedata \
  --format=custom \
  --file=backup.dump

# Export with compression
pg_dump -h db-postgres-123456.danubedata.ro \
  -U admin \
  -d danubedata \
  --format=custom \
  --compress=9 \
  --file=backup.dump.gz

# Export specific schemas
pg_dump -h db-postgres-123456.danubedata.ro \
  -U admin \
  -d danubedata \
  --schema=public \
  --format=custom \
  --file=public_schema.dump

# Export specific tables
pg_dump -h db-postgres-123456.danubedata.ro \
  -U admin \
  -d danubedata \
  --table=users \
  --table=orders \
  --format=custom \
  --file=tables.dump

Import PostgreSQL Backup

# Restore from dump
pg_restore -h db-postgres-123456.danubedata.ro \
  -U admin \
  -d danubedata \
  --clean \
  --if-exists \
  backup.dump

# Restore specific table
pg_restore -h db-postgres-123456.danubedata.ro \
  -U admin \
  -d danubedata \
  --table=users \
  backup.dump

MySQL/MariaDB Export

Using mysqldump

# Export entire database
mysqldump -h db-mysql-123456.danubedata.ro \
  -u admin \
  -p \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  danubedata > backup.sql

# Export with compression
mysqldump -h db-mysql-123456.danubedata.ro \
  -u admin \
  -p \
  --single-transaction \
  danubedata | gzip > backup.sql.gz

# Export specific tables
mysqldump -h db-mysql-123456.danubedata.ro \
  -u admin \
  -p \
  danubedata users orders > tables_backup.sql

# Export structure only (no data)
mysqldump -h db-mysql-123456.danubedata.ro \
  -u admin \
  -p \
  --no-data \
  danubedata > schema.sql

Import MySQL/MariaDB Backup

# Import SQL file
mysql -h db-mysql-123456.danubedata.ro \
  -u admin \
  -p \
  danubedata < backup.sql

# Import compressed backup
gunzip < backup.sql.gz | mysql -h db-mysql-123456.danubedata.ro \
  -u admin \
  -p \
  danubedata

Automated External Backups

Create a cron job for regular external backups:

#!/bin/bash
# /home/user/scripts/backup_database.sh

# Configuration
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backups/database"
DB_HOST="db-postgres-123456.danubedata.ro"
DB_USER="admin"
DB_NAME="danubedata"

# Create backup
pg_dump -h $DB_HOST -U $DB_USER -d $DB_NAME \
  --format=custom \
  --file="$BACKUP_DIR/backup_$DATE.dump"

# Upload to S3 (optional)
aws s3 cp "$BACKUP_DIR/backup_$DATE.dump" \
  s3://my-backups/database/

# Delete local backups older than 7 days
find $BACKUP_DIR -name "backup_*.dump" -mtime +7 -delete

# Delete S3 backups older than 30 days
aws s3 ls s3://my-backups/database/ | \
  grep 'backup_' | \
  awk '{print $4}' | \
  while read file; do
    file_date=$(echo $file | grep -oP '\d{8}')
    if [ $(( ($(date +%s) - $(date -d $file_date +%s)) / 86400 )) -gt 30 ]; then
      aws s3 rm "s3://my-backups/database/$file"
    fi
  done

Add to crontab:

# Run daily at 1 AM
0 1 * * * /home/user/scripts/backup_database.sh >> /var/log/backup.log 2>&1

Backup Storage

Storage Location

Backups are stored in:

• Storage: Replicated within the Falkenstein datacenter
• Offsite Copies: Export snapshots (see External Backups above) to keep your own copy outside the platform

Storage Costs

Backup Size

Backup size depends on:

• Data Volume: Amount of data in database
• Compression: Backups are compressed (typically 60-80% reduction)
• Changes: Incremental changes since last backup

View backup sizes in the Backups tab of your database.

Disaster Recovery Planning

Recovery Time Objective (RTO)

Expected time to restore database:

Recovery Point Objective (RPO)

Maximum acceptable data loss:

Disaster Recovery Checklist

Before Disaster

• [ ] Verify automatic backups are running
• [ ] Test backup restoration monthly
• [ ] Document restoration procedures
• [ ] Store connection details securely
• [ ] Set up monitoring and alerts
• [ ] Configure backup retention appropriately
• [ ] Export snapshots for offsite copies of critical databases

During Disaster

• [ ] Assess scope of data loss or corruption
• [ ] Identify last known good backup
• [ ] Notify stakeholders of expected downtime
• [ ] Initiate restoration procedure
• [ ] Monitor restoration progress
• [ ] Verify data integrity after restoration
• [ ] Test application connectivity
• [ ] Document incident for review

After Disaster

• [ ] Perform post-mortem analysis
• [ ] Update disaster recovery procedures
• [ ] Implement preventive measures
• [ ] Restore normal backup schedule
• [ ] Communicate resolution to stakeholders

Best Practices

Backup Strategy

1. Enable Automatic Backups: Always keep automatic backups enabled
2. Extend Retention: Use 14 or 30-day retention for production databases
3. Manual Backups: Create manual backups before risky operations
4. Test Regularly: Monthly restoration tests to verify backups work
5. External Backups: Maintain additional external backups for critical data
6. Document Procedures: Keep restoration procedures up-to-date
7. Monitor Backups: Set up alerts for backup failures

Application Best Practices

1. Backup Before Migrations: Always backup before schema changes
2. Version Control: Keep database migration scripts in version control
3. Rollback Plans: Document rollback procedures for deployments
4. Data Validation: Verify data integrity after restoration
5. Connection Management: Handle database unavailability gracefully

Security Best Practices

1. Encrypt Sensitive Data Yourself: Snapshots are stored unencrypted, and backup copies in the platform's object store are not guaranteed to be encrypted at rest. If your data must be encrypted at rest, encrypt sensitive fields in your application
2. Access Control: Limit who can restore backups
3. Audit Logs: Monitor backup and restoration activities
4. Secure External Backups: Encrypt external backups if storing off-platform
5. Compliance: Ensure backup retention meets regulatory requirements

Monitoring and Alerts

Backup Monitoring

Monitor backup health in dashboard:

• Last Backup: Timestamp of most recent backup
• Backup Status: Success or failure
• Backup Size: Current backup size
• Next Backup: Scheduled time for next backup
• Retention: Number of backups retained

Alert Configuration

Set up alerts for:

• Backup failures
• Backup size exceeding threshold
• No backup in 24 hours
• Backup storage quota exceeded

Troubleshooting

Backup Failed

Symptoms: Backup marked as failed in dashboard

Causes:

• Database was offline during backup window
• Insufficient storage space
• Long-running transactions preventing consistent snapshot
• Network connectivity issues

Solutions:

• Check database status
• Ensure database has available storage
• Review long-running queries
• Retry backup manually
• Contact support if issue persists

Restoration Failed

Symptoms: Database restoration fails or database doesn't start

Causes:

• Incompatible database version
• Insufficient resources on target
• Corrupted backup
• Configuration mismatch

Solutions:

• Verify database version compatibility
• Ensure target has sufficient resources
• Try different backup
• Check restoration logs
• Contact support for assistance

Slow Restoration

Symptoms: Restoration taking longer than expected

Causes:

• Large database size
• High compression ratio
• Network limitations
• Concurrent database operations

Solutions:

• Be patient; large databases take time
• Schedule restoration during off-peak hours
• Consider restoring to new database to avoid downtime
• Monitor restoration progress in dashboard

Related Documentation

• PostgreSQL
• MySQL
• MariaDB
• Database Replicas
• Database Overview
• Platform Security