Backup, katasztrófa-helyreállítás és GDPR

20.1Előbb a két szám: RPO és RTO

Mielőtt bármit beállítanál, két kérdésre kell választ adnod — és ezek üzleti, nem technikai döntések:

• RPO (Recovery Point Objective): mennyi adatvesztés fér bele? Öt perc? Egy óra? Egy nap?
• RTO (Recovery Time Objective): mennyi ideig lehet a szolgáltatás használhatatlan? Tíz perc? Négy óra?

Egy tipikus B2B SaaS-nál reális kiindulás: RPO ≈ 1 óra, RTO ≈ 4 óra. Ezt írd le, mert innentől minden döntés (mennyire gyakran exportálsz, mit automatizálsz) ebből következik — és mert egy enterprise ügyfél előbb-utóbb megkérdezi.

20.2Mi romolhat el? — négy forgatókönyv

20.3A helyreállítási terv rétegenként

A heti export — a minimum, amit meg kell csinálni

Egy cron-Worker (7. modul), ami hetente kimenti a lényeget egy külön helyre. Ez a legkisebb munka, ami a 3. forgatókönyv ellen véd:

export class BackupWorkflow extends WorkflowEntrypoint {
  async run(event, step) {
    const stamp = event.payload.stamp;      // a cron adja, determinisztikus ID-hez

    // 1) D1 SQL-export
    const dump = await step.do("export-d1", () => exportDatabase(this.env));

    // 2) titkosítás — a mentés is érzékeny adat!
    const enc = await step.do("encrypt", () =>
      encryptAesGcm(dump, this.env.BACKUP_KEY));

    // 3) elhelyezés FIÓKON KÍVÜL (S3 vagy másik fiók R2-je)
    await step.do("upload-offsite",
      { retries: { limit: 5, delay: "30 seconds", backoff: "exponential" } },
      () => putOffsite(this.env, `backups/${stamp}/db.sql.enc`, enc));

    // 4) ellenőrzés: a feltöltött méret és hash stimmel-e
    await step.do("verify", () => verifyOffsite(this.env, stamp));

    // 5) értesítés — ha ez elmarad, tudni akarsz róla
    await step.do("notify", () => notifySlack(this.env, `backup ok: ${stamp}`));
  }
}

20.4Runbook: mit csinálsz, amikor baj van?

Írd meg előre, egy oldalban, és tedd a repóba. A váza:

1. Állítsd meg a vérzést. Ha kód okozza: wrangler rollback (8. modul, másodpercek). Ha adatot ír felül: kapcsold ki az érintett funkciót (feature flag, 16. modul) vagy tedd karbantartási módba.
2. Mérd fel a kárt. Mikor kezdődött? Melyik tenantokat érinti? Melyik rétegben van a hiba (kód / séma / adat)? A verzió-korrelált logok itt segítenek (9. modul).
3. Döntsd el a stratégiát. Fix-forward (javító szkript) vagy restore? Az esetek többségében a fix-forward a jobb, mert a restore visszaviszi a hiba óta érkezett legitim adatot is (8. modul).
4. Ha restore: lehetőleg szűkítve. Per-tenant D1-nél csak az érintett tenant Time Travelje (5b. modul!) — ez a minta egyik legszebb haszna. Shared DB-nél: állítsd vissza egy másolatba, és onnan emeld át a hiányzó rekordokat, ne az egész éles bázist told vissza.
5. Kommunikálj. Statusz-oldal, érintett ügyfelek értesítése. GDPR-releváns incidensnél az órák számítanak (20.6).
6. Utóelemzés. Mi hiányzott a védvonalakból? Kerüljön be pre-flight ellenőrzésbe, tesztbe vagy riasztásba (8. modul playbookja).

20.5Tenant-törlés: a teljes lista

Amikor egy ügyfél távozik (vagy GDPR-törlést kér), az adatai sok helyen vannak szétszórva. Ez a lista azért fontos, mert a hiányzó tétel az, ami később kellemetlen kérdéssé válik:

20.6GDPR és adatvédelem — a fejlesztőt érintő rész

Nem jogi tanácsadás, hanem az a néhány dolog, ami a te architektúrádban dől el (a szerződéses részhez kérj jogi segítséget):

20.7Amit érdemes negyedévente elvégezni

• Restore-próba: export → friss staging → az app elindul rajta (20.3).
• Tenant-törlés próbája egy teszt-tenanttal, a teljes lista alapján (20.5).
• Secret-rotáció a fontos kulcsokra, a sorrendre figyelve (8. modul).
• API-token-audit: mely tokenek léteznek, milyen hatókörrel, ki használja őket.
• Alfeldolgozói lista frissítése (új szolgáltató? új AI-modell?).
• Runbook átolvasása — és javítása azzal, amit az elmúlt negyedév incidenseiből tanultatok.

20.8Ellenőrizd magad