Disaster Recovery

Ljubo Brodarić

ljubo@brodaric.com

Sadržaj

DR definicija, uzroci, komponente

DR u „Enterprise” i „običnoj” okolini

DR u oblaku

Definicija

Disaster recovery je skup procedura i alata za oporavak IT sustava od katastrofe uzrokovane

prirodnim ili ljudskim faktorom.

Uzroci Prirodni

potres, cunami, požar, udar meteorita… Ljudski

nestručnost, napad hakera, virusi, teroristički napad…

Hardware/Software Failure

20%

External Security Threats

12%

Natural Disasters12%

Power Outages10%

Employee Error10%

Data Leakage or Loss8%

IT Problem10%

Others18%

Hardware/Software FailureExternal Security ThreatsNatural DisastersPower OutagesEmployee ErrorData Leakage or LossIT ProblemOthers

Symantec Annual IT Survey Results

Business continuity

Komponente DR-a i korištenje Visoka dostupnost (High Availability)

je dizajn i implementacija sustava koja nam osigurava dogovoreni nivo operativnosti (downtime).

Replikacija je proces dupliciranja podataka i osiguravanja

njihove konzistentnosti. HW ili SW sinkrona ili asinkrona

Backup i restore je izrada pričuvnih kopija podataka i njihov povrat.

Koriste se za: file servise, print servise, database servise, Hyper-V...

Failover klaster (On-site DR) „Enterprise” rješenje potpuno automatizirano gotovo nevidljivo klijentima

Failover klaster (Off-site DR)

Dva servera (On-site i Off-site DR) pogodno za manje tvrtke stupanj automatizacije nizak zahtijeva određenu reakciju klijenata

Dva servera (On-site i Off-site DR) File servisi

automatizacija putem DFS-a (nije optimalno za velike datoteke)

Print servisi identična instalacija na oba servera klijenti se moraju sami prebaciti na novi server

Hyper-V moguće jedino ako možemo pristupiti do vhd

datoteka nema automatizacije najveći downtime od svih servisa

Dva SQL servera (On-site i Off-site DR) Database mirroring

kopira transakcije iz loga s „principala” na „mirror” server

sinkroni (high safety) ili asinkroni (high performance) mod

samo jedan mirror za svaku principal bazu nije preporučljivo za više od 10 baza zbog resursa baza na mirroru je nedostupna (Restoring state) oprez s visoko transakcijskim bazama (log može

rasti u beskonačnost) vrijeme failovera <3s pogodno za servere koji su blizu i povezani su

dobrim linkom

Dva SQL servera (On-site i Off-site DR) Log shipping

periodički backup loga, kopiranje i restore na sekundarnom serveru

neograničen broj kopija primarne baze na sekundarnim serverima

baza na sekundarnom serveru je dostupna (Read-only state), može se koristiti za Reporting

asinkroni mod traži učestali backup loga što može utjecati na performanse

pogodno za servere koji su daleko i povezani su relativno lošim linkom

Recovery model SQL baze

Recovery model

Opis RizikRecovery do kojeg trenutka?

Simple

Ne zahtijeva log backup.

Automatski oslobađa prostor u logu nakon svakog checkpointa (backup).

Promjene nakon zadnjeg backupa su nezaštićene. U slučaju katastrofe potrebno je rekonstruirati transakcije.

Recovery moguć samo do kraja zadnjeg backupa.

Full

Zahtijeva log backup.

Ne gube se transakcije uslijed gubitka ili oštećenja mdf datoteke.

Recovery moguć za bilo koji trenutak (npr. prije korisničke ili aplikacijske greške).

Veoma malen.

U slučaju oštećenja tail loga, promjene od zadnjeg log backupa moraju se rekonstruirati.

Recovery moguć do bilo kojeg trenutka , uz pretpostavku da imamo cjeloviti backup do tog trenutka (log chain).

Bulk logged

Zahtijeva log backup.

Sličan full recovery modelu, služi za high-performance bulk operacije.

Reducira log koristeći minimalno logiranje bulk operacija.

Ako je log oštećen ili je bilo bulk-logged operacija od zadnjeg log backupa, promjene od zadnjeg log backupa moraju se rekonstruirati.

Za sve ostale slučajeve rizik ne postoji.

Recovery moguć samo do kraja bilo kojeg backupa. Point-in-time recovery nije podržan.

Backup SQL-a (Simple recovery model)

Backup SQL-a (Full recovery model)

Backup SQL-a Radite backup uz checksum

Zadržite barem jedan prethodni backup set

Povremeno napravite restore backupa (preporučljivo na neki drugi server)

Provjeravajte povremeno bazu (dbcc dbcheck)

DR u oblaku Modeli

IaaS (Hyper-V) – briga o cjelokupnom DR PaaS (Azure) – aplikacija mora podržavati HA i DR SaaS (Office 365) – davatelj usluge se brine o svemu

Private cloud nije zamjena za DR Hyper-V klaster je „samo” HA virtualna platforma

Public cloud Vaši podaci nisu gdje i vi. Ili…? Da li davatelj usluge replicira podatke u disperzirane

datacentre? Koga kontaktirati u slučaju problema?

Zaključak

Procijenite rizik i dozvoljenu nedostupnost

Izradite detaljan plan DR-a uzimajući u obzir procjenu i cijenu

Testirajte ga!!!

Hvala na pažnji!