Why Your Database Backup Strategy Is Your Biggest Multi-Tenant Risk

Backups are the overlooked attack surface

Most multi-tenant security discussions focus on the live database. Query-time filtering, row-level security, connection isolation, access controls. These are important. But they protect data in one state: the state where it is being actively queried by the application.

Data exists in other states. It is backed up to object storage. It is copied to staging environments. It is transferred between regions. It is retained for compliance. In each of these states, the access controls that protect the live database do not apply.

A database backup is a complete, unfiltered copy of everything in the database. For a shared multi-tenant database, that means a single file containing every tenant's data. Anyone who gains access to that file has access to every customer's data simultaneously.

The security of your backup strategy determines the actual blast radius of a data exposure. And for most multi-tenant applications, the backup strategy is the weakest link.

The shared backup problem

Consider a SaaS application with 300 tenants on a shared PostgreSQL database. The automated backup runs nightly, producing a pg_dump file that is uploaded to S3.

That single file contains:

• 300 customers' data in every table

• Credentials, personal information, financial records

• Historical data going back months or years

• Every row from every tenant, unfiltered

Now consider the places that file travels:

Object storage. The backup sits in an S3 bucket. If the bucket permissions are misconfigured, the backup is publicly accessible. This is not a hypothetical scenario. Misconfigured S3 buckets are one of the most common sources of data exposure.

Development environments. Engineers restore production backups to debug issues. The staging database now contains every tenant's production data. Everyone with access to the staging environment has access to all customer data.

CI/CD pipelines. Automated tests might restore from backups to test against realistic data. The backup credentials are stored in environment variables, pipeline configurations, or secret managers. Each of these is an additional access point.

Disaster recovery sites. Backups are replicated to secondary regions for disaster recovery. Each replica is another copy of every tenant's data in another location with its own access controls.

Long-term retention. Compliance requirements might mandate retaining backups for years. Each retained backup is a frozen copy of every tenant's data at that point in time. The longer the retention, the more copies exist.

Every copy of the backup is a copy of every customer's data. The attack surface is not one database. It is every place that backup has ever been stored, copied, transferred, or retained.

Per-tenant backups change the equation

When each tenant has their own database, each backup contains one customer's data. A backup of tenant "acme" contains only acme's data. A backup of tenant "globex" contains only globex's data.

The same scenarios play out differently:

Misconfigured bucket. An exposed backup reveals one tenant's data, not 300. The incident response is scoped. The notification is to one customer.

Development environment. Engineers can restore a single tenant's backup for debugging without exposing other customers' data. You can even create sanitized development environments by restoring only specific test tenants.

CI/CD. Tests run against individual tenant backups. No production data from other customers is present in the pipeline.

Disaster recovery. Each tenant's backup is replicated independently. A failure in the replication of one backup does not affect others.

Retention. Long-term retention applies per tenant. When a tenant is deleted and their data retention period expires, their backups are deleted. Other tenants' backups are unaffected.

The blast radius of every backup-related incident is reduced from "all customers" to "one customer."

The restoration problem

Backups exist to be restored. The restore process introduces its own risks in a shared database model.

Restoring a shared database backup means restoring every tenant's data simultaneously. You cannot restore one tenant's data from a shared backup without also restoring every other tenant's data. If tenant "acme" needs a rollback to yesterday's state, you must either:

1. Restore the entire database to yesterday, affecting all 300 tenants. Every other tenant loses today's data.

2. Extract acme's rows from the backup manually, table by table, and insert them into the live database. This is error-prone and slow.

3. Restore the backup to a separate database, extract acme's data, then merge it back. This requires additional infrastructure and careful coordination.

None of these options are good. The first is destructive. The second is unreliable. The third is complex and time-consuming.

With per-tenant backups, restoring one tenant is straightforward. Restore that tenant's backup to their database. Other tenants are not affected. The operation takes seconds to minutes depending on data size.

One tenant, one backup, one restore. No other tenant is touched.

Backup frequency and granularity

With a shared database, backup frequency is constrained by the size of the entire database. A 500 GB shared database takes significant time and resources to back up. Running frequent backups (hourly or more) becomes impractical. Most teams settle for daily backups.

With per-tenant databases, each backup is the size of one tenant's data. A tenant with 50 MB of data backs up in seconds. This makes frequent backups practical. Hourly backups, or even backup-on-demand triggered by specific events, become feasible without impacting performance.

For tenants on dedicated infrastructure, backup granularity extends to point-in-time recovery. The database engine's write-ahead log or binary log is continuously archived, allowing restoration to any second in the past.

This level of backup granularity is only practical when backups are per-tenant.

Multi-engine backup complexity

Applications using multiple database engines compound the backup problem. A shared PostgreSQL database needs pg_dump. A shared MongoDB database needs mongodump. A shared Redis instance needs RDB snapshots. Each engine has its own backup tool, its own format, and its own restore procedure.

For a shared multi-tenant application, this means maintaining three separate backup pipelines, each producing a file that contains all tenants' data. Three backup tools. Three storage paths. Three restore procedures. Three sets of access controls to manage.

With per-tenant backups across a platform that supports all four engines, the backup system handles every engine through a single scheduler. PostgreSQL tenants are backed up with pg_dump. MySQL tenants with mysqldump. MongoDB tenants with mongodump. Redis tenants with RDB snapshots. Each backup is per-tenant, stored in a consistent path structure, and restorable through a single interface.

One tenant, multiple engines, unified backup management.

Encryption at rest

Backup encryption is straightforward when backups are per-tenant. Each backup file can be encrypted with a tenant-specific key. If a tenant requires that their backups are encrypted with a key they control (common in enterprise and healthcare), this is possible because their backup is a separate file.

With shared backups, tenant-specific encryption is not possible. The backup is a single file containing all tenants' data. It can be encrypted, but with a single key that covers everyone. There is no way to give one tenant control over the encryption of their data within a shared backup.

The compliance angle

Auditors frequently ask about backup procedures during compliance reviews. The questions include:

"How are backups encrypted?" With per-tenant backups: each backup is encrypted individually. With shared backups: one encryption key covers all tenants.

"How long are backups retained?" With per-tenant backups: retention is configurable per tenant based on their compliance requirements. With shared backups: one retention policy applies to all tenants.

"Can you demonstrate a backup restore for a single customer?" With per-tenant backups: restore the backup, show the data. With shared backups: restore the entire database or extract one tenant's data manually.

"What happens to backups when a customer leaves?" With per-tenant backups: delete that tenant's backups. Provable and auditable. With shared backups: the departed tenant's data remains in every historical backup until the retention period expires.

Each of these questions has a cleaner answer with per-tenant backups. The answers are also easier to demonstrate and audit.

Where TenantsDB fits

TenantsDB runs automated backups per tenant across PostgreSQL, MySQL, MongoDB, and Redis. Each backup is stored in S3, organized by tenant, engine, and timestamp. Backups are encrypted at rest.

Restoring a tenant is a single command. Point-in-time recovery is available for tenants on dedicated infrastructure. Backup schedules run automatically without configuration. Manual backups can be triggered on demand through the CLI or API.

The backup strategy is per-tenant by default because the database architecture is per-tenant by default. There is no shared backup that contains all customers' data. Every backup file contains one tenant's data.

Start free with up to 5 tenants at docs.tenantsdb.com.