Acasă›Ghiduri›DRP și BCP

DRP și BCP

Cum mențineți disponibilă o aplicație de business în timpul unei pane?

O aplicație de business rămâne disponibilă în timpul unei pane dacă o a doua instanță, deja actualizată și deja accesibilă de pe stațiile de lucru, preia activitatea fără ca fiecare utilizator să modifice vreo setare. Dacă sistemul de rezervă există, dar nimeni nu știe cum să se conecteze la el, aplicația este tehnic „salvată” și practic oprită.

Actualizat în octombrie 20263 min de lectură4 surse citate

Pe scurt

  • Patru condiții: date coerente, sistem de rezervă dimensionat corect, cale de rețea pregătită, verificare de business.
  • Baza de date trebuie salvată printr-o metodă care o cunoaște (jurnal de tranzacții, aducere în stare de repaus), nu ca simple fișiere.
  • Păstrarea aceleiași adrese IP este mai transparentă decât o modificare DNS, dar presupune un echipament încă funcțional în sediu.
  • Verificați licența software-ului în mediul de rezervă înainte de pană.
  • Dacă cele patru condiții nu sunt îndeplinite, anunțați un DRP și descrieți în scris modul degradat.

Cele patru condiții

Datele sunt coerente. Aplicația și baza sa de date trebuie copiate împreună, într-o stare pe care motorul bazei de date acceptă să o deschidă. O copie de fișiere realizată în mijlocul unei scrieri poate porni pe o bază de date pe care producătorul o va considera coruptă. Instrumentul de backup sau de replicare trebuie să cunoască baza de date (aducere în stare de repaus, jurnal de tranzacții), nu doar discul. Pentru SQL Server, Microsoft recomandă, în plus, plasarea backupurilor într-o locație fizică separată de fișierele bazei de date și amintește că nu aveți o strategie de restaurare atâta timp cât nu ați restaurat o copie pe un sistem de test și nu i-ați verificat integritatea.

Sistemul de rezervă este dimensionat pentru a lucra, nu doar pentru „a arăta că pornește”. O instanță prea mică pentru zece utilizatori simultani creează o pană software în locul penei hardware.

Calea de rețea este pregătită. Două tehnici uzuale:

  • păstrarea aceleiași adrese IP văzute de stațiile de lucru, datorită unui echipament local care redirecționează către sistemul de rezervă;
  • modificarea unui nume DNS, acceptând timpul de propagare și cache-urile stațiilor de lucru.

Prima este mai transparentă. Ea presupune un agent sau un dispozitiv încă funcțional în sediu. Dacă întregul sediu este distrus (incendiu), nu mai există niciun agent local: utilizatorii la distanță trec atunci printr-o adresă publică de rezervă, cu condiția ca aceasta să fi fost rezervată și testată. BCP-ul pentru un sediu și BCP-ul pentru un singur server nu se pregătesc în același mod.

Cineva verifică aplicația, nu doar sistemul. Deschiderea ecranului de autentificare nu este suficientă. Un utilizator autorizat face operațiunea obișnuită: caută un dosar, emite un document, tipărește.

Comparația celor două căi de rețea

Aceeași adresă IP printr-un echipament localModificarea numelui DNS
Acțiune pe stațiile de lucruNiciunaUneori golirea cache-ului sau repornirea
Durata comutăriiScurtăDepinde de durata de viață (TTL) a înregistrărilor DNS
Funcționează dacă sediul este distrusNuDa, dacă accesul la distanță este pregătit
Punct de atențieEchipamentul local trebuie să supraviețuiascăAdresele scrise direct în codul software-ului

Înainte de pană: lista de verificare

  • Metoda de backup a bazei de date este documentată și a permis deja o restaurare reușită.
  • Dimensiunea sistemului de rezervă a fost validată pentru numărul de utilizatori prevăzut.
  • Calea de rețea a fost testată de pe o stație de lucru obișnuită, nu de pe cea a administratorului.
  • Licența funcționează pe sistemul de rezervă.
  • Un utilizator de business a efectuat o operațiune reală pe sistemul de rezervă la ultimul test. Consultați Cum se testează un DRP?.

Modul degradat

Dacă cele patru condiții nu sunt îndeplinite, abordarea onestă este să anunțați un DRP (reluare după o întrerupere) și să descrieți în scris modul degradat: ce operațiuni pot aștepta, care se notează pe hârtie, cine le reintroduce ulterior. O aplicație „indispensabilă” al cărei mod degradat rezistă o jumătate de zi nu are neapărat nevoie de un sistem de rezervă pornit tot anul. ANSSI, agenția națională franceză de securitate cibernetică, recomandă prevederea din timp a acestor soluții alternative, deoarece o criză de origine cibernetică poate dura mai multe săptămâni.

Licențe și producători de software

Unele aplicații de business leagă licența de un identificator hardware sau interzic găzduirea externă. Verificați acest lucru înainte de pană. Un sistem de rezervă care pornește și apoi se închide din lipsă de licență nu este un sistem de rezervă.

La WeDoBack

Oferta BCP este concepută pentru acest caz: instanțe cloud pornite permanent, agent în rețeaua clientului, legătură VPN IPsec, preluare fără schimbarea adresei IP. Astfel, aplicația rămâne accesibilă de pe stațiile de lucru din sediu atâta timp cât agentul și rețeaua locală există. Pentru ca baza de date a aplicației să fie actualizată pe instanță, iar datele introduse în timpul penei să revină apoi pe serverul reparat, este necesar un proces specific de replicare sau de sincronizare: acesta nu este nativ, iar WeDoBack îl poate implementa pe bază de ofertă. Instanțele pornesc de la 50,22 € fără TVA pe lună, iar stocarea de la 8,75 € fără TVA pe lună pentru 50 GB. Dacă clădirea este distrusă, acest mecanism local nu mai este suficient: sunt necesare adrese publice și un acces la distanță, care țin mai degrabă de oferta DRP cu adrese IP publice (0,54 € fără TVA per adresă pe lună). WeDoBack face backupul pentru SQL Server, Exchange și aplicațiile de business și restaurează serverul și aplicația dacă au fost salvate în mod coerent. WeDoBack nu repară o bază de date copiată oricum: metoda de backup a bazei de date face parte din implementare și trebuie testată în prealabil.

Întrebări frecvente

Pot fi copiate fișierele bazei de date la fel ca celelalte fișiere?

Nu este suficient. O copie realizată în mijlocul unei scrieri poate produce o bază de date pe care motorul va refuza să o deschidă. Este nevoie de un backup care cunoaște baza de date (backup nativ, jurnal de tranzacții sau aducere în stare de repaus). Microsoft amintește, în plus, că o strategie de restaurare există doar după ce backupurile au fost testate pe un sistem de test.

Sistemul de rezervă trebuie să fie la fel de puternic ca serverul de producție?

Trebuie să suporte numărul de utilizatori simultani prevăzut în timpul penei. Un sistem de rezervă subdimensionat transformă o pană hardware într-o problemă de performanță. Puteți accepta un sistem de rezervă ceva mai modest dacă modul degradat reduce numărul de utilizatori, cu condiția să fi măsurat acest lucru.

Ce se întâmplă dacă întreaga clădire este distrusă?

Mecanismele care se bazează pe un echipament local (agent, dispozitiv) dispar odată cu sediul. Utilizatorii trebuie atunci să acceseze sistemul de rezervă din exterior, printr-o adresă publică și un acces la distanță rezervate și testate din timp. Este un scenariu diferit de pana unui server.

Aveți un proiect de backup, DRP sau BCP?

Peste 20 de ani de experiență în protecția datelor companiilor.

Solicitați o ofertă+33 9 72 50 78 28

Protejați-vă datele cu WeDoBack

Backup criptat în afara sediului, stocare imuabilă, DRP și BCP: descrieți-ne serverele dumneavoastră și vă propunem combinația potrivită.