Backup & disaster recovery για μια βάση δεκάδων TB

Question

IT Interview Practice · Accepted Answer

**Συνδυάστε περιοδικά snapshots με συνεχές WAL archiving για point-in-time recovery, κάντε replicate offsite/cross-region, και αποδείξτε το με τακτικά restore drills έναντι ρητών RPO/RTO targets.** Ένα backup που δεν έχετε ποτέ κάνει restore είναι μια ελπίδα, όχι ένα σχέδιο.

## Αρχιτεκτονική

```text
Primary DB ──snapshot (daily)──▶ Object store (S3) ──cross-region replicate──▶ DR region
     │                               ▲
     └── WAL/binlog stream ──────────┘   (continuous, PITR to any second)
                                          │
                          restore drill ──┴──▶ verified restore ─▶ measure RTO, checksum RPO
```

## Πώς λειτουργεί

- **Τα snapshots** είναι ένα πλήρες αντίγραφο του volume/cluster (π.χ. ημερήσιο EBS snapshot ή `pg_basebackup`). Είναι η βάση *από* την οποία κάνετε restore — αλλά το restore μόνο στην περασμένη νύχτα χάνει μια μέρα writes.
- **Το WAL / binlog archiving** κάνει stream κάθε αλλαγή από το τελευταίο snapshot στο object store συνεχώς. Restore = snapshot + replay WAL μέχρι οποιοδήποτε επιλεγμένο δευτερόλεπτο. Αυτό είναι **PITR (point-in-time recovery)** — ανάκτηση στις 10:32:04, τη στιγμή πριν από ένα κακό `DELETE`.
- **Offsite / cross-region.** Ένα backup στην ίδια περιοχή με τη βάση πεθαίνει μαζί με την περιοχή. Κάντε replicate σε μια δεύτερη περιοχή (S3 cross-region replication) ώστε μια περιφερειακή διακοπή ή ransomware να μην πάρει και τα δύο.
- **Restore drills.** Περιοδικά κάντε restore σε ένα scratch environment, μετρήστε πόσο πήρε (**RTO**) και πόσα δεδομένα θα χάνατε (**RPO**), και κάντε checksum έναντι της prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = πόσα δεδομένα αντέχετε να χάσετε. WAL archiving κάθε 5 λεπτά → RPO ≈ 5 λεπτά. Synchronous replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = πόσο γρήγορα πρέπει να επιστρέψετε. Το restore 20TB από S3 μπορεί να πάρει ώρες· ένα warm standby replica κόβει το RTO σε λεπτά.

## Οπτική συνέντευξης

Ο συνεντευκτής διερευνά αν ξέρετε ότι **τα snapshots μόνα τους δεν αρκούν** (απώλεια δεδομένων μεταξύ τους), αν μπορείτε να **ορίσετε RPO/RTO σε αριθμούς**, και αν **δοκιμάζετε restores**. Εξαιρετικές απαντήσεις τονίζουν ότι τα μη-δοκιμασμένα backups αποτυγχάνουν ακριβώς όταν χρειάζονται, και επιλέγουν στρατηγική από το *επιχειρησιακό* RPO/RTO, όχι από βολικότητα. Μια παγίδα: να θεωρείτε ότι ένα read replica είναι backup — το replication αντιγράφει πιστά και ένα `DROP TABLE`.

## Trade-offs & αποτυχία

- **Κόστος vs RTO.** Ένα warm cross-region standby δίνει λεπτά RTO αλλά διπλασιάζει το κόστος infra· το cold S3 restore είναι φθηνό αλλά αργό. Αγοράστε το tier που πραγματικά χρειάζεται η επιχείρηση.
- **Backup load.** Το snapshot-άρισμα μιας hot 20TB βάσης προσθέτει I/O· πάρτε snapshots από ένα replica.
- **Silent corruption.** Το WAL μπορεί να αρχειοθετήσει ένα corrupt page· περιοδικό full-restore + checksum το πιάνει.
- **Retention & compliance.** Κρατήστε αρκετή ιστορία (π.χ. 35 μέρες PITR + μηνιαία archives) για νομικές ανάγκες· Glacier για φθηνό long-term.
- **Πότε όχι:** μια μικροσκοπική βάση είναι μια χαρά με νυχτερινό `pg_dump` σε S3 — full WAL + cross-region standby είναι υπερβολή μέχρι η απώλεια δεδομένων να μετριέται σε πραγματικά χρήματα.

Αρχιτεκτονική

Πώς λειτουργεί

RPO vs RTO

Οπτική συνέντευξης

Trade-offs & αποτυχία

Σχετικές ερωτήσεις