6.3Database reliability and security

Since a database holds an organization's core operational data, its design must build in both reliability ("recoverable even if it breaks") and security ("accessible only to legitimate parties"). A DBA must be able to design the backup scheme and redundancy configuration by working backward from business requirements such as tolerable data loss (RPO) and recovery time (RTO), and to design access control, encryption, and auditing together based on the principle of least privilege. This section builds that design-judgment pattern.

6.3.1Backup and recovery

• A full backup duplicates the entire database as of a point in time. Restoration is simple, but taking the backup requires time and storage. A differential backup duplicates everything changed since the last full backup. Restoration needs only two generations ("full + the latest differential"), but the differential grows larger day by day. An incremental backup duplicates only what changed since the last backup (full or incremental). Each backup is small and fast, but restoration requires applying "full + every incremental in sequence," which tends to make restore time longer.
• Combined with write-ahead logging (WAL), a backup regimen that continuously retains transaction (archive) logs alongside full backups enables point-in-time recovery—restoring to any moment just before a failure. The choice of backup scheme is worked out backward from business requirements: the tolerable recovery time (RTO: Recovery Time Objective) and the tolerable data loss (RPO: Recovery Point Objective).