Veeam Updater w VBR 13.1 - jak automatyzujesz bezpieczne okno serwisowe?

Cześć wszystkim 👋,

Od dnia premiery używam VBR 13.1 w środowiskach produkcyjnych, w tym w kilku instalacjach VBR działających na Windows oraz środowiskach Veeam Cloud Connect.

Począwszy od VBR 13.1, wbudowany Veeam Updater jest dostępny również dla serwerów backupu działających na Windows. To właśnie jest nowością: VBR na Windows może teraz automatycznie pobierać i instalować obsługiwane aktualizacje produktów Veeam.

W kilku środowiskach o przewidywalnych harmonogramach włączyłem już automatyczną instalację aktualizacji. Dotychczas mechanizm działał dokładnie tak, jak oczekiwałem: aktualizacje są instalowane w ciągu tygodnia od publikacji, a ja nie muszę wracać do każdego serwera backupu tylko po to, aby ręcznie zainstalować poprawkę.

To realne usprawnienie. ✅

Po skonfigurowaniu tej funkcji w kilku środowiskach nie uważam jednak, aby sama instalacja aktualizacji była najtrudniejszą częścią procesu. Trudniejsze jest udowodnienie, że wybrany moment rzeczywiście jest bezpieczny.

⏱️ Okno serwisowe nadal opiera się na zegarze

Obecne okno serwisowe pozwala określić, kiedy Veeam Updater ma rozpocząć pracę. Dokumentacja zawiera jednak ważne ostrzeżenie: zaplanowana instalacja lub osiągnięcie terminu zgodności może uruchomić aktualizację nawet wtedy, gdy zadania nadal działają. Objęte nią operacje backupu lub odzyskiwania mogą wówczas zakończyć się niepowodzeniem.

Oznacza to, że obecne okno jest oparte na harmonogramie, a nie na stanie środowiska.

Niedziela o 14:00 może być spokojnym okresem w jednym środowisku. W innym właśnie wtedy działają SureBackup, health check, kontrole CRC, merge, skanowanie złośliwego oprogramowania, zadania taśmowe lub długotrwałe zadania Backup Copy.

Aktywne odtwarzanie, sesja Instant Recovery, failover lub operacja odzyskiwania po stronie providera są jeszcze bardziej oczywistymi powodami do wstrzymania aktualizacji.

Nie chciałbym, aby Updater zatrzymywał takie operacje albo automatycznie przepisywał ich harmonogramy. Wolałbym, aby odłożył własną pracę i poszukał kolejnego wystarczająco długiego okna.

Warto też rozdzielić dwa mechanizmy: na serwerze backupu działającym na Windows Veeam Updater aktualizuje produkt Veeam. Nie instaluje poprawek systemu operacyjnego Windows. Dystrybucja komponentów zdalnych oraz aktualizacje systemu operacyjnego appliance również mają własne etapy i zależności.

⚙️ Proces, który chciałbym zautomatyzować

Na wysokim poziomie widzę go następująco:

Wykryto aktualizację
→ Sprawdź gotowość
→ Poczekaj na zakończenie chronionych operacji i odtwarzania
→ Sprawdź najbliższe zaplanowane zadania
→ Zarezerwuj czas na aktualizację, restart i walidację
→ Zaktualizuj środowisko pilotowe
→ Wykonaj kontrole po aktualizacji
→ Zezwól na kolejną falę albo ją zablokuj

Przed rozpoczęciem kontrola gotowości mogłaby potwierdzić, że:

istnieje świeży, zakończony powodzeniem i zaszyfrowany backup konfiguracji;
backup konfiguracji jest dostępny poza aktualizowanym serwerem;
nie działa żadna sesja backupu, Backup Copy, replikacji, odtwarzania, Instant Recovery, SureBackup ani zadanie taśmowe;
nie trwa konserwacja repozytorium ani operacja infrastrukturalna;
krytyczne proxy, repozytoria i pozostałe komponenty są dostępne;
na aktualizację jest wystarczająco dużo wolnego miejsca;
pozostało dość czasu przed rozpoczęciem następnego zaplanowanego zadania;
dostępne okno zawiera margines bezpieczeństwa na ewentualny restart i walidację po aktualizacji.

Snapshot hypervisora, jeżeli jest właściwy dla danej architektury, traktuję wyłącznie jako krótkotrwały dodatkowy punkt kontrolny. Nie zastępuje on backupu konfiguracji VBR i nie powinien być jedynym planem odzyskiwania.

Jeżeli preferowane okno przestaje być dostępne, aktualizacja powinna przejść do następnego odpowiedniego okresu. Jeżeli przed terminem zgodności nie da się znaleźć bezpiecznego okna, administrator powinien dostać ostrzeżenie z wyprzedzeniem i świadomie podjąć decyzję.

Poszczególne kontrole można już oskryptować, odpytując stan VBR. Nie znalazłem jednak jednego spójnego i wspieranego interfejsu, który koordynowałby cały proces dla serwera VBR działającego na Windows.

Dlatego interesuje mnie, jak dużą część tego procesu inni administratorzy automatyzują już za pomocą wspieranych interfejsów PowerShell lub REST.

🌊 Jeden serwer jest prosty. Grupa serwerów VBR to inna skala

Dla pojedynczej instalacji stałe okno z rozsądnym zapasem może wystarczyć.

Przy wielu zarządzanych środowiskach VBR, a szczególnie w Cloud Connect, nie wdrażałbym tej samej aktualizacji wszędzie jednocześnie. Podzieliłbym środowiska na grupy według architektury, krytyczności i zainstalowanych ról.

Przykładowa kolejność mogłaby wyglądać następująco:

Laboratorium lub reprezentatywne środowisko pilotowe
Mała grupa produkcyjna
Standardowe środowiska produkcyjne
VCC i inne środowiska wymagające dodatkowej walidacji
Wyjątki wymagające ręcznego zatwierdzenia

Następna grupa powinna rozpocząć aktualizację dopiero po przejściu walidacji przypisanej do poprzedniej grupy.

Nieudana aktualizacja, niedostępne repozytorium, nieaktualny komponent infrastruktury albo nieudany smoke test powinny zatrzymać rollout, zanim ten sam problem dotrze do pozostałych środowisk.

Nie oczekuję, że automatyczny rollback będzie domyślną reakcją. Cofnięcie schematu bazy konfiguracji, komponentów zdalnych lub zmian systemu operacyjnego appliance może być bardziej ryzykowne niż zatrzymanie procesu. Bezpieczniejszą reakcją domyślną byłoby zablokowanie pozostałych fal, zachowanie dokładnego stanu, zebranie diagnostyki i przekazanie decyzji administratorowi.

Warto również oddzielić aktualizację serwera VBR od dystrybucji komponentów zdalnych. Automatic Component Upgrade Distribution pomaga w aktualizowaniu serwerów zarządzanych, proxy i repozytoriów, ale końcowa walidacja nadal musi potwierdzić, że każdy wymagany komponent wrócił online i żaden nie pozostał w stanie Out of Date.

Podczas moich aktualizacji VCC do wersji 13.1 główne serwery VBR zostały zaktualizowane bez problemów. Dodatkowej uwagi wymagało kilka appliance VIA używanych jako WAN Acceleratory lub Cloud Gateways. W jednym przypadku musiałem ręcznie ponownie uruchomić aktualizację VIA z poziomu Host Management.

Dlatego serwer providera, appliance, komponenty zdalne i zarządzane środowiska odbiorców usług utrzymywałbym jako oddzielne etapy.

🧪 Co powinno oznaczać pomyślne przejście walidacji?

Nie uważam, aby każde środowisko wymagało identycznego testu po aktualizacji.

Podstawowe kontrole mogłyby obejmować:

usługi Veeam oraz łączność z bazą konfiguracji;
dostęp przez konsolę lub Web UI;
dostępność repozytoriów i proxy;
Cloud Gateways oraz WAN Acceleratory w VCC;
wersje i stan komponentów zdalnych;
nowe krytyczne ostrzeżenia lub błędy infrastruktury.

Test operacyjny powinien zależeć od środowiska. Może to być wybrane zadanie backupu, Backup Copy, odtwarzanie plików, zadanie SureBackup, test Instant Recovery albo inne znane obciążenie.

Nie wymagałbym pełnego odtwarzania VM po każdej poprawce w każdym środowisku, ale taki test powinien być dostępny jako bramka walidacyjna dla wybranych systemów krytycznych.

📊 Czy mogą pomóc dane historyczne?

Samo sprawdzenie listy aktywnych sesji nie wystarcza. Przed rozpoczęciem procesu system powinien również wiedzieć, kiedy ma wystartować następne zaplanowane zadanie oraz czy pozostały czas wystarczy na aktualizację, ewentualny restart, aktualizację komponentów zdalnych i walidację.

Historyczne czasy trwania mogłyby pomóc oszacować zarówno zakończenie aktywnych zadań, jak i czas potrzebny na aktualizację. Estymacja mogłaby uwzględniać poprzednie aktualizacje w tym samym środowisku, rozmiar bazy konfiguracji, wydajność serwera, liczbę i typ zarządzanych komponentów oraz wcześniejsze czasy restartów.

Nie musi to być niekontrolowana decyzja AI. Przydatna byłaby już rekomendacja z poziomem pewności i marginesem bezpieczeństwa:

Szacowany czas aktualizacji: 50 minut
Rekomendowane okno: 90 minut
Następne kolidujące zadanie: 17:00
Poziom pewności: wysoki

🧭 Gdzie powinna działać centralna koordynacja?

Możliwości jest kilka i nie jestem przekonany, że jeden produkt powinien robić wszystko:

VBR mógłby wykonywać lokalne kontrole gotowości i samą aktualizację;
Veeam ONE ma już historyczne dane o zadaniach i infrastrukturze, które mogłyby pomóc znaleźć prawdopodobnie wolne okresy oraz oszacować potrzebny czas;
Enterprise Manager mógłby koordynować grupy aktualizacji i zatwierdzenia dla wielu serwerów VBR w jednej organizacji;
VSPC byłby naturalnym miejscem dla usługodawców zarządzających politykami, wyjątkami i falami wdrożeniowymi w oddzielnych środowiskach odbiorców usług.

Obecna dokumentacja PowerShell dla Veeam Updater pokazuje też ciekawą granicę: udokumentowane polecenia Updatera koncentrują się na serwerach backupu działających na Linux oraz Veeam Infrastructure Appliances. To kolejny powód, dla którego chciałbym wiedzieć, jak inni koordynują pełny proces dla VBR działającego na Windows bez używania niewspieranych skrótów.

💬 Jak radzicie sobie z tym obecnie?

Publikuję ten tekst w Automation Desk, ponieważ chcę rozdzielić dwie kwestie:

co już dziś można bezpiecznie zbudować za pomocą wspieranych interfejsów;
co nadal wymaga dodatkowych możliwości produktu.

Szczególnie interesują mnie Wasze doświadczenia:

Czy opakowujecie już Veeam Updater we własny proces PowerShell lub REST?
Które sesje traktujecie jako bezwzględne blokery?
Czy sprawdzacie tylko aktywne sesje, czy także nadchodzące harmonogramy i historyczne czasy trwania?
Co musi przejść walidację przed zwolnieniem następnej fali aktualizacji?
Gdzie umieszczacie centralną koordynację: w Veeam ONE, Enterprise Manager, VSPC czy na platformie zewnętrznej?
Czy znaleźliście wspierany interfejs obejmujący cały proces dla VBR działającego na Windows?

Veeam Updater rozwiązuje już ważny problem: aktualizacje nie muszą czekać, aż ktoś ręcznie wróci do każdego serwera.

Następne wyzwanie polega na tym, aby automatyzacja rozumiała nie tylko skonfigurowaną godzinę, ale także to, co w danym momencie robi środowisko backupu.

Chętnie porównam różne podejścia i przekształcę wartościowe wnioski z tej dyskusji w bardziej precyzyjny wniosek o nową funkcję.