Backing up Metabase

Protect your Metabase data by implementing regular backup procedures for your application database.

Avoid losing your application data (questions, dashboards, collections, users, and settings) by regularly backing up your Metabase application database.

Metabase uses a single SQL database for all runtime application data. Back up this database to protect your Metabase configuration and content.

What to back up

The Metabase application database contains:

• User accounts and permissions
• Questions (saved queries)
• Dashboards and visualizations
• Collections and organization
• Data source connections
• Settings and configuration
• Alerts and subscriptions
• Audit logs (if enabled)

The application database does not contain your actual data. It only stores Metabase’s metadata and configuration. Your data remains in your connected databases.

When to back up

Create backups:

• Before every upgrade - Essential for safe rollback
• On a regular schedule - Daily or weekly depending on usage
• Before major configuration changes - Like permission updates or integrations
• After creating important content - New dashboards or critical questions

Backing up PostgreSQL

PostgreSQL is the recommended application database for production deployments.

Using pg_dump

Full backup

Create a complete backup of your Metabase database:

pg_dump -h localhost -U username -d metabase -F c -b -v -f metabase_backup_$(date +%Y%m%d).dump

This creates a compressed binary backup with timestamps.

SQL format

Create a plain SQL backup for easier inspection:

pg_dump -h localhost -U username -d metabase > metabase_backup_$(date +%Y%m%d).sql

With password

If prompted for a password, use the PGPASSWORD environment variable:

PGPASSWORD=your_password pg_dump -h localhost -U username -d metabase -F c -b -v -f metabase_backup.dump

Restoring PostgreSQL backups

Binary format (.dump)

pg_restore -h localhost -U username -d metabase -v metabase_backup.dump

Automated PostgreSQL backups

Create a backup script and schedule it with cron:

backup_metabase.sh

#!/bin/bash

# Configuration
DB_HOST="localhost"
DB_USER="metabase"
DB_NAME="metabase"
BACKUP_DIR="/backups/metabase"
RETENTION_DAYS=30

# Create backup directory if it doesn't exist
mkdir -p "$BACKUP_DIR"

# Generate backup filename with timestamp
BACKUP_FILE="$BACKUP_DIR/metabase_backup_$(date +%Y%m%d_%H%M%S).dump"

# Perform backup
pg_dump -h "$DB_HOST" -U "$DB_USER" -d "$DB_NAME" -F c -b -v -f "$BACKUP_FILE"

# Compress backup
gzip "$BACKUP_FILE"

# Delete backups older than retention period
find "$BACKUP_DIR" -name "metabase_backup_*.dump.gz" -mtime +$RETENTION_DAYS -delete

echo "Backup completed: ${BACKUP_FILE}.gz"

Schedule with cron (daily at 2 AM):

0 2 * * * /path/to/backup_metabase.sh >> /var/log/metabase_backup.log 2>&1

Backing up MySQL or MariaDB

Using mysqldump

Full backup

mysqldump -u username -p metabase > metabase_backup_$(date +%Y%m%d).sql

You’ll be prompted for the password.

With password in command

mysqldump -u username -pYourPassword metabase > metabase_backup.sql

Note: No space between -p and the password.

Compressed backup

mysqldump -u username -p metabase | gzip > metabase_backup_$(date +%Y%m%d).sql.gz

Restoring MySQL backups

Standard restore

mysql -u username -p metabase < metabase_backup.sql

Automated MySQL backups

backup_metabase.sh

#!/bin/bash

# Configuration
DB_USER="metabase"
DB_PASS="your_password"
DB_NAME="metabase"
BACKUP_DIR="/backups/metabase"
RETENTION_DAYS=30

# Create backup directory
mkdir -p "$BACKUP_DIR"

# Backup filename
BACKUP_FILE="$BACKUP_DIR/metabase_backup_$(date +%Y%m%d_%H%M%S).sql"

# Perform backup
mysqldump -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" > "$BACKUP_FILE"

# Compress
gzip "$BACKUP_FILE"

# Delete old backups
find "$BACKUP_DIR" -name "metabase_backup_*.sql.gz" -mtime +$RETENTION_DAYS -delete

echo "Backup completed: ${BACKUP_FILE}.gz"

Backing up H2 database

The H2 database should not be used in production. If you’re still using H2, migrate to PostgreSQL as soon as possible.

If you must back up an H2 database:

For Docker deployments

1. Stop the Metabase container

   docker stop metabase
   
2. Copy the database file out

   docker cp metabase:/metabase.db/metabase.db.mv.db ./metabase_backup_$(date +%Y%m%d).mv.db
   
3. Restart Metabase

   docker start metabase
   

For JAR deployments

1. Stop Metabase

   Stop the Metabase process (Ctrl+C or stop the service)

2. Copy the database file

   cp metabase.db.mv.db metabase_backup_$(date +%Y%m%d).mv.db
   
3. Restart Metabase

   java --add-opens java.base/java.nio=ALL-UNNAMED -jar metabase.jar
   

H2 database files must be backed up while Metabase is stopped to ensure consistency.

Cloud-managed databases

Amazon RDS

If you’re using Amazon RDS for your Metabase application database:

1. Enable automated backups in the RDS console
2. Set backup retention period (7-35 days)
3. Configure backup window during low-usage hours
4. Enable point-in-time recovery for additional protection

Amazon RDS Backup Guide

Official AWS documentation for RDS backups

Manual RDS snapshots:

aws rds create-db-snapshot \
  --db-instance-identifier metabase-db \
  --db-snapshot-identifier metabase-backup-$(date +%Y%m%d)

Azure Database

Azure Database for PostgreSQL automatically backs up your server. Configure:

• Backup retention period (7-35 days)
• Geo-redundant backup (optional)
• Point-in-time restore capability

Google Cloud SQL

Cloud SQL provides automatic backups:

• Configure automated backup window
• Enable binary logging for point-in-time recovery
• Set backup retention period

Backup best practices

1. Test your backups regularly

   Regularly test restoration to ensure backups are valid:

   • Restore to a test environment monthly
   • Verify data integrity
   • Document restoration procedures
   • Train team members on restoration process
2. Store backups securely

   Protect your backup files:

   • Use encryption for backup files
   • Store in multiple locations (3-2-1 rule)
   • Restrict access to backup storage
   • Use separate infrastructure from production
3. Implement retention policies

   Balance storage costs with recovery needs:

   • Keep daily backups for 7-30 days
   • Keep weekly backups for 3 months
   • Keep monthly backups for 1 year
   • Archive critical snapshots longer
4. Monitor backup jobs

   Ensure backups are running successfully:

   • Set up alerts for backup failures
   • Monitor backup file sizes
   • Verify backup timestamps
   • Log all backup operations

Backup storage options

Amazon S3

Upload backups to S3 for durable, scalable storage

aws s3 cp metabase_backup.dump.gz s3://my-backups/metabase/

Azure Blob Storage

Use Azure CLI to upload backups

az storage blob upload --account-name myaccount --container-name backups --file metabase_backup.sql.gz

Google Cloud Storage

Upload with gsutil

gsutil cp metabase_backup.dump.gz gs://my-backups/metabase/

Network storage

Mount NFS or SMB shares for backup storage

cp metabase_backup.sql.gz /mnt/backups/metabase/

Disaster recovery plan

A complete disaster recovery plan should include:

1. Backup procedures - Documented and automated
2. Restoration procedures - Step-by-step guides
3. Recovery time objective (RTO) - How long to restore
4. Recovery point objective (RPO) - Acceptable data loss window
5. Emergency contacts - Who to notify
6. Escalation procedures - When to escalate

Next steps

Upgrading Metabase

Always back up before upgrading

Configuring database

Set up a production-ready application database

Migrating from H2

Move from H2 to PostgreSQL or MySQL

Running on Docker

Deploy with proper volume management