VMware

Visoka dostupnost, backup i disaster recovery rešavaju različite klase problema. vSphere HA ponovo pokreće virtuelnu mašinu kada host otkaže, ali ne vraća podatke koje je aplikacija već oštetila i ne pomaže ako ceo primarni lokalitet postane nedostupan. Backup čuva nezavisne tačke oporavka, ali sam po sebi ne obezbeđuje redosled pokretanja desetina zavisnih sistema, promenu mrežnih parametara i dokaz da će poslovna usluga proraditi u zadatom roku. Disaster recovery (DR) objedinjuje ljude, infrastrukturu, kopije podataka, automatizovani tok oporavka i proveru aplikacije. Njegov rezultat nije „replika postoji”, već dokaz da se definisana poslovna usluga može vratiti u prihvatljivo stanje, sa poznatim gubitkom podataka i u poznatom vremenu.

Ova lekcija se oslanja na backup i restore iz lekcije 36, monitoring iz lekcije 37, sistematičnu dijagnostiku iz lekcije 38 i kontrolisane promene iz lekcije 46. Fokus je na dizajnu i proveri DR sistema: od poslovnih zahteva i domena otkaza, preko vSphere Replication ili storage replikacije, do recovery plan-a, izolovanog testa, planned migration-a, disaster failover-a, reprotect-a i failback-a. Trijaža incidenta, support bundle i formalna analiza osnovnog uzroka detaljno se obrađuju u sledećoj lekciji.

1. Od poslovnog uticaja do tehničkog cilja oporavka

DR projekat ne počinje izborom proizvoda, već analizom poslovnog uticaja (Business Impact Analysis, BIA). Vlasnik usluge određuje koje poslovne funkcije moraju biti vraćene, koje degradirano stanje je privremeno prihvatljivo i koliko podataka organizacija sme da izgubi. Administrator zatim prevodi zahteve u merljive ciljeve, zavisnosti i tehničke kontrole. Ako su ciljevi preuzeti iz opšte politike bez merenja stvarnog vremena podizanja baze, DNS promene ili aplikacione provere, plan je samo pretpostavka.

Ciljeve treba definisati po usluzi ili recovery tier-u, ne jednim brojem za sve VM-ove. Tier 0 može obuhvatiti identitet, DNS, vreme, KMS i upravljačku ravan bez kojih ostale grupe ne mogu da se oporave. Tier 1 obuhvata kritične transakcione aplikacije, a niži tier-ovi sisteme koji mogu čekati ili biti obnovljeni iz backupa. Kraći RPO povećava količinu promena koje mreža i ciljni storage moraju da prihvate; kraći RTO zahteva unapred rezervisan compute, automatizaciju i česta testiranja. Zbog toga svaki cilj mora imati vlasnika, cenu i rezultat poslednjeg testa.

Minimalni karton DR usluge

• naziv usluge, poslovni vlasnik, tehnički vlasnik i kontakt za deklaraciju katastrofe;
• recovery tier, RPO, RTO, maksimalno tolerisana nedostupnost i dozvoljeno degradirano stanje;
• VM-ovi, baze, eksterni SaaS sistemi, identitet, DNS, NTP, PKI, KMS, firewall i load balancer zavisnosti;
• redosled i uslovi pokretanja, readiness provere, test transakcija i kriterijum prihvatanja;
• metod zaštite, retention recovery points, enkripcija, odgovorna lica i break-glass pristup;
• datum poslednjeg testa, izmereni RPO/RTO, odstupanja, otvorene korektivne mere i rok ponovnog testa.

2. Pretnje, domeni otkaza i izbor DR topologije

Dizajn mora početi eksplicitnim scenarijima: gubitak jednog hosta, storage sistema, management plane-a, mrežne zone, zgrade, regiona, administratorskog identiteta ili integriteta podataka. Dva sajta ne znače automatski dva nezavisna domena otkaza. Zajednički WAN čvor, isti identity provider, jedna KMS instanca, rastegnuti Layer 2 bez alternativnog rutiranja ili zajednička administrativna privilegija mogu pretvoriti lokalni kvar ili napad u istovremeni gubitak oba sajta.

DR sajt mora imati dovoljno resursa za recovery skup, a ne nužno kopiju kompletnog primarnog sajta. Ipak, računica mora uključiti HA rezervu, management VM-ove, replikacioni overhead, privremene test VM-ove i resurse za reprotect. DRS affinity/anti-affinity pravila, host grupe, resource pool mapiranja i storage policy moraju biti ponovo smisleni na ciljnom sajtu. Nije bezbedno pretpostaviti da će ista imena mreža ili datastore-a značiti i istu bezbednosnu zonu.

3. Replikacija nije backup: modeli i kriterijumi izbora

Replikacija održava operativnu kopiju blizu trenutnog stanja i prvenstveno smanjuje RPO/RTO. Ona može veoma brzo preneti brisanje, ransomware enkripciju ili aplikacionu korupciju. Backup mora imati odvojenu politiku zadržavanja, po mogućnosti immutable ili administrativno izolovanu kopiju, i dokaz restore-a. DR plan zato bira između replike i backup recovery tačke prema vrsti incidenta; najnovija replika nije uvek najbezbednija tačka.

Synchronous replication može potvrditi upis tek kada je prihvaćen na oba domena, pa može približiti RPO nuli, ali povećava latency i ne štiti od logičke greške. Asynchronous replication šalje promene naknadno; njen ostvareni RPO zavisi od change rate-a, raspoloživog bandwidth-a, latencije, ciljnog storage-a i backlog-a. Kompresija, enkripcija u tranzitu, QoS i raspored inicijalnih sinhronizacija moraju se projektovati zajedno sa mrežnim timom.

4. Arhitektura vSphere Replication i tok podataka

vSphere Replication je host-based mehanizam. Promene virtuelnih diskova prati se na izvornom ESXi hostu, a podaci se prenose ka vSphere Replication server komponenti na ciljnom sajtu i upisuju u replica diskove. vSphere Replication appliance obezbeđuje management servis i može se proširiti dodatnim replication serverima u skladu sa podržanom arhitekturom. Management saobraćaj i data path nisu ista stvar; firewall pravila i dijagnostika moraju pratiti smer i komponentu konkretnog toka.

Inicijalna sinhronizacija može preneti kompletne diskove ili, gde je podržano i pravilno pripremljeno, iskoristiti seed kopiju kako bi se smanjio WAN transfer. Seed nije proizvoljna kopija: identitet i sadržaj diskova moraju odgovarati dokumentovanom postupku. Posle inicijalne sinhronizacije prenose se promene prema RPO politici. Multiple point in time (MPIT) recovery points mogu omogućiti izbor starije tačke, ali troše dodatni prostor i nisu zamena za backup retention.

Konzistentnost podataka

• Crash-consistent tačka odgovara stanju posle naglog gubitka napajanja; guest OS i aplikacija moraju izvršiti sopstveni recovery.
• File-system quiescing, kada je podržan i uspešan, pokušava da umiri I/O kroz VMware Tools. To nije automatski isto što i aplikaciono konzistentan backup baze.
• Application-consistent rezultat zahteva aplikaciono podržan mehanizam, pre/post skripte ili izvornu replikaciju baze, zajedno sa testom stvarne transakcione konzistentnosti.

Za VM sa velikim change rate-om administrator mora izmeriti prosečan i vršni dnevni churn. Gruba početna procena potrebnog efektivnog protoka je količina promenjenih podataka podeljena raspoloživim vremenom prenosa, uz rezervu za protokolarni overhead, retransmisije i istovremenu inicijalnu sinhronizaciju. Merenje backlog-a i RPO violation-a važnije je od teorijske brzine linka.

Potrebni efektivni protok ≈ promenjeni podaci u intervalu / raspoloživo vreme prenosa

Primer: 180 GiB promena tokom 8 h
180 × 8 / (8 × 3600) ≈ 0,05 Gib/s ≈ 50 Mib/s

Rezultat nije dimenzionisanje: dodaju se vršni faktor, overhead, konkurentne replike,
inicijalne sinhronizacije i bezbednosna rezerva.

5. Orkestracija: site pair, mapiranja, protection group i recovery plan

Live Site Recovery/SRM povezuje upravljačke ravni dva sajta i orkestrira oporavak replika. Tipičan dizajn sadrži uparene instance, vCenter Server na svakom sajtu, odgovarajući replikacioni mehanizam, mapiranja inventara, protection groups i recovery plans. Orkestrator ne projektuje aplikaciju umesto administratora: ako nisu poznate zavisnosti, plan će pouzdano automatizovati pogrešan redosled.

Recovery plan treba graditi po aplikacionom toku. Priority grupe obezbeđuju grubi redosled, dok se zavisnosti između VM-ova koriste kada određeni servis mora biti spreman pre drugog. „VM je powered on” nije dovoljan uslov; readiness se proverava portom, API health endpoint-om, statusom baze ili kontrolisanom test transakcijom. Custom command ili prompt treba da bude determinističan, vremenski ograničen, idempotentan koliko je moguće i da ne sadrži lozinke. Ako korak zahteva ljudsku odluku, mora imenovati ulogu, dokaz i uslov za nastavak.

6. Mreža, identitet i bezbednost tokom oporavka

Najčešći razlog da tehnički oporavljen VM ne postane dostupna usluga jeste nepotpun mrežni dizajn. Postoje tri osnovna modela: očuvanje IP adrese uz stretched network, promena IP parametara na recovery sajtu ili kombinacija sa globalnim load balancing-om/DNS preusmeravanjem. Stretched Layer 2 pojednostavljuje adresiranje, ali širi broadcast i bezbednosni domen i zahteva zaštitu od istovremenog aktiviranja obe kopije. Promena IP-a zahteva proveru statičkih konfiguracija, DNS TTL-a, firewall objekata, sertifikata, licenciranja vezanog za adresu i aplikacionih allow-list pravila.

Test network mora biti izolovana od produkcije kako testna kopija ne bi slala e-poštu, obrađivala produkcione redove, ažurirala DNS ili stupila u kontakt sa stvarnim payment/OT sistemima. Auto-created isolated network može biti dovoljna za jednostavan test jednog VM-a, ali višeslojna aplikacija obično zahteva unapred projektovan izolovani segment sa testnim DNS-om, rutiranjem i emuliranim zavisnostima. Obezbediti administrativni pristup kroz kontrolisani jump host, a ne povezivanjem testnog segmenta sa produkcijom „samo na trenutak”.

• Oba sajta moraju imati pouzdan DNS, NTP i PKI; vremenska razlika može pokvariti autentikaciju i korelaciju događaja.
• Break-glass nalozi moraju biti lokalno upotrebljivi ako je centralni identity provider deo incidenta, uz MFA i kontrolisano čuvanje gde je primenljivo.
• KMS/key provider mora biti dostupan sa recovery sajta i imati bezbedno obnovljivu konfiguraciju; bez ključa encrypted VM ili vTPM workload može ostati neupotrebljiv.
• Servisni nalozi koriste najmanje privilegije prema zvaničnom privilege modelu; aktivnosti se audit-uju na oba vCenter-a i orkestratoru.
• Sertifikate ne treba zaobilaziti opcijom za ignorisanje grešaka u produkcionoj automatizaciji; ispraviti trust chain i DNS identitet.

7. Test, planned migration, disaster recovery, reprotect i failback

Kontrolne kapije odluke

1. Deklaracija: ovlašćena poslovna i tehnička lica potvrđuju scenario, obim i izabranu recovery tačku.
2. Fencing: incident commander dobija dokaz da stari autoritet ne može da prima ili zapisuje produkcione transakcije.
3. Tehnički recovery: orkestrator izvršava plan; svaki ručni override se beleži.
4. Validacija: infrastrukturne, aplikacione i poslovne provere potvrđuju podatke i funkciju.
5. Preusmeravanje: tek zatim se menja DNS/GSLB/load balancer ili korisnički pristup.
6. Stabilizacija: monitoring, backup i replikacija se prilagođavaju novom autoritativnom sajtu.

8. Operativni nadzor, logovi i dokazi

DR stanje treba nadzirati svakodnevno, a ne samo pred godišnji test. Minimalni dashboard prikazuje zdravlje site pair-a, stanje svih replika, trenutni lag, RPO violations, poslednji uspešan recovery point, slobodan prostor ciljnog datastore-a, throughput/backlog, stanje protection group-a, datum i ishod poslednjeg testa. Alarm mora imati vlasnika i vreme reakcije; višednevna crvena replika poništava ugovoreni RPO čak i ako produkcija radi bez simptoma.

Tačne putanje logova zavise od verzije i appliance-a, zato se uz incident beleže build i komponenta, a lokacija potvrđuje u zvaničnom troubleshooting vodiču. Za podršku se generiše support bundle kroz administrativni interfejs proizvoda i čuva uz vremensku zonu, recovery plan history i incident ID. Ne menjati nasumično log nivo u produkciji: verbose/trace može povećati potrošnju diska i treba ga uključiti samo kontrolisano, za ograničen period.

9. Sistematičan troubleshooting DR toka

Dijagnostika ide od najmanje invazivnog ka rizičnijem: sačuvati recovery history i vremensku liniju; utvrditi obim; proveriti poslednje promene, alarme i zavisnosti; formulisati jednu proverljivu hipotezu; potvrditi je iz najmanje dva povezana izvora; primeniti najmanju reverzibilnu korekciju; ponoviti validaciju. Resync, remove protection, brisanje placeholder-a, ponovno uparivanje sajtova ili ručna manipulacija replica diskovima menjaju stanje i ne koriste se kao „probaj pa vidi”.

Model nalaza za incident

• Simptom: šta je opaženo i u koje vreme.
• Obim i posledica: koje replike/usluge i koji RPO/RTO su ugroženi.
• Neposredni uzrok: tehnički događaj koji je proizveo simptom.
• Osnovni uzrok: zašto kontrola nije sprečila ili rano otkrila događaj.
• Zaobilazno rešenje: privremena mera, njen rizik i rok uklanjanja.
• Trajna mera: promena dizajna, procedure, monitoringa ili kapaciteta i dokaz ponovnim testom.

10. Praktikum – od inventara do dokazanog recovery plan-a

Topologija i početno stanje

Zaštićeni sajt A                         Recovery sajt B
vc-a.lab.example                        vc-b.lab.example
lsr-a / VR appliance  ===== WAN =====  lsr-b / VR appliance
PG-PROD: 192.0.2.0/24                   PG-DR: 198.51.100.0/24
APP01 + DB01                            replica datastore + test bubble

Tok usluge: klijent → APP01:443 → DB01:5432
Recovery redosled: infrastruktura zavisnosti → DB01 → APP01 → health/test transakcija

Potrebni su namenski laboratorijski vCenter i orkestrator/replication appliance na oba sajta, kompatibilni build-ovi, DNS forward i reverse rezolucija, NTP, validni sertifikati, datastore kapacitet i nalog sa dokumentovanim minimalnim privilegijama. Administrator mora imati pristup vSphere Client-u, appliance administraciji, VCF PowerCLI-ju i aplikacionim testovima. Pre početka zabeležiti stanje VM-ova, slobodan prostor, mrežna mapiranja i backup konfiguracije appliance-a.

Vežba 1 – DR inventar i merljivi zahtevi

Cilj: pre konfiguracije dokazati da je recovery skup potpun i da su ciljevi merljivi. Rizik je nizak jer je vežba read-only.

1. Sa poslovnim vlasnikom popuniti karton usluge: RPO 30 minuta, RTO 90 minuta, dozvoljen test bez spoljnog slanja i kriterijum „uspešan login, čitanje i rollback test transakcije”.
2. U PowerCLI konzoli povezanoj sa oba laboratorijska vCenter-a prikupiti stanje VM-ova. Kredencijale uneti interaktivno; ne smeštati ih u skriptu.

$vcA = Connect-VIServer -Server "vc-a.lab.example" -Credential (Get-Credential)
$vcB = Connect-VIServer -Server "vc-b.lab.example" -Credential (Get-Credential)

Get-VM -Server $vcA -Name "APP01","DB01" |
  Select-Object Name, PowerState,
    @{N="Host";E={$_.VMHost.Name}},
    @{N="Datastore";E={($_ | Get-Datastore).Name -join ","}},
    @{N="Networks";E={($_ | Get-NetworkAdapter).NetworkName -join ","}}

Get-Datastore -Server $vcB |
  Select-Object Name, State,
    @{N="FreeGiB";E={[math]::Round($_.FreeSpaceGB,1)}},
    @{N="CapacityGiB";E={[math]::Round($_.CapacityGB,1)}}

Komande samo čitaju stanje. Očekivani rezultat je kompletan APP01/DB01 skup, poznate mreže i dovoljan ciljni kapacitet sa rezervom za recovery points i test. U vSphere Client-u potvrditi tagove vlasništva, alarme i zavisnosti. Ako se inventar razlikuje od kartona usluge, zaustaviti konfiguraciju i uskladiti CMDB; automatizacija nepotpunog skupa samo ubrzava nepotpun oporavak.

Vežba 2 – Konfiguracija replikacije i validacija RPO-a

Cilj: zaštititi APP01 i DB01 vSphere Replication-om prema laboratorijskoj RPO politici. Promena stanja je srednjeg rizika jer stvara replica diskove i mrežno/storage opterećenje.

1. U vSphere Client-u otvoriti Site Recovery, potvrditi site pair i zdravlje vSphere Replication komponenti.
2. Izabrati Configure Replication za oba VM-a, recovery sajt B, ciljni datastore i storage policy. Ne prihvatati podrazumevanu lokaciju bez provere kapaciteta i bezbednosne klase.
3. Postaviti laboratorijski podržan RPO i broj point-in-time instanci u okviru kapaciteta. Opciju quiescing uključiti samo ako je podržana i prethodno testirana sa VMware Tools i aplikacijom.
4. Pokrenuti konfiguraciju i pratiti inicijalnu sinhronizaciju. Ne pokretati paralelno veliki broj full sync poslova.
5. Posle statusa OK uneti kontrolisanu promenu u aplikaciju, sačekati narednu recovery tačku i zabeležiti ostvareni lag.

Očekivani rezultat je Active/OK replika bez RPO violation-a, sa svim nameravanim diskovima i recovery point politikom. Proveriti Tasks/Events, appliance health, slobodan prostor i mrežni throughput. Ako sinhronizacija zaostaje, prvo utvrditi change rate, backlog, packet loss i target latency. Rollback laboratorije je plansko uklanjanje replikacije kroz proizvodni interfejs tek po završetku svih vežbi; ne brisati replica VMDK ručno.

Vežba 3 – Site pair, mapiranja i recovery plan

Cilj: napraviti ponovljiv plan za dvoslojnu aplikaciju. Promena je srednjeg rizika i ostaje u laboratorijskom inventaru.

1. Potvrditi site pairing i identitete obe strane. Ispraviti DNS, NTP ili sertifikat pre nastavka; ne koristiti trajno ignorisanje TLS grešaka.
2. Kreirati resource, folder i network mapping. Posebno podesiti test network mapping ka izolovanom segmentu.
3. Izabrati placeholder datastore dostupan svim recovery hostovima, odvojen po operativnoj politici od replica destinacije.
4. Kreirati protection group PG-APP-DEMO sa APP01 i DB01 i potvrditi status Protected.
5. Kreirati recovery plan RP-APP-DEMO. DB01 postaviti u raniju priority grupu, APP01 iza njega, uz readiness proveru baze pre nastavka.
6. Dodati dokumentovan callout/prompt za test transakciju. Skripta ne sme sadržati tajnu niti menjati produkcioni DNS.

Kriterijum završetka je plan bez unresolved protection ili mapping grešaka, sa jasno prikazanim redosledom i izolovanom testnom mrežom. Rollback je uklanjanje recovery plan-a i protection group-a kroz interfejs samo ako nisu potrebni za naredne vežbe; pre toga sačuvati konfiguracioni zapis i screenshot mapiranja.

Vežba 4 – Automatizovana read-only provera PowerCLI-jem

VCF PowerCLI se izvršava na administratorskoj stanici. Sledeći primer uspostavlja sesiju; sama konekcija ne pokreće recovery, ali pristupa osetljivoj upravljačkoj ravni. Tačan API model i metode iz ExtensionData proveriti za instalirani modul i server build, jer nisu svi objekti predstavljeni klasičnim cmdlet-ima.

Import-Module VMware.VimAutomation.Core
Import-Module VMware.VimAutomation.Srm

$vc = Connect-VIServer -Server "vc-a.lab.example" -Credential (Get-Credential)
$remoteCredential = Get-Credential -Message "Nalog za recovery SRM/LSR sajt"
$srm = Connect-SrmServer -Server $vc -RemoteCredential $remoteCredential

$srm | Select-Object Name, IsConnected
$srm.ExtensionData | Get-Member

# Posle read-only inspekcije zatvoriti obe sesije.
Disconnect-SrmServer -Server $srm -Confirm:$false
Disconnect-VIServer -Server $vc -Confirm:$false

Očekuje se IsConnected=True i prikaz dostupnog API objekta bez TLS upozorenja. Get-Member je read-only način da se utvrdi stvarni objektni model; nije dokaz zdravlja plana. Ne kopirati sa interneta poziv recovery metode bez provere zvanične API reference, RBAC-a, režima testa i change odobrenja. U produkciji koristiti secret vault i namenski nalog; interaktivni Get-Credential je prihvatljiv laboratorijski obrazac.

Vežba 5 – Izolovani test, merenje RTO-a i cleanup

Cilj: dokazati oporavak aplikacije bez prekida produkcije. Rizik je srednji: pogrešno mrežno mapiranje može izazvati IP konflikt ili stvarne spoljne akcije.

1. Otvoriti change/test zapis i potvrditi da je testna mreža izolovana, da su e-mail/payment integracije blokirane i da postoji jump host.
2. Zabeležiti UTC početak i trenutno stanje replikacije. Pokrenuti Test Recovery Plan, nikako Run Recovery Plan.
3. Pratiti korake u Recovery Steps i Tasks/Events. Ne preskakati upozorenje bez zapisa razloga.
4. Na testnom DB01 proveriti servis i recovery baze; na APP01 proveriti DNS/hosts rezoluciju unutar bubble-a, HTTPS health i zatim izvršiti dogovorenu reverzibilnu test transakciju.
5. Zabeležiti vreme tehničke spremnosti, vreme poslovnog prihvatanja, izabranu recovery point tačku i procenjeni ostvareni RPO.
6. Izvesti recovery history/report i sačuvati aplikacione dokaze. Pokrenuti Cleanup i potvrditi da su testni VM-ovi i privremeni uređaji uklonjeni, dok produkcija i replike ostaju zdrave.

# Izvršava se sa izolovanog testnog jump hosta; komande samo proveravaju stanje.
date -u
getent hosts app01.dr-test.example
curl --fail --silent --show-error --max-time 10 \
  https://app01.dr-test.example/health

# Primer provere TCP dostupnosti baze; ne potvrđuje transakcionu ispravnost.
nc -vz -w 5 db01.dr-test.example 5432

Uspeh znači: plan je Test Complete, aplikaciona transakcija je prošla, izmereni RTO je unutar cilja, nema kontakta sa produkcionim integracijama, cleanup je završen i replikacija je ponovo OK. Ako test ne uspe, ne proglašavati DR sposobnost na osnovu delimično podignutih VM-ova. Zabeležiti neuspešan korak, neposredni uzrok i korektivnu meru, pa zakazati ponovni test.

Vežba 6 – Kontrolisani kvar i troubleshooting grana

Cilj: u laboratoriji vežbati dokazivanje uzroka RPO violation-a bez destruktivnog failover-a. Bezbedna simulacija je ograničenje bandwidth-a ili kontrolisani prekid tačno dokumentovane replikacione putanje; ne gasiti produkcioni storage ili ceo vCenter.

1. Pre simulacije sačuvati healthy status, datastore prostor, latency, mrežni throughput i vreme poslednje sinhronizacije.
2. U dogovorenom laboratorijskom prozoru primeniti reverzibilno ograničenje na replikacioni test tok. Zabeležiti change ID i UTC vreme.
3. Posmatrati kada se pojavljuje backlog/RPO violation. Prikupiti događaje iz vCenter-a, orkestratora i replication appliance-a za isti interval.
4. Formulisati hipotezu „raspoloživi protok je manji od change rate-a”, potvrditi je mrežnom metrikom i rastom backlog-a, pa ukloniti ograničenje.
5. Potvrditi da backlog opada i da se status vraća na OK bez brisanja/reconfigurisanja replike.

Privremeno rešenje može biti kontrolisano smanjenje konkurentnih inicijalnih sinhronizacija; trajna mera je kapacitivno planiranje/QoS ili promena politike zasnovana na poslovnom zahtevu. Rollback je uklanjanje laboratorijskog mrežnog ograničenja i potvrda prvobitne konfiguracije. Kriterijum završetka je korelisana vremenska linija i oporavljena replika, ne samo nestanak alarma.

Vežba 7 – Tabletop planned migration, disaster failover i failback

Cilj je proveriti odluke bez pokretanja destruktivne operacije. Tim prolazi kroz tri scenarija: najavljena selidba sa dostupnim sajtom A, nagli gubitak sajta A i povratak posle obnove. Za svaki scenario imenovati ko proglašava događaj, ko potvrđuje fencing, koju recovery point tačku bira, kada se preusmerava saobraćaj, ko prihvata podatke, kako se uspostavlja backup na aktivnom sajtu i koji uslovi dopuštaju reprotect/failback.

Završni dokaz je odobren runbook sa RACI odgovornostima, kontaktima van primarnog sistema, kontrolnim kapijama, rollback kriterijumima i procenjenim vremenima. Ako tim ne može nedvosmisleno da odgovori ko sprečava split-brain ili ko proglašava oporavljene podatke autoritativnim, stvarni failover se ne vežba dok se upravljanje ne ispravi.

11. Administratorske prakse

• Projektovati oporavak po poslovnoj usluzi i zavisnostima, ne po proizvoljnoj listi VM-ova.
• Držati backup i replikaciju kao komplementarne, administrativno razdvojene kontrole; testirati i noviju repliku i stariju bezbednu recovery point tačku.
• Meriti ostvareni RPO i end-to-end RTO, uključujući deklaraciju, fencing, mrežno preusmeravanje i poslovno prihvatanje.
• Testirati plan posle značajne promene aplikacije, mreže, storage-a, sertifikata, KMS-a, identiteta ili verzije proizvoda, kao i periodično prema politici.
• Automatizovati read-only inventar i validacije; state-changing recovery operacije zaštititi change kontrolom, RBAC-om, eksplicitnim režimom i audit tragom.
• Čuvati plan i kontakte van istog failure domain-a; recovery procedura ne sme biti dostupna samo u sistemu koji se oporavlja.
• Redovno proveravati kapacitet recovery sajta, licence, kompatibilnost build-ova/SRA-a i istek sertifikata.
• Svaki test završiti cleanup-om, ponovnom proverom zaštite, izveštajem, vlasnikom korektivne mere i datumom ponovnog testa.

12. Završna kontrolna tačka

Administrator je završio lekciju kada može dokazima da:

• razlikuje HA, backup, replikaciju, orkestraciju i poslovni kontinuitet;
• prevede BIA zahtev u recovery tier, RPO, RTO, zavisnosti i kriterijum prihvatanja;
• izabere između vSphere Replication, array-based i aplikacione replikacije bez poistovećivanja replike sa backupom;
• objasni uloge site pair-a, mapiranja, placeholder datastore-a, protection group-a i recovery plan-a;
• projektuje izolovanu testnu mrežu i spreči IP konflikt, neželjene spoljne akcije i split-brain;
• razlikuje Test, Cleanup, Planned Migration, Disaster Recovery, Reprotect i Failback;
• izvede izolovan test, izmeri end-to-end RTO, proceni ostvareni RPO i dobije poslovno prihvatanje;
• koreliše recovery history, vCenter događaje, replication/orkestrator logove, mrežne i storage metrike;
• bezbedno zaustavi tok kada fencing, integritet podataka, KMS, kapacitet ili identitet nisu dokazani;
• dokumentuje odstupanje, korektivnu meru, vlasnika, rok i obavezni ponovni test.

13. Zaključak

Pouzdan disaster recovery nije proizvod koji se jednom instalira, već stalno proveravana sposobnost organizacije. Replikacija obezbeđuje podatke u drugom domenu, orkestrator prevodi zavisnosti u kontrolisan tok, ali tek izolovan test i poslovna validacija pretvaraju konfiguraciju u dokaz oporavljivosti. Najvažnija administratorska odluka često nije „pokreni plan”, već izbor odgovarajuće recovery tačke, potvrda da je izvor ograđen i spremnost da se proces zaustavi kada integritet nije dokazan.

Administrator koji odgovorno upravlja DR-om poznaje granice verzije i licence, prati ostvareni RPO, meri celokupan RTO, čuva nezavisne backup kopije, testira mrežu i identitet jednako ozbiljno kao VM-ove i dokumentuje svaki izuzetak. Tako recovery plan prestaje da bude optimističan dokument i postaje proverljiv operativni sistem za kontinuitet poslovanja. Sledeća lekcija nastavlja od trenutka kada događaj preraste u incident: trijažom, prikupljanjem support bundle-a, koordinacijom sa podrškom i RCA postupkom.