OnLinux.ro

, ,

Disaster Recovery pentru Homelab: cum reconstruiești un server după pierderea totală

👁 3 vizualizări

Backup-ul pare un subiect teoretic până în ziua în care serverul nu mai pornește.

Poate fi un SSD defect, un filesystem corupt, o actualizare eșuată, un controller de storage mort, un ransomware, o comandă greșită executată ca root sau pur și simplu o placă de bază care nu mai pornește.

Într-un astfel de moment nu mai discutăm despre backup. Discutăm despre Disaster Recovery: procesul prin care reconstruim infrastructura și readucem serviciile în funcțiune folosind copiile de siguranță și documentația existentă.

În ghidul introductiv despre backup pentru homelab am discutat despre protejarea datelor, iar în ghidul strategiei 3-2-1 am construit o arhitectură de backup cu Restic, Borg, Kopia și alte soluții gratuite.

Acum mergem până la capăt și simulăm scenariul pe care sperăm să nu îl întâlnim niciodată:

Serverul principal a fost pierdut complet și trebuie reconstruit de la zero.

Scenariul de Disaster Recovery

Vom presupune că infrastructura inițială arăta astfel:

Internet
   |
   |
Router / Firewall
192.168.10.1
   |
   |
+---------------------------+
| homelab01                 |
| Ubuntu / Debian Linux     |
| 192.168.10.10             |
|                           |
| Docker                    |
| Reverse proxy             |
| PostgreSQL / MariaDB      |
| Nextcloud                 |
| Vaultwarden               |
| Grafana                   |
| WireGuard                 |
| alte servicii             |
+---------------------------+
           |
           |
     storage local
           |
           +------ backup local
           |
           +------ backup off-site

Serverul homelab01 este acum indisponibil definitiv.

Presupunem că avem:

  • backup Restic sau Borg;
  • dump-uri ale bazelor de date;
  • fișiere Docker Compose;
  • fișiere de configurare;
  • secretele necesare;
  • parolele repository-urilor;
  • documentația infrastructurii.

Disaster Recovery nu este același lucru cu restore

Restore înseamnă de obicei recuperarea unui fișier, a unei baze de date sau a unei mașini virtuale.

Disaster Recovery este mai larg.

Trebuie să reconstruim:

  • sistemul de operare;
  • storage-ul;
  • rețeaua;
  • utilizatorii și permisiunile;
  • runtime-ul aplicațiilor;
  • configurațiile;
  • bazele de date;
  • serviciile;
  • DNS-ul;
  • TLS-ul;
  • monitorizarea;
  • backup-ul însuși.

RTO decide ordinea restaurării

Nu toate serviciile trebuie restaurate în aceeași ordine.

Într-un homelab putem avea această prioritate:

Prioritate Serviciu Țintă orientativă
P0 rețea, DNS, autentificare imediat
P1 reverse proxy, baze de date < 1 oră
P1 Vaultwarden, Home Assistant < 1 oră
P2 Nextcloud câteva ore
P3 Jellyfin, media mai târziu

Ordinea exactă depinde de infrastructura ta, dar este util să fie stabilită înaintea incidentului.

Pasul 1: nu modifica backup-ul original

După un incident major, prima regulă este să nu transformăm singura copie validă într-un mediu de test.

Dacă este posibil:

  • montează mediul de backup read-only;
  • clonează disk-ul dacă există suspiciuni hardware;
  • nu executa prune sau cleanup;
  • nu șterge snapshot-uri;
  • nu modifica repository-ul înainte de verificare.

Pasul 2: verifică repository-ul înainte de restaurare

Pentru Restic:

restic \
  -r /mnt/backup/restic-homelab \
  --password-file /root/restic-password \
  snapshots

și:

restic \
  -r /mnt/backup/restic-homelab \
  --password-file /root/restic-password \
  check

Pentru Borg:

borg list /mnt/backup/borg-homelab

și:

borg check /mnt/backup/borg-homelab

Pasul 3: alegerea hardware-ului de recovery

Noul server nu trebuie să fie identic fizic cu cel vechi.

Dar trebuie să verificăm:

  • suficient spațiu de stocare;
  • suficient RAM;
  • arhitectura CPU;
  • numărul și tipul interfețelor de rețea;
  • compatibilitatea cu filesystem-ul;
  • suportul pentru virtualizare dacă avem VM-uri;
  • accesul la mediul de backup.

Pasul 4: instalăm un sistem Linux curat

Pentru un restore previzibil prefer o instalare minimală a aceleiași familii de distribuție și, ideal, aceeași versiune majoră.

Exemple:

  • Ubuntu LTS;
  • Debian Stable;
  • AlmaLinux;
  • Rocky Linux.

După instalare:

sudo apt update
sudo apt full-upgrade

sau:

sudo dnf upgrade

Pentru configurarea inițială completă vezi Instalare și configurare Linux Server: ghid și bune practici.

Pasul 5: reconstruim storage-ul înainte de aplicații

Nu instala Docker înainte să știi unde vor locui datele.

lsblk
lsblk -f
findmnt
df -h

Dacă infrastructura veche folosea, de exemplu:

/srv
/mnt/storage
/mnt/media
/opt/stacks

este util să recreăm aceleași mountpoints pentru a reduce modificările necesare în fișierele Compose și configurații.

Filesystem și UUID

După formatare verificăm UUID-urile:

blkid

și configurăm persistent:

/etc/fstab

Înainte de reboot:

sudo mount -a

Dacă această comandă returnează erori, nu reporni serverul înainte să corectezi configurația.

Pasul 6: reconstruim rețeaua

Ideal, serverul nou va primi aceeași adresă internă ca serverul pierdut:

192.168.10.10

Asta simplifică foarte mult:

  • DNS-ul;
  • firewall-urile;
  • rutele;
  • reverse proxy;
  • clienții interni;
  • automatizările;
  • monitorizarea.

Verificări de rețea

ip -br addr
ip route
resolvectl status 2>/dev/null || true
ping -c 3 1.1.1.1
getent hosts onlinux.ro

Pasul 7: reconstruim utilizatorii administrativi

Nu restaura orbește întregul /etc/passwd peste sistemul nou.

Este mai sigur să reconstruim explicit utilizatorii necesari:

sudo adduser admin
sudo usermod -aG sudo admin

Pe distribuțiile RHEL-like:

sudo usermod -aG wheel admin

Pasul 8: restaurăm accesul SSH

Restaurăm doar fișierele relevante și verificăm permisiunile:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Pentru un server compromis, cheile vechi trebuie evaluate înainte de reutilizare.

Pasul 9: aplicăm hardening-ul înainte să expunem serviciile

Nu restaurăm aplicațiile și abia apoi configurăm securitatea.

Minimum:

  • SSH cu chei;
  • firewall;
  • actualizări;
  • Fail2ban unde este relevant;
  • SELinux sau AppArmor;
  • servicii inutile dezactivate.

Vezi Securizarea unui Linux Server după instalare: ghid complet.

Pasul 10: instalăm runtime-ul aplicațiilor

Dacă infrastructura folosește Docker, instalăm mai întâi Docker Engine și pluginul Compose.

Verificăm:

docker version
docker compose version

Nu avem nevoie să restaurăm imaginile Docker. Acestea pot fi descărcate din nou din registry, dacă sunt încă disponibile.

Pasul 11: instalăm Restic pe serverul nou

Ubuntu și Debian:

sudo apt install restic

AlmaLinux și Rocky Linux:

sudo dnf install restic

Pasul 12: conectăm repository-ul de backup

Pentru un disk local:

mount /dev/sdX1 /mnt/backup

Verificăm:

findmnt /mnt/backup
df -h /mnt/backup

Repository Restic remote prin SFTP

Dacă backup-ul este off-site:

export RESTIC_REPOSITORY="sftp:[email protected]:/srv/restic/homelab01"

și:

export RESTIC_PASSWORD_FILE="/root/restic-password"

Verificăm accesul:

restic snapshots

Pasul 13: nu restaura direct peste sistemul nou

Într-un recovery important prefer să restaurez mai întâi într-un director temporar:

mkdir -p /restore

Apoi:

restic restore latest \
  --target /restore

Vom obține o structură similară:

/restore/
├── etc/
├── opt/
│   └── stacks/
├── srv/
└── var/
    └── backups/

Acum putem compara și restaura controlat doar ceea ce avem nevoie.

De ce nu restaurăm /etc integral?

Fișierul /etc conține atât configurațiile aplicațiilor, cât și informații care depind de sistemul instalat.

Copierea completă peste o instalare nouă poate introduce:

  • configurații pentru pachete inexistente;
  • UID-uri și GID-uri nepotrivite;
  • configurații de rețea vechi;
  • fișiere systemd incompatibile;
  • setări kernel nedorite;
  • credentiale compromise.

Restaurează selectiv.

Exemplu de restore selectiv

rsync -aHAX \
  /restore/opt/stacks/ \
  /opt/stacks/

Pentru date:

rsync -aHAX \
  /restore/srv/ \
  /srv/

Nu presupune însă că proprietarii și UID/GID-urile sunt automat corecte. Verifică:

ls -lan /srv
ls -lan /opt/stacks

Pasul 14: restaurăm fișierele Docker Compose

O structură bine organizată ajută enorm în disaster recovery:

/opt/stacks/
├── reverse-proxy/
│   ├── compose.yml
│   └── .env
├── nextcloud/
│   ├── compose.yml
│   └── .env
├── vaultwarden/
│   ├── compose.yml
│   └── .env
└── monitoring/
    ├── compose.yml
    └── .env

Validăm Compose înainte să pornim containerele

cd /opt/stacks/nextcloud

docker compose config

Dacă există variabile lipsă sau erori YAML, este mai bine să le descoperim acum decât după pornirea parțială a stack-ului.

Pasul 15: nu porni încă bazele de date cu volume vechi la întâmplare

Dacă avem dump-uri logice, preferăm să pornim o instanță curată a motorului de baze de date și să importăm datele.

Această strategie evită multe probleme legate de schimbarea versiunii motorului.

Restore MariaDB / MySQL

Dacă backup-ul conține:

mysql-all.sql.gz

îl putem verifica mai întâi:

gzip -t mysql-all.sql.gz

Apoi importul poate fi realizat, în funcție de configurație, cu:

gunzip -c mysql-all.sql.gz \
  | mysql -u root -p

Restore PostgreSQL

Pentru un dump creat cu pg_dumpall:

gzip -t postgresql-all.sql.gz

Apoi:

gunzip -c postgresql-all.sql.gz \
  | sudo -u postgres psql

Versiunea bazei de date contează

În special la PostgreSQL, nu presupune că poți copia pur și simplu directorul de date între versiuni majore diferite.

Dump-urile logice sunt foarte utile în disaster recovery tocmai pentru că reduc dependența de layout-ul fizic al bazei de date.

Pasul 16: restaurăm serviciile în ordinea dependențelor

O ordine tipică:

1. rețea
2. storage
3. baza de date
4. cache / Redis
5. aplicație
6. reverse proxy
7. DNS
8. monitoring

Dacă pornim aplicația înaintea bazei de date, vom genera doar erori suplimentare care complică analiza.

Exemplu: restaurarea unui stack Nextcloud

Să presupunem că avem:

/opt/stacks/nextcloud/
/srv/nextcloud-data/
/var/backups/databases/nextcloud.sql.gz

Ordinea poate fi:

1. restaurează compose.yml
2. restaurează .env
3. recreează volume/directoare
4. pornește doar baza de date
5. importă dump-ul SQL
6. restaurează fișierele Nextcloud
7. verifică owner/group
8. pornește aplicația
9. verifică logurile
10. pornește reverse proxy

Pornire controlată cu Docker Compose

Putem porni doar serviciul bazei de date:

docker compose up -d db

Verificăm:

docker compose ps
docker compose logs db

Apoi pornim restul:

docker compose up -d

Pasul 17: verificăm permisiunile

Multe restore-uri eșuează din cauza UID/GID-urilor, nu din cauza datelor.

ls -ln /srv/nextcloud-data

Dacă aplicația rulează cu UID 1000, iar fișierele aparțin unui UID care nu mai există, accesul poate fi refuzat.

Corectarea trebuie făcută numai după ce cunoaștem UID-ul real folosit de aplicație.

Pasul 18: restaurăm reverse proxy-ul

Reverse proxy-ul este de obicei unul dintre serviciile critice deoarece toate aplicațiile publice depind de el.

Poate fi:

  • Caddy;
  • Nginx;
  • Traefik;
  • HAProxy;
  • Nginx Proxy Manager.

Înainte de pornire verificăm dacă porturile sunt disponibile:

sudo ss -ltnp | grep -E ':80|:443'

Testăm aplicația direct înainte de reverse proxy

Dacă aplicația ascultă local pe portul 8080:

curl -I http://127.0.0.1:8080

Abia dacă acest test funcționează are sens să investigăm HTTPS sau proxy-ul.

Pasul 19: DNS

Dacă serverul nou păstrează IP-ul vechi, este posibil ca DNS-ul să nu necesite nicio modificare.

Dacă IP-ul s-a schimbat, actualizăm înregistrările relevante.

dig example.com
dig A example.com
dig AAAA example.com

Local:

getent hosts example.com

TTL-ul DNS influențează recovery-ul

Dacă ai un TTL de 24 de ore, schimbarea IP-ului în timpul unui incident poate avea nevoie de mult timp pentru propagare în cache-urile existente.

Pentru infrastructuri unde schimbarea rapidă a endpoint-ului este importantă, un TTL moderat poate simplifica failover-ul.

Pasul 20: certificate TLS

Dacă reverse proxy-ul folosește ACME, poate fi mai sigur să permitem generarea unor certificate noi decât să restaurăm orbește certificate expirate.

Verificare:

curl -Iv https://example.com

Sau:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  </dev/null

Pasul 21: WireGuard și VPN

Dacă serverul avea rol de endpoint WireGuard, trebuie restaurate configurația și cheia privată sau trebuie generate chei noi.

Configurațiile se află de obicei în:

/etc/wireguard/

Pentru un incident de tip compromitere, este mai sigur să considerăm cheile vechi compromise și să facem key rotation.

Vezi și Instalare și configurare WireGuard Server pe Linux.

Verificare WireGuard

sudo systemctl status wg-quick@wg0
sudo wg show
ip addr show wg0
ip route

Pasul 22: firewall-ul

Nu restaura reguli vechi fără să verifici numele interfețelor noului hardware.

Serverul vechi poate fi avut:

ens18

iar cel nou:

enp3s0

Verifică:

ip -br link

UFW

sudo ufw status verbose

Firewalld

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

Pasul 23: SELinux sau AppArmor

Nu dezactiva mecanismele de securitate doar pentru că aplicația restaurată nu pornește.

Pe AlmaLinux și Rocky Linux:

getenforce

Pe Ubuntu și Debian:

sudo aa-status

Dacă există probleme de policy, investighează logurile înainte de a dezactiva protecția.

Pasul 24: verificarea serviciilor systemd

systemctl --failed

Pentru un serviciu:

systemctl status docker
systemctl status ssh

Pasul 25: verificarea logurilor

journalctl -b -p warning

Și pentru Docker:

docker compose logs --tail=100

Pentru o metodologie completă vezi Diagnosticarea și monitorizarea unui Linux Server.

Pasul 26: verificarea funcțională, nu doar tehnică

Faptul că un container este „Up” nu demonstrează că aplicația funcționează corect.

Pentru Nextcloud, de exemplu, verificăm:

  • login;
  • fișiere;
  • upload;
  • download;
  • database connectivity;
  • background jobs;
  • cache;
  • WebDAV;
  • TLS.

Health check cu curl

curl -sS -o /dev/null \
  -w '%{http_code}\n' \
  https://service.example.com

Un răspuns 200 este un început bun, dar pentru aplicațiile critice putem verifica și API-uri sau endpoint-uri dedicate de health.

Pasul 27: verificăm datele, nu doar aplicația

După restore verificăm exemple concrete:

  • fișiere vechi și noi;
  • numărul de înregistrări;
  • utilizatorii aplicației;
  • fotografii;
  • documente;
  • configurații;
  • timestamp-uri.

Checksum-uri pentru date importante

Pentru anumite fișiere putem folosi:

sha256sum important-file.img

Dacă avem checksum-ul anterior, putem verifica dacă fișierul restaurat este identic.

Pasul 28: reconstruim monitorizarea

Monitoring-ul nu trebuie lăsat pentru „mai târziu”. După disaster recovery vrem să știm imediat dacă sistemul începe din nou să aibă probleme.

Minimum:

  • CPU;
  • RAM;
  • disk;
  • filesystem;
  • servicii;
  • HTTP/HTTPS;
  • certificate TLS;
  • backup.

Pasul 29: reconstruim sistemul de backup imediat

Una dintre cele mai periculoase situații este să terminăm disaster recovery-ul și să lăsăm noul server fără backup câteva săptămâni.

După validarea serviciilor:

restic backup \
  /etc \
  /opt/stacks \
  /srv

Apoi reconstruim timer-ul sau mecanismul de automatizare.

Nu suprascrie imediat singurul backup vechi

După recovery este prudent să păstrăm snapshot-urile de dinaintea incidentului pentru o perioadă.

Este posibil să descoperim ulterior că un fișier, un secret sau un tabel nu a fost restaurat corect.

Exemplu de plan de Disaster Recovery

FAZA 1 - Stabilizare
--------------------
[ ] server nou disponibil
[ ] backup protejat
[ ] repository verificat
[ ] parole de recovery disponibile

FAZA 2 - Infrastructură
-----------------------
[ ] Linux instalat
[ ] actualizări
[ ] storage
[ ] fstab
[ ] rețea
[ ] SSH
[ ] firewall
[ ] hardening

FAZA 3 - Platformă
------------------
[ ] Docker
[ ] Compose
[ ] directoare
[ ] UID/GID
[ ] secrete

FAZA 4 - Date
-------------
[ ] restore Restic/Borg
[ ] baze de date
[ ] volume
[ ] configurații

FAZA 5 - Servicii
-----------------
[ ] database
[ ] Redis/cache
[ ] aplicații
[ ] reverse proxy
[ ] WireGuard
[ ] DNS
[ ] TLS

FAZA 6 - Validare
-----------------
[ ] health checks
[ ] login
[ ] date
[ ] logs
[ ] monitoring

FAZA 7 - Protecție
------------------
[ ] backup nou
[ ] backup off-site
[ ] test restore
[ ] documentație actualizată

Exemplu de inventar pentru homelab

Un fișier simplu poate face diferența între un restore de două ore și unul de două zile.

HOST:
homelab01

OS:
Ubuntu LTS

IP:
192.168.10.10

GATEWAY:
192.168.10.1

DNS:
192.168.10.2

STORAGE:
/srv
/mnt/media

STACKS:
/opt/stacks/

BACKUP:
Restic

REPOSITORY LOCAL:
/mnt/backup/restic-homelab

REPOSITORY REMOTE:
sftp:backup@backup02:/srv/restic/homelab01

SERVICES:
reverse-proxy
nextcloud
vaultwarden
postgresql
redis
grafana
wireguard

Infrastructure as Code ajută enorm

Cu cât configurația serverului este mai declarativă, cu atât Disaster Recovery devine mai simplu.

Exemple:

  • Docker Compose;
  • Ansible;
  • Terraform;
  • cloud-init;
  • scripturi shell versionate;
  • fișiere de configurare documentate.

Dacă un serviciu poate fi reconstruit din cod și configurație, nu mai depindem atât de mult de restaurarea unei imagini complete a sistemului.

Backup plus Infrastructure as Code

Infrastructure as Code
        |
        v
reconstruiește sistemul

Backup
        |
        v
restaurează datele

        +
        |
        v

Disaster Recovery rapid

Secret management

Infrastructure as Code nu înseamnă să publicăm secretele într-un repository Git.

Fișierele precum:

.env
private.key
wg0.conf
credentials.json

trebuie protejate separat.

Disaster Recovery după compromitere este diferit

Dacă serverul a murit din cauza hardware-ului, putem reutiliza în general credentialele existente.

Dacă serverul a fost compromis, presupunem că secretele accesibile acelui sistem pot fi compromise.

Trebuie rotite, după caz:

  • cheile SSH;
  • cheile WireGuard;
  • parolele bazelor de date;
  • token-urile API;
  • parolele aplicațiilor;
  • certificatele private;
  • credentialele cloud;
  • cheile de backup cu drept de scriere.

Nu restaura malware-ul împreună cu datele

După compromitere, restaurarea completă a filesystem-ului vechi poate readuce exact mecanismul care a compromis serverul.

De aceea instalarea curată și restaurarea selectivă sunt deseori mai sigure decât clonarea integrală a sistemului.

Disaster Recovery pentru Proxmox

Dacă infrastructura folosește Proxmox VE și Proxmox Backup Server, recuperarea poate fi mult mai rapidă.

Strategia:

1. instalează Proxmox VE
2. configurează rețeaua
3. adaugă storage
4. conectează Proxmox Backup Server
5. restaurează VM-urile critice
6. restaurează containerele LXC
7. verifică MAC/IP
8. verifică serviciile
9. restaurează restul workload-urilor

Nu restaura toate VM-urile simultan

După un incident este mai bine să restaurăm întâi infrastructura critică:

DNS
 ↓
database
 ↓
reverse proxy
 ↓
aplicații critice
 ↓
monitoring
 ↓
servicii non-critice

Ce faci dacă backup-ul principal este corupt?

Acesta este motivul pentru care folosim strategia 3-2-1.

Ordinea poate fi:

repository local
      ↓
repository off-site
      ↓
copie offline
      ↓
snapshot secundar

Dacă toate copiile sunt doar replici ale aceluiași repository corupt, redundanța fizică nu ne ajută suficient.

Ce faci dacă nu ai ultimul backup?

Dacă ultimul backup valid este de ieri, trebuie să acceptăm RPO-ul planificat.

Nu încerca să reconstruiești date lipsă prin improvizații care pot compromite și copia validă.

Test de Disaster Recovery fără incident real

Cea mai bună metodă este să simulăm recuperarea pe un server sau VM izolat.

VM nouă
   |
   +-- Linux curat
   |
   +-- Restic/Borg
   |
   +-- restore
   |
   +-- Docker
   |
   +-- aplicație
   |
   +-- test date

Astfel descoperim problemele fără presiunea unui incident real.

Nu conecta imediat serverul de test la producție

Un restore test poate conține:

  • job-uri programate;
  • email-uri automate;
  • webhooks;
  • integrări API;
  • backup jobs;
  • DNS update scripts.

Într-o rețea de test acestea pot produce efecte reale dacă au acces la Internet sau la serviciile de producție.

Checklist rapid de Disaster Recovery

  1. Protejează backup-ul existent.
  2. Identifică ultimul snapshot valid.
  3. Verifică integritatea repository-ului.
  4. Confirmă parola și cheile de recovery.
  5. Pregătește hardware sau VM de înlocuire.
  6. Instalează Linux curat.
  7. Actualizează sistemul.
  8. Recreează storage-ul.
  9. Configurează mountpoint-urile.
  10. Configurează rețeaua.
  11. Recreează accesul administrativ.
  12. Aplică hardening-ul.
  13. Instalează Docker/runtime-ul necesar.
  14. Instalează clientul de backup.
  15. Conectează repository-ul.
  16. Restaurează inițial într-un director temporar.
  17. Restaurează configurațiile selectiv.
  18. Recreează UID/GID unde este necesar.
  19. Restaurează bazele de date.
  20. Restaurează volumele persistente.
  21. Validează Docker Compose.
  22. Pornește serviciile în ordinea dependențelor.
  23. Verifică reverse proxy-ul.
  24. Verifică DNS-ul.
  25. Verifică certificatele TLS.
  26. Verifică VPN-ul.
  27. Verifică firewall-ul.
  28. Verifică SELinux/AppArmor.
  29. Verifică systemd.
  30. Verifică logurile.
  31. Testează funcțional aplicațiile.
  32. Verifică date reale.
  33. Reactivează monitoring-ul.
  34. Reactivează backup-ul.
  35. Fă un backup nou al sistemului restaurat.
  36. Actualizează documentația.

Un recovery nu este terminat când site-ul răspunde cu HTTP 200

Serviciul trebuie verificat din perspectiva utilizatorului.

Pentru o aplicație self-hosted verificăm:

[ ] login
[ ] citire date
[ ] scriere date
[ ] upload
[ ] download
[ ] database
[ ] email
[ ] job-uri programate
[ ] API
[ ] HTTPS
[ ] backup nou

Ce documentăm după incident?

După stabilizarea sistemului trebuie să răspundem la câteva întrebări:

  • care a fost cauza incidentului?
  • ce a funcționat bine?
  • ce informații lipseau?
  • cât a durat recuperarea?
  • care a fost pierderea de date?
  • ce pas a consumat cel mai mult timp?
  • ce putem automatiza?
  • ce backup nu era necesar?
  • ce backup lipsea?

Post-mortem fără vinovați

Scopul analizei de după incident nu este să găsim persoana care a executat comanda greșită.

Scopul este să construim un sistem în care aceeași greșeală nu poate produce din nou același dezastru.

Exemple:

Problema:
backup-ul era pe același disk

Soluția:
copie off-site


Problema:
nimeni nu știa parola repository-ului

Soluția:
procedură de recovery offline


Problema:
restore-ul bazei de date nu fusese testat

Soluția:
restore test trimestrial

Un plan bun trebuie să poată fi executat și de altcineva

Dacă Disaster Recovery depinde exclusiv de faptul că administratorul își amintește 50 de detalii din memorie, planul este fragil.

Documentația trebuie să permită unui administrator competent să reconstruiască infrastructura fără acces la memoria autorului ei.

Exemplu de document DR minimal

DISASTER RECOVERY - HOMELAB

Server:
homelab01

OS:
Ubuntu LTS

IP:
192.168.10.10

Backup:
Restic

Repository:
backup02:/srv/restic/homelab01

Recovery password:
vezi password manager / copie offline

Ordine servicii:
1. PostgreSQL
2. Redis
3. Nextcloud
4. Vaultwarden
5. Reverse Proxy
6. Monitoring

DNS:
router / internal DNS

VPN:
WireGuard wg0

Restore test:
trimestrial

Cât de des trebuie testat Disaster Recovery?

Pentru un homelab obișnuit, o simulare completă anuală este deja mult mai bună decât zero teste.

Pentru serviciile importante putem face:

  • restore de fișiere lunar;
  • restore SQL trimestrial;
  • restore VM trimestrial;
  • Disaster Recovery complet anual.

Concluzie

Disaster Recovery nu începe în momentul în care serverul moare. Începe atunci când alegem cum organizăm datele, unde păstrăm configurațiile, cum facem backup și cât de bine documentăm infrastructura.

Un homelab construit din fișiere Docker Compose, configurații versionate, dump-uri regulate ale bazelor de date și repository-uri de backup separate poate fi reconstruit mult mai repede decât un server construit manual în ultimii cinci ani și pe care nimeni nu mai știe exact ce s-a modificat.

Într-un incident real, ordinea contează: protejăm backup-ul, reconstruim sistemul de bază, restaurăm datele într-un mediu controlat, pornim serviciile după dependențe și verificăm funcțional fiecare componentă.

După recovery, reconstruim imediat sistemul de backup și monitorizare. Altfel noul server devine din nou un single point of failure.

Backup-ul îți păstrează datele. Disaster Recovery îți reconstruiește infrastructura.

Pentru a construi fundația acestei strategii, citește și Backup pentru Homelab și Self-hosting: strategia 3-2-1, apoi testează restaurarea înainte ca primul test să fie impus de un incident real.