New: AI & text-to-SQL on your own SupersetBook a demo
D23 logoD23
All posts
Apache Superset

Apache Superset Backup, Disaster Recovery, and HA Setup

Production-grade resilience for Apache Superset: backup strategies, disaster recovery architecture, and high-availability setups for mission-critical analytics.

DTD23 Team
13 minutes read

Understanding the Stakes: Why Superset Resilience Matters

When your analytics infrastructure goes down, the impact ripples fast. Dashboards disappear. Reports don't run. Teams making decisions on stale data or no data at all. For organizations running D23's managed Apache Superset or self-hosted deployments, the question isn't if you need backup and disaster recovery—it's how soon you implement it.

Apache Superset stores two critical layers of data: the metadata database (users, roles, dashboards, queries, permissions) and the connected data sources themselves. A failure in either layer breaks your analytics stack. This guide walks you through production-grade backup, disaster recovery, and high-availability (HA) setups that keep Superset running when things go wrong.

Unlike ephemeral analytics tools, Superset's value compounds over time. Each dashboard, saved query, and configured permission represents institutional knowledge. Losing that means rebuilding not just infrastructure—it means losing months of analytics work. That's why this post focuses on concrete, implementable strategies rather than theory.

The Three Layers of Resilience: Backup, HA, and Disaster Recovery

Before diving into implementation, let's clarify the three interconnected concepts that make Superset production-ready:

Backup is the practice of copying your metadata database and configuration to a secondary location. It's your insurance policy. When corruption happens or accidental deletion occurs, backups let you restore to a known-good state. Backups are point-in-time snapshots—they capture state at specific moments.

High Availability (HA) means your Superset deployment continues running even when individual components fail. If one Superset web server crashes, others handle traffic. If one database node fails, replicas take over. HA is about redundancy—multiple instances of critical components so no single failure brings the system down.

Disaster Recovery (DR) is your playbook for recovering from catastrophic failures—entire data center outages, regional cloud infrastructure problems, or widespread data corruption. DR typically involves failover to a geographically separate location and includes recovery time objective (RTO) and recovery point objective (RPO) targets.

Think of it this way: backups are your parachute. HA is your redundant engines. DR is your alternate airport. You need all three for true production resilience.

Backup Strategy: Protecting Your Metadata Database

The metadata database is Superset's brain. It stores dashboard definitions, user credentials, data source connections, saved queries, and permissions. Lose it, and you lose everything—even if your connected data sources are perfectly fine.

Identifying What to Backup

Your Superset backup scope includes:

  • The metadata database (PostgreSQL, MySQL, or other RDBMS configured via SQLALCHEMY_DATABASE_URI)
  • Uploaded files (CSV imports, custom logos, custom plugins if stored locally)
  • Configuration files (superset_config.py, environment variables, secrets)
  • Custom plugins and extensions (if not version-controlled)

The metadata database is your primary concern. When following official Apache Superset configuration guidance, your SQLALCHEMY_DATABASE_URI points to a database that holds all dashboard, user, and permission data. That's your backup target.

Full Database Backup Methods

For PostgreSQL (the most common choice for production Superset), use pg_dump for logical backups or filesystem-level snapshots for physical backups. As discussed in the Backup Discussion on Apache Superset GitHub, full backup methods using database tools like pg_dump capture users, roles, and permissions comprehensively.

Logical backup with pg_dump:

pg_dump -U superset_user -h db.example.com superset_db > superset_backup_$(date +%Y%m%d_%H%M%S).sql

This creates a SQL script containing all database objects. It's portable across PostgreSQL versions (with caveats) and human-readable. Restore it with:

psql -U superset_user -h db.example.com superset_db < superset_backup_20240115_143022.sql

Logical backups are slower for large databases but safer for version mismatches and easier to verify.

Physical backups with WAL archiving:

For production systems, PostgreSQL's Write-Ahead Logging (WAL) archiving provides point-in-time recovery (PITR). Configure your database to archive WAL segments to S3 or another object store, then combine periodic base backups with WAL replay to recover to any moment in time.

archive_command = 'aws s3 cp %p s3://my-superset-backups/wal/%f'

Physical backups are faster and enable PITR, but require more operational sophistication.

Automated Backup Scheduling

Manual backups are backups that don't happen. Automate with cron jobs on a backup server separate from your database:

0 2 * * * /usr/local/bin/backup-superset.sh

Your backup script should:

  1. Connect to the metadata database
  2. Perform the backup (pg_dump or snapshot)
  3. Compress the output
  4. Upload to S3, GCS, or another durable storage
  5. Verify the backup integrity
  6. Log the result and alert on failure

Store backups in a different AWS region than your primary database. If your primary region has an outage, you can't recover from backups in the same region.

Backup Retention and Testing

Retain backups according to your compliance requirements:

  • Daily backups: Keep for 30 days
  • Weekly backups: Keep for 90 days
  • Monthly backups: Keep for 1 year

More importantly, test your backups. Monthly, restore a backup to a staging environment and verify that dashboards load, queries run, and user permissions work. A backup that hasn't been tested is just hope—not insurance.

Document your recovery process. When disaster strikes at 3 AM, you won't have time to figure out the steps. Write them down now.

High Availability Architecture: Eliminating Single Points of Failure

HA means designing Superset so that no single component failure brings down the system. This requires redundancy at every layer.

Multi-Instance Superset Web Servers

Run multiple Superset web server instances behind a load balancer. If one instance crashes, traffic automatically routes to others.

Architecture:

[Users]
    ↓
[Load Balancer] (ALB, NLB, or nginx)
    ↓
[Superset Web 1] [Superset Web 2] [Superset Web 3]
    ↓
[Shared Metadata Database]
    ↓
[Data Sources]

Each Superset instance is stateless—all user sessions and dashboard state live in the metadata database. This means you can spin up or tear down instances without losing data.

Configuration for HA:

Set SQLALCHEMY_POOL_SIZE and SQLALCHEMY_MAX_OVERFLOW appropriately for your database connection pool:

SQLALCHEMY_POOL_SIZE = 10
SQLALCHEMY_MAX_OVERFLOW = 20

With three web servers, each with a pool size of 10, you're maintaining ~30 active connections to your metadata database. Make sure your database can handle this.

Enable session persistence in your load balancer or use Redis for session storage. This ensures users stay logged in if they're routed to a different web server mid-session.

Database Replication and Failover

Your metadata database is still a single point of failure. Protect it with replication.

PostgreSQL streaming replication:

Set up a primary database with one or more hot standby replicas. The primary accepts writes; replicas receive changes via WAL streaming and can be promoted to primary if needed.

# On primary
wal_level = replica
max_wal_senders = 10
wal_keep_size = 1GB
 
# On standby
standby_mode = on
primary_conninfo = 'host=primary.example.com user=replication password=xxx'

When the primary fails, promote a standby:

pg_ctl promote -D /var/lib/postgresql/data

Or use automated failover tools like pg_auto_failover or your cloud provider's managed database HA features (AWS RDS Multi-AZ, Google Cloud SQL HA, Azure Database for PostgreSQL HA).

Managed database HA:

If you're running on AWS, Google Cloud, or Azure, use their managed database services with HA enabled. They handle replication, failover, and backups automatically. The operational burden drops dramatically.

Cache Layer for Query Performance

High availability isn't just about uptime—it's about consistent performance. Add Redis as a cache layer for query results and session storage.

CACHE_CONFIG = {
    'CACHE_TYPE': 'redis',
    'CACHE_REDIS_URL': 'redis://redis-primary:6379/0',
    'CACHE_DEFAULT_TIMEOUT': 300,
}
 
RESULTS_BACKEND = 'redis://redis-primary:6379/1'

Run Redis with replication and sentinel for automatic failover:

# Sentinel configuration
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000

When the primary Redis fails, Sentinel automatically promotes a replica. Superset reconnects and continues serving cached results.

Load Balancer Configuration

Your load balancer must be intelligent. Use health checks to detect failed Superset instances:

Health check endpoint: /health
Interval: 10 seconds
Timeout: 5 seconds
Unhealthy threshold: 2 consecutive failures
Healthy threshold: 2 consecutive successes

When an instance fails two health checks, the load balancer stops routing traffic to it. Implement the /health endpoint in your Superset deployment to return 200 OK when the instance is healthy and can connect to the metadata database.

Disaster Recovery: Planning for Catastrophic Failure

HA handles component failures. DR handles catastrophic failures—entire regions going down, widespread data corruption, or security breaches requiring a complete rebuild.

Define Your RTO and RPO

Before designing DR, define your targets:

Recovery Time Objective (RTO): How long can analytics be down? If you say "4 hours," your DR plan must get Superset back online within 4 hours of a disaster.

Recovery Point Objective (RPO): How much data can you afford to lose? If you say "1 hour," your backups must run at least hourly, and you accept losing up to 1 hour of dashboard changes.

These targets drive your infrastructure investment. An RTO of 15 minutes requires active-active failover across regions. An RTO of 24 hours allows manual failover. Be realistic about your business needs.

For guidance on these concepts, practical disaster recovery configuration includes detailed steps for setting RTO/RPO, backup strategies, failover procedures, and testing.

Backup Strategy for DR

Your DR backup strategy differs from your HA backup strategy. For HA, you're protecting against component failures within a region. For DR, you're protecting against regional failure.

Cross-region backup replication:

  1. Take daily backups in your primary region (e.g., us-east-1)
  2. Replicate those backups to a secondary region (e.g., us-west-2) within 4 hours
  3. Retain cross-region backups for 30 days
  4. Test recovery from cross-region backups monthly

Use S3 cross-region replication or database native replication:

# S3 cross-region replication
aws s3api put-bucket-replication \
  --bucket my-superset-backups \
  --replication-configuration file://replication.json

Standby Environment Setup

A DR standby environment is a full Superset deployment in a secondary region, ready to take over if the primary fails.

Minimal standby (lower cost):

  • Single Superset web server instance (not HA)
  • Metadata database with recent backups available
  • No active users—used only for failover
  • Scaled down to reduce costs

Active-active standby (zero downtime):

  • Full HA Superset deployment in secondary region
  • Active user traffic split between regions
  • Bidirectional database replication
  • Higher cost but zero failover time

Most organizations start with minimal standby and upgrade to active-active as scale increases.

Failover Procedures

Document your failover steps. When disaster strikes, you need clear procedures, not improvisation.

Detecting disaster:

  1. Health checks from primary region fail for >5 minutes
  2. Manual verification confirms regional outage
  3. Declare disaster and initiate failover

Failover steps:

  1. Restore latest backup to standby database
  2. Update DNS to point to standby Superset
  3. Verify dashboards load and queries run
  4. Notify users of failover
  5. Monitor standby for stability

Failback procedures:

  1. Primary region restored and verified
  2. Sync any changes made in standby back to primary
  3. Gradually shift traffic back to primary
  4. Verify primary stability
  5. Decommission standby (or reset for next DR cycle)

Automate as much as possible. Manual failover is error-prone and slow. Use infrastructure-as-code (Terraform, CloudFormation) to spin up standby environments automatically.

Testing Your Disaster Recovery Plan

A DR plan that hasn't been tested is fiction. Schedule quarterly DR drills:

  1. Announcement: Notify stakeholders that a drill is happening
  2. Initiate failover: Trigger your failover procedures
  3. Verify functionality: Confirm dashboards load, queries run, users can log in
  4. Measure RTO: Time from disaster declaration to full functionality
  5. Document issues: Note anything that failed or took longer than expected
  6. Remediate: Fix issues before the next drill
  7. Failback: Return to primary and verify stability

DR drills are expensive in time and attention, but they're cheaper than discovering your DR plan doesn't work during an actual disaster.

Production Checklist for Superset Resilience

Based on production hardening guidance for Apache Superset, here's a checklist covering HA setups, metadata database management, and backup recommendations:

Backup Checklist

  • Metadata database backups running daily
  • Backups stored in a different AWS region (or cloud provider region)
  • Backup retention policy documented (30 days daily, 90 days weekly, 1 year monthly)
  • Monthly restore tests from backup to staging environment
  • Backup encryption enabled (at rest and in transit)
  • Backup monitoring and alerting configured
  • Recovery procedures documented and tested
  • Configuration files and secrets included in backup scope
  • Custom plugins and extensions version-controlled

High Availability Checklist

  • Multiple Superset web server instances (minimum 3 for true HA)
  • Load balancer in front of web servers with health checks
  • Metadata database replication configured (primary + standby)
  • Automated database failover (via RDS, pg_auto_failover, or similar)
  • Redis cache with replication and Sentinel for automatic failover
  • Session storage in Redis (not local memory)
  • Connection pooling configured for metadata database
  • Load balancer health check endpoint implemented
  • Monitoring and alerting for failed instances
  • Runbooks for manual failover if automation fails

Disaster Recovery Checklist

  • RTO and RPO defined and documented
  • Standby environment in secondary region (minimal or active-active)
  • Cross-region backup replication tested
  • DNS failover strategy documented (Route 53, Azure Traffic Manager, etc.)
  • Failover procedures documented and tested quarterly
  • Failback procedures documented
  • DR drill scheduled and executed quarterly
  • Post-drill remediation tracked and completed
  • Disaster declaration criteria defined
  • Communication plan for stakeholders during disaster

Implementing Backup and DR at Scale

For organizations running multiple Superset instances or managing analytics across portfolio companies, best practices for managing high availability runtimes and disaster recovery strategies in cloud environments apply directly.

Multi-Instance Backup Coordination

If you're running Superset for multiple teams or business units, coordinate backups:

  1. Centralized backup service: One service handles all backups
  2. Shared backup storage: All backups stored in centralized S3 bucket with proper isolation
  3. Backup tagging: Tag backups with team, environment, and timestamp for easy retrieval
  4. Retention policies: Enforce retention via S3 lifecycle policies
  5. Access controls: Restrict who can restore backups (security teams, not individual users)

Multi-Region Deployments

For organizations with users in multiple geographic regions, consider:

  1. Regional Superset deployments: Each region has its own Superset instance
  2. Shared metadata database: All regions write to a primary database, read from regional replicas
  3. Data source locality: Data sources stay in their region; Superset queries them locally
  4. Cross-region replication: Metadata database replicates to secondary region for DR

This topology reduces latency (users query nearby data sources), improves resilience (regional failure doesn't affect other regions), and simplifies compliance (data stays in region).

Monitoring and Alerting for Resilience

You can't respond to failures you don't know about. Implement comprehensive monitoring:

Metrics to Monitor

  • Database replication lag: If standby is >5 minutes behind primary, investigate
  • Backup success rate: Alert if backup fails two days in a row
  • Query latency: Spike indicates performance degradation
  • Cache hit rate: Dropping hit rate indicates cache issues
  • Web server error rates: Spike indicates application problems
  • Database connection pool utilization: High utilization indicates scaling issues
  • Disk space: Alert when backups fill up disk
  • SSL certificate expiration: Alert 30 days before expiration

Alert Severity Levels

  • Critical: Immediate page (database down, backup failed, replication lag >10 minutes)
  • High: Page within 15 minutes (query latency >5s, error rate >1%)
  • Medium: Email alert (cache hit rate <50%, connection pool >80%)
  • Low: Dashboard only (routine metrics for trend analysis)

Avoid alert fatigue. Every alert should be actionable. If you're ignoring alerts, you have too many.

Infrastructure as Code for Repeatable Resilience

Manual infrastructure is fragile. Use infrastructure-as-code to define your resilient architecture:

Terraform example for HA Superset on AWS:

# VPC with multi-AZ subnets
resource "aws_vpc" "superset" {
  cidr_block = "10.0.0.0/16"
}
 
resource "aws_subnet" "private_a" {
  vpc_id            = aws_vpc.superset.id
  availability_zone = "us-east-1a"
  cidr_block        = "10.0.1.0/24"
}
 
resource "aws_subnet" "private_b" {
  vpc_id            = aws_vpc.superset.id
  availability_zone = "us-east-1b"
  cidr_block        = "10.0.2.0/24"
}
 
# RDS Multi-AZ database
resource "aws_db_instance" "superset_metadata" {
  allocated_storage    = 100
  storage_type         = "gp3"
  engine               = "postgres"
  engine_version       = "14.7"
  instance_class       = "db.r5.large"
  multi_az             = true
  backup_retention_period = 30
  backup_window        = "02:00-03:00"
  copy_tags_to_snapshot = true
  skip_final_snapshot  = false
  db_subnet_group_name = aws_db_subnet_group.superset.name
}
 
# Auto Scaling Group for Superset web servers
resource "aws_launch_template" "superset" {
  image_id      = data.aws_ami.ubuntu.id
  instance_type = "t3.large"
  user_data     = base64encode(file("${path.module}/user_data.sh"))
}
 
resource "aws_autoscaling_group" "superset" {
  vpc_zone_identifier = [
    aws_subnet.private_a.id,
    aws_subnet.private_b.id,
  ]
  min_size         = 3
  max_size         = 10
  desired_capacity = 3
  launch_template {
    id      = aws_launch_template.superset.id
    version = "$Latest"
  }
  health_check_type         = "ELB"
  health_check_grace_period = 300
  target_group_arns         = [aws_lb_target_group.superset.arn]
}
 
# Application Load Balancer
resource "aws_lb" "superset" {
  internal           = false
  load_balancer_type = "application"
  subnets            = [aws_subnet.public_a.id, aws_subnet.public_b.id]
}
 
resource "aws_lb_target_group" "superset" {
  port     = 8088
  protocol = "HTTP"
  vpc_id   = aws_vpc.superset.id
  health_check {
    path                = "/health"
    interval            = 10
    timeout             = 5
    healthy_threshold   = 2
    unhealthy_threshold = 2
  }
}

With this code, you can spin up a complete HA Superset deployment in minutes. Add cross-region replication and you have DR.

Cost Optimization for Resilient Superset

Resilience costs money. Optimize intelligently:

Database Costs

  • Managed databases (RDS, Cloud SQL) cost 2-3x more than self-managed but eliminate operational burden and include HA/backups
  • Reserved instances for baseline capacity reduce compute costs by 30-50%
  • On-demand instances for burst capacity handle traffic spikes without overpaying for idle capacity
  • Storage optimization: Compress backups, archive old data, use cold storage for long-term retention

Compute Costs

  • Spot instances for non-critical workloads (batch jobs, dev environments) save 70-90%
  • Right-sizing: Monitor actual usage and downsize oversized instances
  • Scheduled scaling: Reduce capacity during off-hours if your analytics usage is predictable

Backup Costs

  • Tiered retention: Keep 30 days of daily backups, 90 days of weekly, 1 year of monthly
  • Compression: Reduces storage costs by 50-80%
  • S3 Intelligent-Tiering: Automatically moves old backups to cheaper storage classes

Standby Environment Costs

  • Minimal standby: Single small instance, minimal database, no active users—costs 20-30% of primary
  • Scheduled standby: Spin up standby only during DR drills, tear down after—costs near zero
  • Active-active: Costs equal to primary but provides zero-downtime failover

Start with minimal standby. If your RTO demands active-active, upgrade later.

Conclusion: Resilience as a Feature

Apache Superset's flexibility and power make it ideal for organizations building production analytics. But flexibility without resilience is risk. Backup, high availability, and disaster recovery aren't optional—they're table stakes for production deployments.

The good news: modern cloud infrastructure and open-source tools make resilience accessible. You don't need massive budgets or teams. You need clear thinking about what can fail, what failure costs, and how to prevent it.

Start with backups. Test them. Add HA. Define RTO/RPO. Build DR. Monitor everything. Document procedures. Test quarterly. This isn't a one-time project—it's an ongoing practice.

For organizations evaluating managed Apache Superset on D23, resilience is built-in. We handle backups, HA, and DR so your team focuses on analytics, not infrastructure. For teams running self-hosted Superset, the playbook above provides a clear path to production-grade resilience.

Your analytics infrastructure is too valuable to lose. Build it to last.