DR-checklist – palautettavuus käytännössä (tekninen)

Perusperiaate

Backup ilman restore-testausta on toiveajattelua. DR (Disaster Recovery) tarkoittaa, että sinulla on dokumentoitu polku ja todisteet siitä, että palautus toimii.

RPO (Recovery Point Objective): kuinka paljon dataa saa kadota (aika).
RTO (Recovery Time Objective): kuinka nopeasti palvelu pitää saada ylös.
Runbook: konkreettiset komennot ja järjestys, ei “kyllä se jostain palautuu”.

1) Ennen kuin mitään tapahtuu (valmiustaso)

Inventoi: mitä pitää palauttaa (www, db, cront, konfigit, secrets, certit).
Tallenna “lähde totuudelle”: repo / vault / dokumentti, josta DR-ohje löytyy.
Varmista pääsy: hostingin console/KVM, cPanel, SSH, DNS-hallinta, domain-tili.
Pidä yhteystiedot: palveluntarjoaja, domain, kriittiset tunnukset, offline-kopio.

Käytännön nyrkkisääntö: jos et pääse sisään ilman selaimen salasana-automaattia, sinulla ei ole DR:ää. Sinulla on toivoa.

2) Backuppien “todisteet” (manifesti ja checksumit)

Hyvä backup sisältää metadatan: mitä pakattiin, milloin, millä versiolla, ja millä checksumilla. Vähintään:

manifest.txt (listaus sisällöstä + keskeiset versiot)
SHA256SUMS (arkistot + kriittiset dumpit)
logit (onnistuiko ajot, mitä varoitti)

# Esimerkki: checksumit
sha256sum *.tar.gz *.sql.gz > SHA256SUMS
sha256sum -c SHA256SUMS

Jos checksumit eivät täsmää: älä “kokeile restorea ja katso”. Tee uusi backup ja tutki rikkoutuminen.

3) DR-checklist (kun hätä on päällä)

Tilannekuva: mikä on rikki? (www, db, DNS, cert, palvelin, tunnukset)
Stop the bleeding: estä lisävahinko (offline, maintenance, salasanat).
Valitse palautus: viimeisin hyvä backup vai “edellinen varma”.
Varmista checksumit ennen palautusta.
Palauta järjestyksessä:
- konfigit / runtime / oikeudet
- tiedostot (www)
- tietokannat (db dump import)
- cront / ajastukset
- DNS / TLS / sertit
Smoke test: aukeaako etusivu, kirjautuminen, lomakkeet, admin.
Logit: tarkista virheet (web, php, db).
Dokumentoi: mitä tehtiin ja miksi (post-mortem myöhemmin).

4) Testipalautus (se osa jonka ihmiset “tekee myöhemmin”)

Tee testipalautus säännöllisesti. Jos sinulla ei ole erillistä stagingia, tee vähintään “minimipalautus” paikallisesti:

Pura arkisto tyhjään hakemistoon ja varmista rakenne.
Importtaa DB dump paikalliseen/erilliseen DB:hen.
Varmista että kriittiset tiedostot löytyvät (config.php, .env, uploadit).

# Esimerkki: pura ja tarkista
mkdir -p /tmp/restore-test
tar -xzf site-www.tar.gz -C /tmp/restore-test
ls -lah /tmp/restore-test | head

Hyvä mittari: testipalautuksen pitäisi olla dokumentoitu niin, että joku muu (tai väsyneen päivän sinä) pystyy tekemään sen.

5) Runbook-malli (kopioi ja täytä)

DR RUNBOOK – {{SERVICE}}
- Palvelu: {{domain/app}}
- RPO: {{x h}}
- RTO: {{x h}}
- Pääsyt:
  - Console/KVM: {{url/ohje}}
  - SSH: {{host/user}}
  - cPanel: {{url}}
  - DNS: {{provider}}
- Backup-sijainti: {{vault path}}
- Palautusjärjestys:
  1) {{configs}}
  2) {{www restore}}
  3) {{db import}}
  4) {{cron}}
  5) {{tls/dns}}
- Smoke test:
  - {{url 1}}
  - {{url 2}}
- Post-restore:
  - logit ok?
  - monitorointi?
  - tee uusi backup

Tee tästä oma versio jokaiselle domainille (nousiainen.eu, it-huoltomies.fi, publattahattu...).

Yhteenveto

DR ei ole “backup on olemassa”, vaan “restore toimii”.
Manifesti + checksumit + logit = todisteet.
Testipalautus tekee tästä oikean järjestelmän, ei uskomuksen.

Kun palautus on dokumentoitu, hätätilanne muuttuu “työlistaksi”. Se on koko DR:n pointti.