Cześć wszystkim,
Bare Metal Recovery z Veeam Agent for Microsoft Windows wykonywałem już wiele razy: po awarii dysku, przy wymianie sprzętu, podczas migracji i oczywiście w testach odtwarzania. Sam mechanizm nie jest więc nowy. W VBR 13.1 zmieniło się to, kto musi siedzieć przy odtwarzanym serwerze i skąd prowadzimy całą operację.
Od premiery 13.1 korzystałem z Remote Bare Metal Recovery już wielokrotnie, głównie podczas wdrożeń i testów procedur recovery. W rozproszonych środowiskach ma to sporo sensu. Jeżeli serwer stoi w oddziale i ma kontroler zdalnego zarządzania, na przykład iDRAC, iLO lub iBMC, mogę zdalnie podłączyć ISO i poprowadzić odtwarzanie. Bez takiej konsoli wystarczy ktoś na miejscu, kto uruchomi komputer z przygotowanego nośnika.
🖥️ Co dokładnie doszło w VBR 13.1?
Po uruchomieniu Veeam Recovery Environment komputer rejestruje się w VBR jako recovery appliance. Widzę go wtedy w nowej sekcji w Web UI: Protection Groups > Remote Bare Metal Recovery, sprawdzam (sześciocyfrowy) kod połączenia wyświetlany po obu stronach i uruchamiam kreator odtwarzania.
W Web UI wskazuję jedną lub kilka maszyn oczekujących na odtworzenie, wybieram backup i restore point. Układ dysków może pozostać taki jak w kopii albo zostać zmieniony. Kreator pozwala powiększyć lub zmniejszyć woluminy, przenieść je na inne dyski i pominąć niepotrzebne partycje. Z tego samego miejsca uruchamiam restore, obserwuję postęp i po zakończeniu restartuję komputer do odtworzonego systemu.
VBR próbuje dopasować backup do recovery appliance na podstawie nazwy hosta i podpowiada najnowszy restore point. Można oczywiście wskazać inną maszynę z backupu albo starszy punkt. Sam restore zapisuje się w historii jako sesja Recovery Appliance Volumes Restore (co ciekawe - nie znajdziecie tego wpisu w historii ‘grubego’ klient VBR 😐.
Przy zdalnym BMR VBR zawsze wstrzykuje sterowniki do odtwarzanego systemu. Podczas startu przez Virtual Recovery Partition sterowniki wykrytych urządzeń są dodatkowo instalowane automatycznie, co ogranicza ryzyko braku sieci lub dostępu do storage już w recovery environment.
Samą sesję Remote Bare Metal Recovery uruchamia się i prowadzi wyłącznie w VBR Web UI. Dokumentacja wprost zaznacza, że ‘gruba’ konsola VBR nie może jej uruchomić. Przygotowanie Recovery Media ISO ma szerszy zakres tworzenia: nośnik z opcją zdalnego startu można utworzyć zarówno w konsoli VBR, jak i w Web UI.
💿 ISO czy Virtual Recovery Partition?
VBR 13.1 daje dwie drogi przygotowania środowiska odzyskiwania.
Pierwsza to klasyczne Veeam Recovery Media ISO, ale utworzone z opcją Allow remote start from this backup server when this recovery media is booted. ISO można wygenerować z poziomu protection group albo z istniejącego backupu Agenta. Po starcie z nośnika recovery environment korzysta z zapisanych ustawień, łączy się z VBR i pojawia się jako recovery appliance. Jeśli trzeba poprawić sieć albo doładować sterownik, osoba przy komputerze może zrobić to przed ponowieniem połączenia.
Druga droga to Virtual Recovery Partition. Włącza się ją w zaawansowanych ustawieniach Veeam Agent for Microsoft Windows dla protection group, w sekcji Security. Po rescanie Agent tworzy na wolumenie systemowym dedykowany folder z dostosowanym recovery environment oraz ukryty wpis startowy.
Gdy potrzebne jest odtwarzanie, wybieram komputer w Web UI i uruchamiam Bare Metal Recovery. Agent jednorazowo zmienia sposób startu i restartuje Windows bezpośrednio do środowiska odzyskiwania. Po restore mogę z tego samego miejsca wykonać kolejny reboot, tym razem do odzyskanego systemu.
VBR pokazuje stan Virtual Recovery Partition w szczegółach komputera. Odświeża go przy rescanie protection group oraz po backupie. Agent ponawia nieudaną próbę utworzenia do trzech razy dziennie. Środowisko jest też automatycznie tworzone ponownie po aktualizacji Veeam Agenta i po aktualizacji Windows Server do nowszego wydania. W Web UI znajduje się również akcja Recreate Virtual Recovery Partition.
Przed zamknięciem wdrożenia czekam, aż status rzeczywiście zmieni się na Created. Dopiero taki stan potwierdza, że Virtual Recovery Partition została przygotowana.
🏢 Gdzie to się przydaje?
Najbardziej oczywisty przypadek to serwery fizyczne w oddziałach i lokalizacjach bez stałej (lokalnej) obsługi IT. Przy działającym systemie lub przynajmniej sprawnym dysku systemowym Virtual Recovery Partition pozwala rozpocząć proces bez konieczności dojazdu na miejsce. Po utracie dysku uruchamiam ISO przez konsolę zdalnego zarządzania. Jeśli serwer nie ma takiego kontrolera, potrzebny jest przygotowany wcześniej nośnik i pomoc kogoś na miejscu.
Remote BMR przydaje się również przy wymianie dysków, migracji systemu na inny sprzęt i cyklicznych testach recovery. W jednym kreatorze można obsłużyć więcej niż jeden recovery appliance.
Pliki Virtual Recovery Partition znajdują się na wolumenie systemowym. Po fizycznej awarii tego dysku lokalne środowisko odzyskiwania znika razem z Windowsem. Dlatego nadal przechowuję ISO poza chronionym serwerem.
☁️ A co z kopią w Veeam Cloud Connect?
W tym miejscu łatwo pomylić dwie niezależne ścieżki. TCP 6180 służy w Cloud Connect do zestawiania komunikacji z Cloud Gateway i transportu danych w scenariuszach VCC. Nie jest tunelem, przez który Cloud Gateway wystawia kliencki VBR na zewnątrz ani zastępuje połączenia recovery appliance z tym VBR.
Remote BMR wymaga, aby Veeam Recovery Environment zarejestrował się bezpośrednio jako recovery appliance na serwerze VBR, a dokumentacja wyraźnie wyklucza NAT. W praktyce przed takim testem trzeba więc potwierdzić routowanie, DNS i zaporę pomiędzy recovery environment a klienckim VBR. Sam dostęp do Cloud Gateway po TCP 6180 tego nie załatwia.
Sprawdziłem również wariant z pełną łącznością do VBR. Do klienckiego VBR działającego jako VSA dodałem Service Providera, utworzyłem zadanie Veeam Agent kierowane bezpośrednio do Cloud Repository i wykonałem pełny backup. Kopia oraz jej restore point były prawidłowo widoczne w VBR, a recovery appliance zarejestrował się poprawnie.
Po uruchomieniu recovery appliance kreator Remote BMR automatycznie dopasował jednak wyłącznie kopię z lokalnego repozytorium. W oknie Select Backup backup z Cloud Repository nie był dostępny. Powtórzyłem próbę po odświeżeniu danych - wynik się nie zmienił.
To ważne rozróżnienie. Klasyczny Bare Metal Recovery uruchomiony lokalnie z Veeam Recovery Media może korzystać z backupu w Cloud Repository. W takim wariancie połączenie z Service Providerem wskazuje się w samym środowisku odzyskiwania. Nie jest to jednak nowy Remote BMR sterowany z Web UI VBR.
Dokumentacja Cloud Connect wymienia obsługiwane operacje odzyskiwania backupów Agenta z Cloud Repository, ale Remote BMR nie znajduje się na tej liście. Na dziś nie wpisywałbym więc tej metody jako zdalnej procedury odzyskiwania z VCC - nawet gdy połączenie recovery appliance z VBR jest poprawne. Dla kopii off-site pozostaje klasyczny BMR z Recovery Media. Jeśli Remote BMR ma być elementem runbooka, potrzebna jest również kopia widoczna dla jego kreatora w Web UI. mam nadzieję że niebawem to się zmieni i Remote BMR będzie także dostępne z kopii w VCC.
⚠️ Ograniczenia, które trzeba uwzględnić
Remote BMR działa dla komputerów z Veeam Agent for Microsoft Windows zarządzanych przez VBR. Nie obejmuje maszyn z protection groups typu Pre-installed Catch-All ani Cloud Native.
Nie ma obsługi połączeń przez NAT. Recovery environment musi połączyć się bezpośrednio z VBR, dlatego DNS, routing i reguły zapory sprawdzam z uruchomionego środowiska odzyskiwania, a nie ze stacji roboczej administratora.
Przy Virtual Recovery Partition nie jest obsługiwane Wi-Fi ani systemowy wolumen zabezpieczony BitLockerem. Ręczne mapowanie nie obejmuje woluminów dynamicznych. Funkcja wymaga Veeam Data Platform Advanced lub Premium oraz licencjonowania Rental lub VUL. Nie jest dostępna w Community Edition, trybie bez licencji, Foundation, Essentials ani w starszych modelach licencjonowania.
Przed wpisaniem Remote BMR do runbooka ustalam trzy rzeczy:
- jak uruchomimy recovery environment po całkowitej utracie dysku,
- jak połączy się ono z VBR,
- kto potwierdzi kod wyświetlany na odzyskiwanym komputerze.
🧪 Jak wyglądał mój ostatni test?
Do udokumentowanego przebiegu użyłem VBR 13.1.1 działającego jako VSA oraz Veeam Agent for Microsoft Windows 13.1.1. Maszyna miała źródłowy dysk 64 GB, a na potrzeby odtworzenia dołożyłem pusty dysk 80 GB. Źródła nie ruszałem.
Po uruchomieniu Virtual Recovery Partition recovery appliance pojawił się w Web UI. VBR dopasował backup, a ja wybrałem restore point i własne mapowanie. Partycję EFI oraz Windows (C:) przypisałem wyłącznie do nowego dysku.
Przy dwóch widocznych dyskach warto się zawsze zastanowić. Odruchowe zaakceptowanie automatycznego układu może skończyć się odtworzeniem nie tam, gdzie planowaliśmy.
Sesja zakończyła się statusem Success. Odtworzenie 63,6 GB woluminu Windows trwało 54 sekundy, a cały proces 1 minutę i 41 sekund.
Po pierwszym restarcie zobaczyłem ekran logowania. W konfiguracji pozostał jednak stary dysk, a UEFI potrafi uruchomić system z innego nośnika niż sugeruje ustawiona kolejność startu. Wynik wymagał więc dodatkowego sprawdzenia.
Odpiąłem więc źródłowy dysk bez usuwania jego danych i uruchomiłem maszynę ponownie. Windows wystartował, a kontrola z poziomu systemu potwierdziła dysk systemowy 80 GB i zdrowy wolumin C:. Dopiero wtedy uznałem test za zakończony. Później podłączyłem źródło i przywróciłem wcześniejszą konfigurację.
Jedna z wcześniejszych prób zatrzymała się przed transferem, bo recovery environment nie mogło odnaleźć punktu połączenia z VBR. Przyczyna dotyczyła mojego laboratorium. Od tamtej pory FQDN i dostęp do VBR sprawdzam po uruchomieniu właściwego recovery environment. Łączność ze stacji roboczej administratora przebiega inną ścieżką.
✅ Co sprawdzam przed zamknięciem wdrożenia
W runbooku zapisuję oba warianty startu: Virtual Recovery Partition na typową awarię systemu oraz ISO uruchamiane przez konsolę zdalnego zarządzania albo z fizycznego nośnika po utracie dysku. Sprawdzam stan Created, uruchamiam recovery environment i potwierdzam sieć, storage, sterowniki oraz rejestrację w VBR.
Później wykonuję próbne mapowanie na pusty dysk, kontrolowany restore i start bez dostępu do źródłowego nośnika. Po zalogowaniu sprawdzam jeszcze usługi oraz działanie aplikacji.
💬 Jak Wy podchodzicie do Remote BMR?
Korzystacie już z Virtual Recovery Partition, czy procedury nadal opieracie głównie na ISO uruchamianym przez konsolę zdalnego zarządzania?
Interesuje mnie też, czy ktoś testował kilka recovery appliances w jednej sesji oraz jak zachowuje się ten mechanizm na fizycznych serwerach z bardziej nietypowymi kontrolerami storage i kartami sieciowymi (ja w swoim labie mam raczej standardową infrastrukturę).
No i jeszcze jedno - w sumie nie tylko dotyczące tego odtwarzania: mierzycie samo odtworzenie, czy czas od zgłoszenia awarii do uruchomienia działającej aplikacji?
🔗 Źródła
- What's New - Agent-Based Protection
- Restoring from Veeam Recovery Media Remotely
- Creating Veeam Recovery Media Using Web UI
- Launching Bare Metal Recovery Wizard
- Specifying Volume Allocation
- Specifying Backup File Location - Veeam Agent for Microsoft Windows
- Before You Begin - Bare Metal Recovery
- Backup to Veeam Cloud Connect Repository
- Backing Up to Cloud Repositories - Veeam Agent for Microsoft Windows
- VBR 13.1 Release Notes
