Backup and Recovery Fundamentals Questions

Core principles and techniques for protecting, storing, and restoring data. Topics include backup models and types such as full, incremental, and differential backups; snapshotting and replication approaches; transaction log management and write ahead logging for databases; point in time recovery and continuous log based recovery; trade offs between Recovery Time Objective and Recovery Point Objective and how business requirements drive those trade offs; backup storage architectures for file systems and databases including local, off site, and geo redundant storage; backup scheduling, retention lifecycle and policy governance including encryption and compliance; and verification and integrity checks to ensure backups are restorable. Candidates should be able to describe step by step restore procedures, validation and testing techniques, common failure scenarios, and decision trade offs when choosing backup approaches for different application types.

EasyTechnical

31 practiced

Explain crash-consistent and application-consistent backups. Describe what each captures, why application consistency matters for databases and transactional systems, and simple techniques (on Linux and Windows) to achieve application-consistent snapshots.

MediumTechnical

32 practiced

Technical-domain question: You run PostgreSQL 12 on Linux and archive WAL files to S3. Describe, step by step, how you would restore the database to a specific timestamp (e.g., 2026-02-15T13:47:20Z). Include how to obtain the base backup, prepare configuration (recovery settings), and replay WAL files from S3 until the target time.

Sample Answer

**Approach (high level)**Restore = 1) Obtain a consistent base backup taken before target time, 2) configure recovery to replay WALs from S3 up to the timestamp, 3) start Postgres and monitor until recovery_target_time is reached, then promote.

**Step-by-step**

1. Confirm target and stop Postgres- Target: 2026-02-15T13:47:20Z- On the standby/restore host stop Postgres cleanly:

bash

sudo systemctl stop postgresql-12

2. Obtain base backup- Find the most recent base backup whose start_time < target. If you use wal-g/wal-e, list backups:

bash

wal-g backup-list
wal-g backup-fetch /var/lib/postgresql/12/main BACKUP_NAME

- If backups are stored as tarball on S3, download and extract:

bash

aws s3 cp s3://my-pg-backups/basebackups/base_2026-02-14.tar.gz /tmp/
tar -xzf /tmp/base_2026-02-14.tar.gz -C /var/lib/postgresql/12/main
chown -R postgres:postgres /var/lib/postgresql/12/main

3. Prepare WAL access (restore_command)- Ensure WAL archive strategy: WAL files in s3://my-pg-wal/…- Create a script or use aws cli directly. Example restore_command in postgresql.conf (we will use recovery.signal instead of legacy recovery.conf):

bash

# in /var/lib/postgresql/12/main/postgresql.conf (or include file)
restore_command = 'aws s3 cp s3://my-pg-wal/%f %p || test -f /var/lib/postgresql/12/main/%f'

- Make sure the Postgres user has AWS credentials (IAM role or ~/.aws/credentials).

4. Configure recovery to stop at timestamp- Create recovery.signal file and set recovery_target_time plus restore_command in postgresql.conf (or recovery.conf old style).

bash

# create recovery.signal to enable recovery mode
touch /var/lib/postgresql/12/main/recovery.signal

# add to postgresql.conf or include file:
recovery_target_time = '2026-02-15 13:47:20+00'
recovery_target_action = 'promote'    # or 'pause' to inspect
restore_command = 'aws s3 cp s3://my-pg-wal/%f %p'

5. Ensure wal_level and timeline considerations- If you need a specific timeline, set recovery_target_timeline = 'latest' or a specific id.

6. Start Postgres and monitor

bash

sudo systemctl start postgresql-12
tail -f /var/log/postgresql/postgresql-12-main.log

- Postgres will call restore_command for each WAL segment. Watch logs for errors like missing WAL → fetch from S3 or re-run wal-g wal-fetch.

7. Verify and promote- When logs show recovery completed to target time, confirm with:

bash

psql -c "SELECT pg_is_in_recovery(), now();"
SELECT pg_last_xact_replay_timestamp();

- If recovery_target_action = 'promote' it will automatically switch to read-write. If 'pause', promote manually:

bash

pg_ctl -D /var/lib/postgresql/12/main promote

**Edge cases & troubleshooting**- Missing WAL segments: check S3 path/permissions and that restore_command pattern matches filenames (%f).- Encryption or multipart uploads: ensure aws cli can access full objects.- Corrupt base backup: try an earlier base backup + more WALs.- Timezones: always use UTC or confirm timezone in recovery_target_time.

**Why this works**- Base backup provides consistent image; WAL replay applies changes up to the requested timestamp. restore_command fetches WAL segments on demand from S3 so replay proceeds until recovery_target_time.

MediumSystem Design

33 practiced

Design question: You need to replicate backups to two cloud regions for compliance. Discuss replication strategies across regions for backups including asynchronous replication, scheduling large initial seeding, bandwidth management, eventual consistency implications, and recovery considerations when failing over to a secondary region.

EasyTechnical

37 practiced

List and explain key techniques used to verify backup integrity and restoreability: cryptographic checksums, metadata validation, periodic full restores, synthetic verification, and automated smoke tests. For each technique explain frequency and pros/cons.

HardTechnical

36 practiced

Design a backup encryption and key management scheme where backups are encrypted using customer-managed keys (BYOK) stored in an enterprise KMS/HSM. Describe key lifecycle (creation, envelope keys, rotation, backup/escrow, revocation), how to rotate keys without losing access to existing encrypted backups, and recovery options if keys are lost or compromised.

Sample Answer

**Situation & Goals (one line)** Design BYOK backup encryption where customer-managed keys live in enterprise KMS/HSM; ensure safe key lifecycle, rotation without data loss, and recovery if keys lost/compromised.

**Key concepts & pattern** - Use envelope encryption: generate ephemeral Data Encryption Keys (DEKs) per backup; wrap (encrypt) DEKs with Customer Master Keys (CMKs) stored in HSM/KMS (Key-Encrypting Keys, KEKs). Store wrapped DEKs with the backups.

**Key lifecycle**- Creation: Create CMK in HSM with strong policy (auth methods, roles). Generate DEK per backup using CSPRNG on backup host.- Envelope keys: DEK encrypts backup payload; DEK is wrapped by CMK via KMS Encrypt/Wrap API. Store wrapped DEK + metadata (CMK id, algorithm, key version).- Rotation: Rotate CMK by creating a new CMK/version in HSM. Do not re-encrypt all backups immediately — keep old CMK usable to unwrap historical DEKs.- Backup/Escrow: Export only wrapped DEKs and CMK public info to an encrypted key escrow store (separate HSM or offline vault) using split‑knowledge (Shamir) or quorum access. Log and hash for integrity.- Revocation: Revoke CMK permissions in KMS; mark key state as disabled/compromised. Maintain policy to deny further wrap operations but allow unwrap if needed unless explicitly destroyed.

**Rotating keys without losing access**- Two-step approach: 1. New backups: use new CMK to wrap DEKs (new key version). 2. Existing backups: either keep old CMKs available to unwrap (best practice) OR perform proactive rewrap: for each backup, unwrap DEK with old CMK, then rewrap with new CMK (create background rewrap job). Track key version metadata to know which CMK to call for unwrap.- Use key version identifiers and KMS audit logs to route unwrap calls.

**Recovery and compromise handling**- If CMK compromised: - Immediately disable CMK to stop new wraps. Identify affected backups via metadata. - If attacker only had wrapped DEKs but not HSM keys, wrapped DEKs remain safe. - For recovery: use escrowed key material (split across trustees) to reconstruct CMK or use HSM restore to recover key version; then unwrap DEKs and rewrap to new CMK. - If CMK destroyed and no escrow: offline recovery impossible — plan for legal/operational consequences (data unrecoverable). Mitigate by maintaining escrow/backup of wrapped key material and periodic key export procedures allowed by policy.- If keys lost accidentally: use quorum-based escrow to restore CMK; if not available, use backup copies of wrapped DEKs and CMK backup stored in tamper-evident offline vault.

**Operational controls & best practices**- Enforce least privilege, MFA for key operations, role separation (operators vs. custodians).- Regularly test restore and key-restore runbooks (tabletop + live drills).- Automate rewrap jobs, maintain inventory (which backups use which key version).- Retain disabled keys long enough for restores per retention policy before scheduled destruction.- Audit and monitor all KMS/HSM operations, alert on anomalies.

This scheme ensures encrypted backups remain recoverable across rotations while giving admins control to revoke, recover, and audit keys in enterprise HSM/KMS.

Unlock Full Question Bank

Get access to hundreds of Backup and Recovery Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.