O institutie de invatamant superior din Transilvania rula sistemul informatic central pe o baza Oracle pe un server Dell PowerEdge R550 cu controller Dell PERC H755, 10 discuri HDD SAS 558 GB 15k RPM in RAID10 + 1 hot spare. La ora 04:00 dimineata, 6 din 10 discuri au trecut offline simultan. Sub 24 de ore am readus totul in productie — fara inlocuire de discuri.
Contextul
Configuratia parea solida pe hartie:
- Server Dell PowerEdge R550
- Controller RAID hardware Dell PERC H755
- 10 discuri HDD SAS 558 GB @ 15k RPM in array RAID10
- 1 disc hot spare (care, logic, nu intra in array decat la cedare confirmata)
- Baza Oracle, sistem informatic central al institutiei
Backup-ul rula automat in fiecare noapte. La 03:00 backup-ul fusese executat cu succes pe alt server. Problema reala nu era lipsa backup-ului — era ca nu exista un server gata pregatit sa ruleze acel backup: sa primeasca restore-ul, sa porneasca Oracle pe el si sa preia rolul productiv in cateva ore.
Asta a facut ca strategia sa fie restaurarea hardware-ului original, nu deployment-ul unui server nou din backup.
Problema
La ora 04:00, controllerul PERC H755 a marcat 6 din cele 10 discuri din array ca offline aproape simultan. Hot spare-ul a ramas neutilizat — degradarea era prea masiva pentru ca un singur disc de rezerva sa poata repara array-ul. Volumul a disparut din sistemul de operare, baza Oracle s-a oprit brusc cu fisiere de date inconsistente.
6 discuri raportate simultan offline intr-un RAID10 (conform log-urilor iDRAC) — statistic nu exista ca defectiune fizica reala. Asta a fost prima pista: discurile nu erau cu defect fizic — fusesera trecute logic offline de catre controller, dintr-o eroare tranzitorie (backplane, expander SAS, firmware glitch).
Doua probleme suprapuse, in ordinea corecta de rezolvat:
- Stratul de stocare — array-ul RAID10 inaccesibil la nivel PERC H755.
- Stratul de date — baza Oracle oprita necontrolat, fisiere de date inconsistente.
Diagnoza
Verificarea log-urilor PERC H755 + SMART pe fiecare disc SAS a confirmat ipoteza: toate cele 6 discuri "offline" erau fizic functionale, fara sectoare relocate masiv, fara erori PRE-FAIL, fara counter-uri SMART critice. Problema era de stare logica in controller, nu de hardware mort.
Decizia de strategie: nu deployment server nou din backup-ul de la 03:00 (dureaza semnificativ — provisioning, instalare Oracle, restore, validare), ci readucerea controlata a discurilor in array pe hardware-ul existent. Avantaj: ne aducem aminte ca pierderea reala de date ar fi de maxim 1 ora (intre backup 03:00 si incident 04:00) — fie ce restore am face.
Interventia
Pasul 1 — Readucerea array-ului PERC H755 online
Discurile functionale au fost reintroduse in configuratia array-ului fortand foreign config import pe PERC H755, cu atentie la ordinea si rolul fiecarui disc in perechile RAID10. Array-ul a revenit in stare degraded, dar citibil — exact ce era nevoie pentru a ajunge la fisierele bazei.
Pas critic: orice operatiune de scriere gresita in aceasta faza — orice tentativa de rebuild prematur — poate distruge definitiv parity si datele. S-a lucrat in read-only mode pana la confirmare integritate.
Pasul 2 — Recuperarea bazei Oracle
Cu volumul citibil din nou, baza Oracle era inca intr-o stare inconsistenta — oprita necontrolat in timpul incidentului. Recuperarea s-a facut pe baza fisierelor redo log, care inregistrau tranzactiile, permitand Oracle sa aduca fisierele de date la o stare consistenta (instance/media recovery) si sa finalizeze sau sa anuleze tranzactiile ramase in aer.
Rezultat: baza a pornit curat, recovery a folosit redo log-urile post-03:00, deci nici macar ora dintre ultimul backup si incident nu a fost pierduta.
Rezultatul
- ✅ Array RAID10 refacut pe PERC H755 fara inlocuire de discuri — defectiunea era logica
- ✅ Baza Oracle recuperata din redo log, repusa in productie
- ✅ Pierdere de date critice: zero pentru tranzactiile confirmate
- ✅ Downtime total: sub 24 ore (vs zile pentru provisioning server nou + restore + validare)
- ✅ Cost suplimentar: zero hardware (vs €30-50k pentru recuperare profesionala de pe discuri raportate offline (iDRAC) + server nou)
Ce am invatat din acest caz
Cazul reusit a expus exact problemele care trebuie auditate inainte:
- Un backup fara server gata sa-l ruleze nu e o strategie DR completa. Aici am avut noroc ca hardware-ul era recuperabil. Daca discurile aveau cu adevarat defect fizic, restore-ul ar fi durat zile, nu ore — pentru ca trebuia provisioning + Oracle install + import + validare.
- "RAID nu e backup." RAID10 + hot spare protejeaza de cedarea unui disc, nu de cadere de controller, eroare umana sau ransomware.
- Single point of failure documentat. Baza critica pe un singur server fizic, fara replicare hot-standby, e risc de business.
Recomandarea noastra post-incident pentru clienti similari: warm-standby server pre-configurat (sau Hyper-V/Proxmox cluster cu replicare VM-level) — backup-ul ajunge instant intr-un mediu gata sa porneasca, RTO scade de la ore la minute.
Ai un server critic single-point-of-failure?
Facem audit de infrastructura care se uita la intrebari concrete: ce se intampla cand pica controllerul la 04:00 noaptea? Cat dureaza pana aplicatia revine? Ai un server gata sa primeasca restore-ul? Backup-ul a fost testat la restore saptamana asta?