Microsoft AZ-801: Odzyskiwanie po awarii i ciągłość działania — Przewodnik do nauki

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Część Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Kopia zapasowa i przywracanie: Azure Backup (MARS, MABS/DPM), magazyny i Windows Server Backup

Azure Backup zapewnia ochronę w punkcie w czasie dla obciążeń lokalnych (on-premises) i w Azure. Wybierz odpowiedniego agenta i typ magazynu w zależności od obciążenia i wymaganych funkcji.

Agent MARS (Microsoft Azure Recovery Services agent)

Zasady tworzenia kopii zapasowych: Skonfiguruj do trzech kopii zapasowych dziennie z granularnym przechowywaniem (dziennym/tygodniowym/miesięcznym/rocznym) w magazynie Recovery Services. Wybierz redundancję magazynu (LRS lub GRS) i dostosuj okres przechowywania do wymogów zgodności, kontrolując jednocześnie wzrost wielkości magazynu. Zaplanuj tworzenie kopii zapasowych poza godzinami szczytowego obciążenia I/O i w razie potrzeby włącz ograniczanie przepustowości sieci.
Kopia zapasowa stanu systemu (System State): Obsługiwana przez agenta MARS dla Windows Server w celu ochrony AD, rejestru, COM+ i plików rozruchowych. Używaj do odzyskiwania kontrolera domeny (autorytatywnego/nieautorytatywnego) lub naprawy systemu operacyjnego bez konieczności tworzenia pełnej kopii zapasowej na poziomie obrazu.
Odzyskiwanie online: Przywracaj pliki/foldery za pomocą funkcji Przeglądaj (Browse) lub Szukaj (Search). Funkcja Instant Restore montuje punkt odzyskiwania jako wolumin w celu szybkiego kopiowania plików. Możesz przywrócić dane do oryginalnej lub alternatywnej ścieżki, a nawet na inny serwer, używając poświadczeń magazynu na serwerze docelowym i uwierzytelniając się w magazynie.
Zarządzanie hasłem szyfrującym: Agent MARS używa hasła szyfrującego (AES-256) przechowywanego przez klienta, które jest generowane i zapisywane lokalnie; Microsoft nigdy nie ma do niego dostępu. Utrata hasła uniemożliwia odzyskanie danych. Przechowuj je w bezpiecznej lokalizacji z kopią zapasową (np. jako zapieczętowany sekret w Key Vault wspieranym przez HSM z kontrolą RBAC). Aby zmienić hasło, zatrzymaj ochronę i ponownie ją skonfiguruj z nowym hasłem. Włącz w magazynie funkcje usuwania nietrwałego (soft delete) i kodu PIN zabezpieczeń, aby chronić przed złośliwym zatrzymaniem/usunięciem ochrony.

Azure Backup z MABS/DPM i IaaS

Kopia zapasowa Bare Metal Recovery (BMR): Użyj Microsoft Azure Backup Server (MABS) lub System Center DPM do przechwytywania BMR dla Windows Server. Umożliwia to pełną odbudowę serwera na nowym sprzęcie lub maszynie wirtualnej poprzez uruchomienie WinRE lub nośnika instalacyjnego i wskazanie obrazu BMR.
Odzyskiwanie do alternatywnej lokalizacji: W przypadku kopii zapasowych plików/danych za pośrednictwem MARS/MABS/DPM, przywracaj do alternatywnej ścieżki lub na inny serwer, aby uniknąć nadpisania danych źródłowych. W przypadku kopii zapasowych maszyn wirtualnych IaaS w Azure (w magazynie Recovery Services), przywracaj do nowej maszyny wirtualnej, przywracaj dyski do istniejącej maszyny wirtualnej lub zastępuj dyski. Z włączoną funkcją Cross-Region Restore w magazynie, możesz przywracać dane w sparowanym regionie w scenariuszach awarii regionalnej.
SQL i SAP HANA w maszynach wirtualnych Azure: Chroń za pomocą rozszerzeń świadomych obciążenia (workload-aware), aby uzyskać kopie zapasowe spójne z aplikacją i granularne przywracanie baz danych. Dostosuj częstotliwość tworzenia kopii zapasowych logów do RPO (np. co 15 minut) i okres przechowywania do wymogów zgodności.

Windows Server Backup (WSB)

Odzyskiwanie bare-metal: WSB może przechwytywać BMR (woluminy systemowe i stan systemu). Przechowuj kopie na dedykowanym dysku lub woluminie, aby mieć wiele punktów odzyskiwania. W przypadku docelowych udziałów sieciowych przechowywana jest tylko najnowsza wersja. Odzyskuj, uruchamiając system z nośnika Windows w trybie WinRE i wybierając opcję „System Image Recovery”.
Kopia zapasowa stanu systemu (System State): Zapewnia szybkie odzyskiwanie AD DS, rejestru i plików rozruchowych. Przydatne dla kontrolerów domeny i serwerów konfiguracyjnych. Połącz z zaplanowanymi kopiami zapasowymi plików, aby uzyskać szerszy zakres ochrony.
Harmonogram: Użyj konsoli MMC WSB lub polecenia wbadmin, aby zaplanować codzienne/godzinowe kopie zapasowe. Wybierz VSS Full lub VSS Copy w zależności od tego, czy chcesz obcinać logi aplikacji. Upewnij się, że okna tworzenia kopii zapasowych nie pokrywają się z godzinami szczytowego obciążenia I/O i weryfikuj integralność katalogu (wbadmin get versions).

Typy magazynów: Recovery Services vault vs Backup vault

Recovery Services vault (RSV): Tradycyjny magazyn dla kopii zapasowych maszyn wirtualnych Azure, kopii zapasowych agenta MARS, MABS/DPM, kopii zapasowych Azure Files, SQL Server w maszynie wirtualnej Azure i SAP HANA w maszynie wirtualnej Azure. Przechowuje również metadane ASR. Obsługuje funkcje takie jak usuwanie nietrwałe (soft delete), kod PIN zabezpieczeń i Cross-Region Restore (jeśli ma zastosowanie).
Backup vault: Zmodernizowany magazyn dla określonych natywnych obciążeń Azure, takich jak kopie zapasowe Azure Disks i Azure Blobs oraz serwery elastyczne Azure Database for PostgreSQL. Używa Azure RBAC do autoryzacji na płaszczyźnie zarządzania, obsługuje klucze zarządzane przez klienta (customer-managed keys), opcje niezmienności (immutability) i integruje się z Resource Guard w celu ochrony krytycznych operacji. Nie przechowuje metadanych ASR i na dzień dzisiejszy nie zastępuje RSV dla kopii zapasowych MARS/MABS/DPM ani większości kopii zapasowych maszyn wirtualnych IaaS.

HA na poziomie aplikacji: SQL Always On i replikacja DFS

Niektóre obciążenia wymagają natywnej replikacji, która uzupełnia lub zastępuje DR na poziomie hiperwizora, w zależności od RTO/RPO.

Grupy dostępności Always On (AG)

Zatwierdzanie synchroniczne a asynchroniczne: Zatwierdzanie synchroniczne czeka na utrwalenie logu przez replikę wtórną przed zatwierdzeniem transakcji na replice podstawowej, zapewniając niemal zerową utratę danych (niskie RPO) kosztem opóźnień i przepustowości; stosuje się je w ramach połączeń o niskim opóźnieniu (zazwyczaj w obrębie jednego miasta). Zatwierdzanie asynchroniczne nie czeka na replikę wtórną, co pozwala na wyższą wydajność w połączeniach WAN z potencjalną utratą danych podczas przełączania awaryjnego (wyższe RPO).
Warunki automatycznego przełączania awaryjnego: Automatyczne przełączanie awaryjne wymaga co najmniej dwóch replik z zatwierdzaniem synchronicznym, włączonym automatycznym przełączaniem awaryjnym i zsynchronizowanych. Windows Server Failover Clustering monitoruje stan węzłów/usług; elastyczna polityka przełączania awaryjnego SQL Server definiuje poziomy warunków awarii (od awarii procesów po poważne problemy z I/O). Można włączyć wykrywanie stanu bazy danych, aby wymusić przełączenie awaryjne, gdy stan podstawowej bazy danych jest podejrzany. Projekt kworum i świadka (witness) zapobiega sytuacji typu split-brain; upewnij się, że DNS i adresy IP listenera są gotowe w lokalizacji odzyskiwania, aby zapewnić szybkie ponowne połączenie klienta.

Replikacja DFS (DFSR)

Grupy replikacji i połączenia: Grupa replikacji to zbiór serwerów replikujących jeden lub więcej folderów replikowanych. Połączenia definiują topologię (pełna siatka, gwiazda/hub-spoke) oraz harmonogram/ograniczanie przepustowości. Używaj topologii hub-spoke dla skalowalności i łatwiejszego rozwiązywania problemów.
Obszar przejściowy (staging area): DFSR używa obszaru przejściowego dla każdego replikowanego folderu do przechowywania plików delta dla Remote Differential Compression (RDC). Rozmiar obszaru przejściowego powinien być co najmniej równy rozmiarowi największego pliku i zazwyczaj 1–2 razy większy od oczekiwanej dziennej zmiany danych (churn); zbyt mały rozmiar powoduje nadmierne czyszczenie i ponawianie prób, co negatywnie wpływa na RPO/RTO.
Rozwiązywanie konfliktów: DFSR działa w trybie multi-master. Gdy wystąpią jednoczesne edycje, DFSR wykorzystuje wektory wersji i znaczniki czasu; wygrywa ostatni zapis (last-writer wins), a przegrywająca kopia jest przenoszona do folderu ConflictAndDeleted (którego przestrzeń jest zarządzana przez przydział/quota). Aby uniknąć początkowych konfliktów podczas wstępnego wypełniania danych (seeding), ustaw jednego członka jako podstawowego tylko na czas pierwszej synchronizacji. W scenariuszach jednokierunkowych używaj folderów replikowanych tylko do odczytu. Monitoruj zaległości za pomocą dfsrdiag i dostosuj harmonogramy, aby spełnić RPO.

Wpływ RTO/RPO i zintegrowanych planów DR na architekturę

Agresywne RPO: Preferuj synchroniczną replikację baz danych lub ASR z przetwarzaniem zmian o wysokiej częstotliwości i migawkami spójnymi z aplikacją. Izoluj ruch replikacyjny i skaluj serwery przetwarzania. Używaj grup spójności obejmujących wiele maszyn wirtualnych oszczędnie, tylko dla ściśle powiązanych warstw.
Agresywne RTO: Przygotuj z wyprzedzeniem docelowe sieci VNet, podsieci, tabele routingu i grupy NSG; stwórz skrypty do ponownego przypisywania adresów IP i aktualizacji DNS za pomocą planów odzyskiwania i elementów runbook. Utrzymuj złote obrazy i rozmiary maszyn wirtualnych przypięte do jednostek SKU z dostępną pojemnością. Testuj przełączanie awaryjne co kwartał i po istotnych zmianach.
Warstwowa ochrona danych: Połącz ASR (szybkie odzyskiwanie usług) z Azure Backup (przywracanie do punktu w czasie), aby zaradzić zarówno awariom katastrofalnym, jak i uszkodzeniom logicznym. W przypadku kontrolerów domeny połącz kopie zapasowe stanu systemu (MARS lub WSB) z ASR/testami przełączania awaryjnego, aby zweryfikować odzyskiwanie bezpieczne pod kątem wycofywania numerów USN. W przypadku usług plików, DFSR zapewnia wysoką dostępność wewnątrz- i międzylokacyjną, a Azure Backup umożliwia odzyskiwanie odporne na oprogramowanie ransomware.

Praktyczny scenariusz problemowy

Fabrikam, Inc., globalny producent, działa w środowisku mieszanym: Hyper-V dla warstw aplikacji ERP, VMware dla starszego oprogramowania pośredniczącego (legacy middleware), SQL Server 2019 AGs dla baz danych oraz duże serwery plików Windows wykorzystujące DFS Replication. Wymagania biznesowe to RTO ≤ 1 godzina i RPO ≤ 15 minut dla ERP; inne obciążenia mogą tolerować RTO 4 godziny i RPO 24 godziny.

Klasyfikacja obciążeń i celów RTO/RPO

Maszyny wirtualne aplikacji/warstwy webowej ERP oraz grupy dostępności SQL oznaczone jako Tier 1 (RTO 1h, RPO 15m). Oprogramowanie pośredniczące i usługi plików to Tier 2/3.
Dlaczego: Zapewnia to, że najbardziej rygorystyczne cele determinują wybory dotyczące replikacji i orkiestracji.

Implementacja ASR dla warstw ERP na Hyper-V

Zainstaluj dostawcę ASR Provider na hostach Hyper-V i zarejestruj go w magazynie Recovery Services. Utwórz politykę replikacji z progiem RPO 15 minut, migawkami spójnymi z aplikacją co godzinę i 48-godzinną retencją. Włącz grupę spójności obejmującą wiele maszyn wirtualnych dla serwerów aplikacji ERP, które współdzielą transakcje z odbiornikiem SQL.
Dlaczego: Replikacja ciągła i spójne z aplikacją punkty kontrolne pozwalają osiągnąć 15-minutowe RPO, jednocześnie utrzymując spójność warstwy.

Implementacja ASR dla oprogramowania pośredniczącego na VMware

Wdróż lokalnie serwer konfiguracji ze współlokowanym serwerem przetwarzania, zwymiarowanym pod przewidywaną zmienność danych (churn). Dodaj serwer przetwarzania w architekturze scale-out w największej lokalizacji. Zainstaluj Mobility Service na chronionych maszynach wirtualnych. Przygotuj główny serwer docelowy (master target server) na ewentualny powrót po awarii (failback).
Dlaczego: Architektura ASR dla VMware zapewnia niezawodne przechwytywanie zmian i kontrolowaną ścieżkę powrotu po awarii, gdy lokalizacja on-premises zostanie odzyskana.

Orkiestracja za pomocą planów odzyskiwania i elementów runbook

Zbuduj plan odzyskiwania grupujący kolejno: SQL (dane), następnie aplikacje ERP, a na końcu warstwy webowe. Wstaw elementy runbook usługi Azure Automation w celu: rekonfiguracji grup NSG, aktualizacji prywatnych stref DNS, aby wskazywały na adresy IP w Azure, oraz przełączania punktów końcowych usługi Traffic Manager. Dodaj ręczny krok walidacji przed udostępnieniem warstwy webowej online.
Dlaczego: Automatyzacja skraca RTO i redukuje ryzyko błędu ludzkiego podczas kryzysu, wymuszając prawidłową kolejność uruchamiania i stan sieci.

Ochrona SQL Server za pomocą grup dostępności (AGs) dostosowanych do lokalizacji

Utrzymuj serwer podstawowy i jeden pomocniczy w trybie zatwierdzania synchronicznego (synchronous commit) w regionie metropolitalnym dla niemal zerowego RPO; utrzymuj zdalny serwer pomocniczy DR w trybie zatwierdzania asynchronicznego (asynchronous commit). Skonfiguruj automatyczne przełączanie awaryjne między replikami synchronicznymi z włączonym wykrywaniem kondycji bazy danych. Zintegruj kroki przełączania awaryjnego AG z planem odzyskiwania ASR w celu zapewnienia wzajemnej widoczności.
Dlaczego: Synchroniczne grupy dostępności zapewniają najniższe RPO dla warstwy bazy danych; ASR zapewnia orkiestrację całej lokalizacji wokół niej.

Warstwowe tworzenie kopii zapasowych za pomocą Azure Backup

Dla lokalnych serwerów Windows wymagających ochrony plików i stanu systemu, wdróż agenta MARS i skonfiguruj polityki z codziennymi kopiami zapasowymi i retencją 30/52/7 (dzienną/tygodniową/roczną). Przechowuj i chroń hasło szyfrujące w Azure Key Vault (zabezpieczonym modułem HSM). Użyj MABS do przechwytywania obrazów BMR dla krytycznych serwerów aplikacji, aby umożliwić pełną odbudowę w razie potrzeby. Włącz usuwanie nietrwałe (soft delete) i kod PIN zabezpieczeń w magazynie.
Dlaczego: Odzyskiwanie do punktu w czasie chroni przed uszkodzeniami logicznymi i oprogramowaniem ransomware, uzupełniając szybkie przełączanie awaryjne ASR.

Wzmocnienie zabezpieczeń DFSR i tworzenie kopii zapasowych usług plików

Przejrzyj topologię grupy replikacji (hub-spoke), upewnij się, że obszary przejściowe (staging areas) są zwymiarowane na 1,5x dziennej zmienności danych (churn) i dostosuj harmonogramy, aby utrzymać replikację wewnątrz regionu niemal w czasie rzeczywistym. Chroń udziały za pomocą MARS/MABS w celu długoterminowej retencji i testów odzyskiwania w lokalizacji alternatywnej.
Dlaczego: Prawidłowe dostrojenie DFSR zapewnia codzienną dostępność, podczas gdy kopie zapasowe zapewniają bezpieczeństwo przywracania do wcześniejszego stanu.

Walidacja za pomocą testów trybu failover i udokumentowanych elementów runbook

Wykonuj kwartalne testy przełączania awaryjnego ASR do izolowanej sieci VNet, weryfikuj funkcjonalność ERP na zamaskowanych danych i mierz RTO. Przeprowadzaj ćwiczenia z przywracania: przywracanie z MARS do lokalizacji alternatywnej oraz pełne odzyskiwanie BMR z MABS do środowiska testowego (sandbox).
Dlaczego: Regularne ćwiczenia potwierdzają skuteczność planu, wykrywają dryf konfiguracji i dostarczają kierownictwu dowodów na zgodność z RTO/RPO.

Ten projekt spełnia cele firmy Fabrikam: ASR zapewnia RTO poniżej godziny, grupy dostępności SQL w trybie synchronicznym minimalizują RPO dla baz danych, a Azure Backup z MARS/MABS zapewnia bezpieczne odzyskiwanie do punktu w czasie i możliwość odbudowy całej maszyny. Plany odzyskiwania i elementy runbook eliminują niejednoznaczność podczas incydentów, a DFSR pozostaje zoptymalizowany pod kątem ciągłości operacyjnej między tworzeniem kopii zapasowych.

← Hyper-V · Wszystkie domeny · Zarządzanie tożsamością i dostępem dla środowisk hybrydowych →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →