Database Backup Security Guide: Encrypting, Isolating and Restoring SQL, Oracle and Cloud Databases

A database backup is a complete, portable copy of the data an organisation most wants to protect, and it is often guarded far less carefully than the live database. Attackers want backups for two reasons: to steal them, because a backup file or snapshot can be restored anywhere, and to destroy them, because ransomware only pays when recovery fails. This guide covers the database-specific layer of backup security: native backup encryption and its keys, transaction log and point-in-time recovery chains, snapshot sharing, immutable retention, backup operator rights and restore testing. It is written for DBAs, platform engineers and security teams running Microsoft SQL Server, Oracle Database, PostgreSQL and managed cloud databases. General backup architecture (3-2-1-1-0, object lock, air gaps) is covered in the Backup Security and Immutable Backup Guide linked below; this page goes deeper on databases.

Key takeaways

• Encrypt the backup, not only the database. SQL Server backup encryption, Oracle RMAN encryption and encrypted cloud snapshots make a stolen backup file useless without the key.
• The key is now the backup. Microsoft and Oracle both warn that losing the certificate, keystore or password makes encrypted backups unrestorable, so key backups need their own separate, tested protection.
• Logs are part of the backup. Point-in-time recovery depends on an unbroken chain of transaction log or WAL archives, which must be protected and immutable just like full backups.
• Sharing and copying are the quiet leak paths. Shared or public snapshots, dump files on file shares and test restores into non-production copy the full data set outside its controls.
• Only a restore proves a backup. Schedule restores into an isolated environment, run integrity checks, and measure the time it takes against the recovery time objective.

Threats to database backups

The GoTo 2023 breach shows why key separation matters: the attacker took encrypted backups from a third-party cloud storage service together with an encryption key for part of them. In the related LastPass 2022 breach, backup decryption keys and cloud access keys reached through one engineer's vault gave access to backups of customer vault data.

Native backup encryption by platform

Platforms are listed alphabetically. Each platform section states what the vendor documentation describes, as of November 2026.

Amazon RDS

Snapshots of an encrypted RDS instance are encrypted with the instance's AWS KMS key. Use a customer managed KMS key rather than the default AWS managed key wherever snapshots may need to be shared or copied across accounts, because AWS documents that snapshots encrypted with the default KMS key cannot be shared. Encrypted snapshots are always private: the console sets visibility to Private and the API rejects the value all for them. Manual snapshots can be shared with up to 20 AWS accounts. See the Amazon RDS and Aurora Security Guide.

Azure SQL Database

For long-term retention (LTR) backups, turn on backup immutability: Microsoft describes it as storing LTR backups in a Write Once, Read Many (WORM) state that is "non-modifiable and non-erasable for a user-defined retention period", even by privileged administrators. Time-based immutability is configured at the policy level and is generally available; legal hold on existing backups is in preview as of November 2026. Changes apply to future backups only. See the Azure SQL and Cosmos DB Security Guide.

Microsoft SQL Server

Backup encryption (from SQL Server 2014) uses AES 128, AES 192, AES 256 or Triple DES with a server certificate or an asymmetric key held in an Extensible Key Management (EKM) provider, for example WITH ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = ...). Choose AES 256. Microsoft's guidance: back up the certificate "preferably to a different location than the backup file it was used to encrypt", do not renew or modify the certificate (the thumbprint can change and break existing backups), and use different certificates for TDE and for backups. Databases protected by TDE produce encrypted backups automatically, and the TDE certificate and private key must be backed up immediately after enabling TDE. Microsoft documents that SQL Server Express and Web editions restore encrypted backups but do not encrypt during backup, so plan encryption at the storage layer for those editions. See the Microsoft SQL Server Security Guide.

Oracle Database

RMAN offers three encryption modes: transparent (the default, using the Oracle software keystore), password, and dual mode (keystore or password). CONFIGURE ENCRYPTION FOR DATABASE ON makes transparent encryption persistent for all backup sets, and CONFIGURE ENCRYPTION ALGORITHM TO 'AES256' raises the algorithm from the documented AES 128 default. Oracle cautions that losing the keystore makes transparently encrypted backups unrestorable, and that an auto-login keystore must not be backed up alongside the encrypted backups, because anyone holding both can read the data. Archived redo log backup sets are encrypted when encryption is configured for the database. See the Oracle Database Security Guide.

PostgreSQL

Physical backups combine a base backup (pg_basebackup) with continuous WAL archiving through archive_command or archive_library. The PostgreSQL documentation notes that archived WAL "contains effectively everything in your database" and should be archived into a location without group or world read access, and that archive commands should refuse to overwrite an existing archive file. Encrypt the archive at the storage or backup tool layer, and back up postgresql.conf, pg_hba.conf and pg_ident.conf separately, because WAL replay does not restore them. See the PostgreSQL Security Guide.

Key custody: keep keys away from the backups

• Separate location: store certificate, keystore and key backups in a different system from the backup files, with a different administrator group. Microsoft's guidance is explicit about a different location; Oracle's auto-login keystore caution makes the same point.
• Escrow and test: keep an offline escrow copy of each backup certificate or keystore and its password, and prove it in restore tests. A key that has never been used for a restore is an untested dependency.
• Find unprotected keys: on SQL Server, Microsoft provides a query against sys.certificates and sys.dm_database_encryption_keys where a NULL pvt_key_last_backup_date shows a TDE certificate that has never been backed up. Run it on every instance.
• Keep retired keys: retain old certificates and keystore versions for as long as any backup encrypted with them is retained. Microsoft notes the TDE certificate is still needed after TDE is disabled for some operations.
• Use an HSM or cloud KMS where practical: SQL Server EKM asymmetric keys and customer managed cloud keys put the key under separate access control and logging. See the Cryptographic Key Management Guide.

Where identity fits: backup operators and service accounts

Database backups are run by machine identities: the SQL Server Agent service account, the RMAN catalog owner, the PostgreSQL replication role used by pg_basebackup, and the IAM role or managed identity of a backup service. These identities usually hold broad read access to every database and write access to the backup target, so they deserve privileged treatment.

• Least privilege for backup: on SQL Server, the db_backupoperator role plus VIEW DEFINITION on the backup certificate is enough to create encrypted backups; avoid sysadmin for backup jobs. See How to audit SQL Server service accounts and logins.
• Write but not delete: the identity that writes backups should not be able to shorten retention or delete immutable copies. Keep deletion and retention changes under a separate, MFA-protected administrative role.
• No shared domain credentials: a backup server joined to the production domain, with a domain admin service account, falls with the domain. See the Backup Identity Isolation Guide.
• Rotate and vault: store backup service and storage credentials in a secrets manager, not in job scripts or connection strings.

Snapshots, dumps and copies outside production

• Snapshot sharing: review snapshot share attributes regularly. AWS warns not to share snapshots containing private information as Public; only unencrypted snapshots can be made public, which is another reason to encrypt every instance.
• Logical dumps: pg_dump, mysqldump, expdp and .bacpac exports are often taken by hand for migrations and left on file shares, laptops and web servers. Treat them as backups: encrypt, inventory and delete on a schedule. See the Directory Listing and Exposed Backup Files Guide.
• Restores into non-production: refreshing test databases from production backups copies real personal data into weaker environments. Mask or subset the data, or restore only into an isolated recovery environment with production-grade controls.
• Cross-region and cross-account copies: copying backups to a separate account with its own administrators is a strong control against a compromised production account, provided the copy is encrypted with a key that the production account cannot delete.

Immutability and isolation for database backups

CISA's #StopRansomware Guide advises maintaining "offline, encrypted backups of critical data" because many ransomware variants try to find and delete or encrypt accessible backups, and also advises using immutable storage with caution, since misconfiguration can be costly. For databases, apply immutability to all three parts of a recovery: full backups, differential or incremental backups, and log or WAL archives. Immutable full backups with a deletable log chain still allow an attacker to remove point-in-time recovery.

For the general design of each option, see the Backup Security and Immutable Backup Guide and the Cyber Recovery Vault Guide.

Restoring safely

1. Restore into isolation: recover into a clean, segmented environment, not back onto a host that may still be compromised.
2. Verify integrity before use: NIST CSF 2.0 RC.RP-03 calls for verifying the integrity of backups before restoration. Run engine checks (for example RESTORE VERIFYONLY and DBCC CHECKDB on SQL Server, RMAN RESTORE ... VALIDATE on Oracle) and application-level reconciliation.
3. Choose the recovery point deliberately: use point-in-time recovery to stop just before the first malicious change, using the incident timeline. PostgreSQL supports stopping by time, named restore point or transaction ID.
4. Review identities in the restored data: check database logins, users, roles and linked server or database link definitions for accounts added by the attacker before reconnecting applications.
5. Rotate credentials: rotate application, service and backup account credentials that existed at the time of the incident. See How to rotate database credentials without downtime.

The D3FEND technique D3-RD Restore Database describes this defensive step; see the D3-RD Restore Database page, and the Database Breach Response Playbook for the wider incident.

Implementation: a phased approach

1. Inventory (weeks 1 to 2): list every database, its backup method, target, retention, encryption state, key location and the identities that can read or delete backups. Include logical dumps and shared snapshots.
2. Close the theft gaps (weeks 2 to 6): turn on backup encryption with AES 256, move to customer managed keys where sharing or copying is needed, back up every certificate and keystore to a separate escrow, and remove public or unneeded snapshot shares.
3. Close the deletion gaps (weeks 4 to 10): add immutable retention for full backups and log archives, and separate the write identity from the delete or retention identity.
4. Test (from week 6, then quarterly): restore a sample of databases into an isolated environment, with keys taken from escrow, and time it. Start with test databases, then tier 1 systems.
5. Roll back safely: enable encryption and immutability on new backups first and keep the existing unencrypted chain until the first encrypted restore succeeds. Locked immutability cannot be undone, so pilot lock periods on a non-critical database before applying them widely.

Small and large organisations

• Small teams: rely on managed database backups with immutability where the platform offers it, plus one encrypted copy in a separate account or subscription, and a documented key escrow.
• Large estates: centralise policy in a backup platform, enforce encryption through configuration baselines, and give the backup platform its own identity domain and administrators.

Detection and measurement

• Backup deletions and retention changes: alert on snapshot deletion, retention reduction, immutability removal and log archive deletion in cloud audit logs and backup platform logs.
• Snapshot sharing changes: alert when a snapshot's restore attribute is modified, especially to an unknown account.
• Unusual backup jobs: ad hoc full backups or exports to new destinations, outside the job schedule or by a human account, can indicate staging for theft.
• Failed or skipped log backups: a broken log chain silently removes point-in-time recovery.

Common failure patterns

• Key stored beside the backup: the certificate export, keystore or password file sits in the same share or bucket as the backups, as the GoTo case illustrates with a key taken along with the backups.
• Lost key, lost backups: a certificate renewed, dropped or never exported makes years of encrypted backups unrestorable.
• Immutable fulls, deletable logs: the attacker deletes the log or WAL archive and point-in-time recovery disappears.
• Backup admin equals domain admin: one compromised directory gives access to delete every copy.
• Forgotten dumps and snapshots: migration exports and old shared snapshots outlive the project that created them.
• Restore never tested: the first restore happens during the incident and takes days longer than planned. See the Restore Testing and Recovery Assurance Guide.

Framework mapping

Practitioner checklist

• Inventory every database backup, dump and snapshot with its encryption state, key location and retention.
• Turn on native backup encryption with AES 256 and customer managed keys where backups are shared or copied.
• Back up every backup and TDE certificate, keystore and password to a separate escrow, and run Microsoft's NULL pvt_key_last_backup_date check on SQL Server.
• Never store an Oracle auto-login keystore with the encrypted backups.
• Make full backups and log or WAL archives immutable for tier 1 databases.
• Separate the identity that writes backups from the one that can delete them or shorten retention.
• Remove public and unapproved snapshot shares and clean up migration dumps.
• Restore tier 1 databases quarterly into an isolated environment using escrowed keys, and record the time taken.
• Alert on backup deletion, retention changes, snapshot sharing changes and broken log chains.

Standards and references

• Microsoft Learn: SQL Server Backup Encryption
• Microsoft Learn: Transparent Data Encryption (TDE)
• Oracle: Configuring the RMAN Environment, Advanced Topics (backup encryption)
• PostgreSQL: Continuous Archiving and Point-in-Time Recovery
• AWS: Sharing a DB snapshot for Amazon RDS
• Microsoft Learn: Backup immutability for Azure SQL Database long-term retention backups
• CISA: #StopRansomware Guide

Related NHI Mgmt Group resources: Backup Security and Immutable Backup Guide · Database and Storage Encryption Guide · Backup Identity Isolation Guide · Backup and Recovery Testing Checklist