A 3-2-1 backup szabaly gyakorlatban

A 3-2-1 szabaly egyszeru: 3 masolat az adatrol, 2 kulonbozo media-n, 1 offsite. Tobb evtizede ez az industry default. A nehezseg nem a leiras, hanem a kovetes: minden masolatot rendszeresen ellenorizni, restore-drillt futtatni, es a celidoket (RTO/RPO) tartani. Itt van, ahogy a NIP ezt csinalja a Nortinia adataira.

Mit jelent a 3-2-1 nalunk

Fo adat: Postgres klaszter (NIP control plane DB, kb. 80 GB), plusz a kulonbozo workload-PG-k (osszesen ~600 GB), plusz a MinIO objektum tarolas (S3-kompatibilis, kb. 4 TB).

• Masolat 1 (live) — a Postgres primary node-on, NVMe SSD-n. Ez az aktiv adat.
• Masolat 2 (logical dump, ondemand restore) — 6 oraankent egy pg_dump job egy NFS-mountolt SAN-ra (Synology RS-sorozat, RAID6). 7 napos retention. Ez gyors restore-ra valo, ha egy mernok vegletesen tabla-truncate-et csinalt.
• Masolat 3 (physical, PITR) — folyamatos WAL streaming Hetzner Object Storage-be (S3 kompatibilis). Ez tudja a Point-In-Time Recovery-t. 30 napos retention. Ez offsite is, mert egy masik Hetzner regio.
• Plusz: cold copy — heti egyszer egy restic job a 6 oras dump-ot atmasolja egy nas-ra Salzburgban (egy partner cegnel, fizikailag mas helyen). Ez a "meg a Hetzner Frankfurt is megsemmisul" forgatokonyv. 90 napos retention.

Ez 4 masolat, 3 media tipus (NVMe, SAS HDD a Synology-n, objektumtarolas), 2 offsite (Hetzner FSN1 + Salzburg). A 3-2-1 minimumat tul is teljesiti.

A celidok: RTO 30 perc, RPO 5 perc

• RTO (Recovery Time Objective): 30 perc — egy teljes klaszter veszteseggel a celunk fel oran belul ujraindulni.
• RPO (Recovery Point Objective): 5 perc — maximum 5 perc trazakcio elveszhet (a WAL streamingnek koszonhetoen).

Ezek nem onkenyes szamok. A nortinia uzletunk SLA-ja 99.9% (havi ~43 perc downtime megengedett). Ha egyetlen havi incident a teljes 43 percet eleszi, marad 0 puffer — eppen ezert valasztottunk 30 perces RTO-t.

A havi restore drill

Minden ho elso szerdajan az on-call kotelezo: futtat egy teljes restore drillt. A jatekszabaly:

1. Vakgyakorlat. A drill kornyezet teljesen elszigetelt (sajat namespace, sajat hostname, nincs DNS).
2. Vegig kell csinalni: 6 oras logical dump betoltes, WAL replay 12 ora-ra visszamenoleg, applikacio elindit, smoke test.
3. Az ido a kubectl apply pillanattol szamolva a smoke test "OK"-jaig.
4. Az eredmenyt a NIP-be log-oljuk, a #infra csatornaba poszt megy.

Elmult ev sorend (idok percekben): 28, 31, 29, 47, 33, 27, 30, 25, 29, 31, 28, 26.

A 47 perces drill

A negyedik drill (2025 oktober) 47 perces lett. Mit talaltunk:

1. A WAL replay 22 percig ment — a normal 8-10 perc helyett. Ok: a wal_buffers es a maintenance_work_mem Postgres parameterek a restore kornyezetben az alapertelmezesen voltak. Javitas: a restore Helm chart-ba beirtuk a tuned parametereket.
2. A smoke test 9 percig hibazott — mert a CORS config a restore namespace-re nem volt beallitva, es a smoke test FE-bol hivott BE-t. Javitas: a smoke test mar direkt curl-lal kuld BE keresteet, nem FE-n keresztul.
3. A restic cold copy nem volt a drill scope-jaban — felfedeztuk, hogy soha nem teszteltuk vegig. A kovetkezo drillen mar benne van, plusz egy extra 2 perccel a restore.

Vegeredmeny: a 47 perc tobbe nem ismetlodott. A kovetkezo havi drill: 33 perc (a felemelt tuned parameterekkel + cleaner smoke test-szel).

Mit nem csinalunk

• Continuous data protection (CDP) — minden trazakcio replikalas valos idoben. Tul draga (network bandwidth + storage cost), a 5 perces RPO eleg.
• Backup encryption per-customer kulccsal — szep, de a multi-tenant adatunk a SealedSecrets-szel mar titokositott a sajat klaszterunkben, es a Hetzner S3 server-side encryption-t hasznalunk. Customer-specific kulcs csak compliance kerelemre.
• Tape backup — 2026-ban tobbe nincs ertelme egy Nortinia meretu cegnel.

Szamok

• 4 masolat / 3 media tipus / 2 offsite
• RTO 30 perc / RPO 5 perc
• 12 havi drill az elmult evben, 30 perc median restore idovel
• 0 valodi disaster esemeny (kopjuk le)