VBR 13.1 - Automatyczne aktualizacje VBR na Windows: wygoda, sztywne okno i granice automatyzacji

Cześć wszystkim,

Temat wypłynął już w komentarzach pod poprzednim wpisem. @Mariusz słusznie dopisał, że w 13.1 Veeam Updater pojawił się również dla VBR działającego na Windows. To jedna z tych zmian, które na slajdzie wyglądają niepozornie, ale przy utrzymaniu wielu serwerów mogą realnie ograniczyć zaległości w aktualizacjach.

Najpierw ważne doprecyzowanie: Updater aktualizuje produkty i komponenty Veeam. Nie instaluje aktualizacji systemu Windows.

Mam już kilka wdrożeń, w których cały proces działa automatycznie w jednym ściśle wyznaczonym oknie. Do tej pory aktualizacje przechodziły bez problemów, a środowiska dostają najnowsze poprawki maksymalnie w ciągu tygodnia od ich udostępnienia. To jest dla mnie największa wartość tej funkcji.

Nie wszędzie można jednak po prostu pozostawić ustawienia domyślne. Sztywne okno serwisowe, a szczególnie domyślna niedziela widoczna w konfiguracji, nie pasują do specyfiki części środowisk. Updater nie przesuwa instalacji inteligentnie na podstawie rzeczywistego zakończenia zadań, Backup Copy, taśm czy innych procesów. Dlatego automatyzacja nadal wymaga właściciela, który zna harmonogram konkretnego środowiska.

Co naprawdę automatyzuje Updater 🔬

Updater dla VBR na Windows wykrywa aktualizację produktu, pobiera pakiet i instaluje go w zaplanowanym terminie albo po osiągnięciu terminu wymuszonej instalacji. Korzysta z mechanizmu cichej aktualizacji i tych samych kontroli wstępnych, które obowiązują przy ręcznym uruchomieniu nośnika aktualizacyjnego. Aktualizacja może wymagać restartu serwera.

Aktualizacja komponentów zdalnych to osobny etap. Automatic Component Upgrade Distribution może rozprowadzić nową wersję między innymi na serwery zarządzane, proxy i repozytoria. Agenty oraz appliance mają własne wymagania i ścieżki aktualizacji.

Żaden z tych mechanizmów nie aktualizuje Windows, nie ustala za administratora kolejności środowisk VCC i Klienów ani nie potwierdza, że pierwszy backup, Backup Copy i test odtwarzania po aktualizacji zakończyły się prawidłowo.

Zasady opisane w KB4840 📖

Od VBR 13.1 na Windows:

• aktualizacje bezpieczeństwa są domyślnie wybierane do automatycznej instalacji;
• opcjonalne aktualizacje, w tym mniejsze wydania produktu, można dodatkowo włączyć;
• instalację można zaplanować albo wykonać ręcznie przed terminem;
• domyślny termin wymuszonej instalacji wynosi 30 dni od wykrycia aktualizacji;
• termin można odroczyć, ale maksymalnie do 90 dni;
• usługi Updatera nie można wyłączyć (można ją co prawda odinstalować, ale jest wysoce niezalecane, w związku z tym komponentu widocznego na liście zainstalowanych programów nie należy odinstalowywać);
• pakiety są pobierane do %ProgramData%\Veeam\Updater\ na serwerze backupu;
• aktualizacja może wymagać restartu serwera VBR.

Najważniejszy szczegół: po osiągnięciu terminu wymuszona instalacja może rozpocząć się mimo działających zadań. To administrator ma wcześniej wyznaczyć kontrolowane okno i doprowadzić środowisko do stanu gotowego do aktualizacji.

To właśnie tutaj widzę największe ograniczenie obecnej wersji. Maintenance window jest harmonogramem, a nie regułą zależną od stanu środowiska. Nie da się zapisać warunku w rodzaju: „zainstaluj aktualizację po zakończeniu wszystkich zadań, ale przed rozpoczęciem kolejnego cyklu”. Przy prostym harmonogramie to nie przeszkadza. Przy długich Backup Copy, zadaniach taśmowych, kilku repozytoriach i różnych oknach ochrony trzeba wybrać termin ręcznie i zostawić odpowiedni zapas.

Co pokazały moje dotychczasowe wdrożenia 🎁

W środowiskach z przewidywalnym harmonogramem automatyzacja sprawdza się bardzo dobrze. Jeżeli zadania kończą się w podobnym czasie, a okno aktualizacyjne jest oddzielone od kolejnego cyklu odpowiednim marginesem, Updater usuwa sporą część ręcznej pracy. Tak jak pisałem, część środowisk które nadzoruję, po odpowiedniej konfiguracji, już od jakiegoś czasu nie wymagają ode mnie żadnej pracy związanej z aktualizacjami - pozwala to przekierować moje moce i zasoby na optymalizację zadań i reagowanie na incydenty.

Nie miałem dotąd problemów żadnych problemów z tym rozwiązaniem w tych instalacjach, w których updaty od początku do końca wykonywane są automatycznie (początkowo na VSA).

Efekt jest prosty: nie trzeba wracać do każdego serwera osobno, a poprawki nie pozostają niewdrożone przez kilka miesięcy (tak, do tej pory zdażają mi się Klienci u których podnosimy się z wersji 12, a nawet starszych...

Nie traktuję tego jednak jako dowodu, że jedno wspólne okno będzie dobre dla wszystkich. W zarządzanych środowiskach dzielę VBR według ich harmonogramów, zależności i znaczenia. Osobno kwalifikuję VCC, środowiska z rozbudowanym Backup Copy, taśmami, SureBackup oraz komponentami, których aktualizacja może potrwać dłużej.

Jak można rozwinąć Veeam Updater 💡

W dyskusji @Mariusz zwrócił uwagę, że statystycznie niedziela około 14:00 może być dobrym terminem: backupy często już nie pracują, a produkcja jest mniej obciążona. Problem w tym, że statystyka nie opisuje każdego środowiska. U części moich klientów z niepracującymi weekendami właśnie wtedy działają SureBackup, health check, CRC, merge, skanowanie malware i inne operacje związane z weryfikacją lub utrzymaniem łańcuchów backupu (a czasami nawet w weekendy przeprowadzane są testy przed aktualizacjami systemów produkcyjnych za pomocą On-Demand Sandboxingu).

Dlatego kolejnym krokiem rozwoju tej funkcjonalności, nie powinno być tylko dodawanie następnych pozycji w harmonogramie. Przydałby się Updater świadomy stanu środowiska.

Najbardziej praktyczny model widzę tak:

• administrator wskazuje przedział albo termin preferowany, na przykład niedzielę o 14:00 lub sobota między 10:00 a 20:00, ale nie musi to być bezwzględna godzina rozpoczęcia;
• jeżeli o tej porze działa SureBackup lub inne zadanie, Updater nie przerywa go, tylko szuka kolejnego odpowiednio długiego okna;
• Updater rozpoczyna instalację dopiero wtedy, gdy nie działa backup, Backup Copy, replikacja, SureBackup, odtwarzanie, Instant Recovery, zadanie taśmowe ani operacja testowania lub utrzymania repozytorium;
• przed startem sprawdza, czy w przewidywanym czasie aktualizacji nie rozpocznie się kolejne zadanie i czy pozostaje wystarczający margines na instalację, restart oraz kontrolę stanu środowiska (zakładam że przy odpowiednio rozwijającym się Veeam AI, system VBR powinien w miarę dobrze móc oszacować w oparciu o infrastrukturę klienta czasochłonnośc aktualizacji);
• aktywna sesja odtwarzania, Instant Recovery, failover, proces związany z VCC albo problem ze storage bezwzględnie blokuje aktualizację;
• jeśli bezpieczne okno nie pojawi się przed terminem wymuszonej instalacji, administrator dostaje wcześniej alarm i może podjąć decyzję, zamiast dowiedzieć się o konflikcie w ostatniej chwili.

Tu widzę naturalne miejsce dla Veeam ONE (choć może usałoby się to zrealizować bezpośrednio w VBR) i coraz szerzej wykorzystywanych mechanizmów AI. Nie chodzi tylko o sprawdzenie, czy w danej chwili lista sesji jest pusta. Dane historyczne mogłyby pomóc wyliczyć sugerowane okno na podstawie rzeczywistych czasów zadań, ich zmienności i wykorzystania repozytoriów. Osobny model mógłby przewidywać czas samej aktualizacji na podstawie poprzednich aktualizacji tego środowiska, wydajności serwera, liczby i rodzaju komponentów zdalnych, czasu wcześniejszych restartów oraz doświadczeń z podobnych instalacji. Updater wiedziałby wtedy nie tylko, kiedy zadania prawdopodobnie się zakończą, ale również jak długiego okna faktycznie potrzebuje. Wynik powinien być rekomendacją z pokazanym marginesem bezpieczeństwa i poziomem pewności, a nie autonomiczną decyzją bez możliwości kontroli.

Drugi kierunek to aktualizacje falowe. Przy wielu VBR, a szczególnie w VCC, potrzebne byłyby:

1. grupa pilotżowa albo pojedynczy serwer reprezentujący typowe środowisko;
2. automatyczne testy po aktualizacji;
3. zatrzymanie kolejnej fali po błędzie lub pogorszeniu stanu usług;
4. osobne reguły dla VCC, tenantów, VSA/VIA i komponentów zdalnych;
5. centralny widok zgodności wersji, terminów, przewidywanego czasu aktualizacji i wyjątków.

Taki mechanizm miałby sens w trzech miejscach, ale każde z nich pełniłoby trochę inną rolę:

• Veeam ONE (lub sam VBR) analizowałby historię, obciążenie i zależności, a następnie wskazywał najlepsze okno oraz przewidywany czas aktualizacji;
• Enterprise Manager pozwalałby koordynować aktualizacje wielu serwerów VBR w jednej organizacji, definiować grupy, kolejność i zatwierdzenia;
• VSPC rozszerzałby ten model na środowiska zarządzane przez Service Providera, z politykami, falami wdrożeniowymi, wyjątkami i kontrolą zgodności wersji dla wielu klientów.

Nie traktowałbym tych produktów jako trzech konkurencyjnych konsol. Najwięcej sensu miałaby współpraca: Veeam ONE (lub VBR) dostarcza analizę, Enterprise Manager koordynuje środowisko jednej organizacji, a VSPC zarządza ‘flotą’ pod nadzorem Service Providera.

Przydałyby się też konfigurowalne warunki wejścia i wyjścia, czyli:

Przed aktualizacją system mógłby potwierdzić:

• świeży, zaszyfrowany backup konfiguracji,
• wolne miejsce,
• brak prywatnego hotfixa wymagającego konsultacji oraz dostępność wszystkich krytycznych komponentów.

Po restarcie powinien:

• sprawdzić usługi,
• stan infrastruktury,
• połączenie z repozytoriami i uruchomić wskazany przez administratora test syntetyczny.

Dopiero jego wynik pozwalałby przejść do kolejnej fali.

Nie oczekiwałbym automatycznego cofania aktualizacji w każdej sytuacji. Przy bazie konfiguracji, zdalnych komponentach i zmianach schematu powrót do wcześniejszej wersji może być bardziej ryzykowny niż zatrzymanie procesu. Ważniejsze byłoby automatyczne przerwanie kolejnych wdrożeń, zebranie diagnostyki i jasne wskazanie, który warunek nie został spełniony.

Na końcu potrzebne są API, webhooki i kalendarze wyłączeń. Pozwoliłoby to połączyć Updater z własnym procesem utrzymaniowym, systemem zgłoszeń i zmianami planowanymi u klienta, bez budowania całej logiki wokół klikania w konsoli.

🔮To nie jest opis funkcji dostępnych obecnie w 13.1. To kierunki, które moim zdaniem zmieniłyby Updater z automatycznego instalatora działającego według zegarka w rzeczywisty mechanizm zarządzania aktualizacjami całej infrastruktury Veeam w różnych środowiskach.

Backup konfiguracji i ewentualny snapshot przed aktualizacją 💾

Oficjalna checklista Veeam wymaga wykonania backupu konfiguracji przed aktualizacją. W zarządzanym środowisku nie ograniczałbym się do sprawdzenia, czy harmonogram jest włączony. Przed oknem serwisowym trzeba:

• uruchomić świeży backup konfiguracji i potwierdzić jego sukces;
• sprawdzić, czy backup jest zaszyfrowany, ponieważ bez szyfrowania nie zawiera zapisanych poświadczeń;
• potwierdzić, że plik jest dostępny również wtedy, gdy aktualizowany serwer VBR będzie niedostępny;
• osobno zabezpieczyć istotne modyfikacje rejestru, ponieważ nie są objęte backupem konfiguracji;
• znać procedurę odtworzenia konfiguracji, a nie tylko miejsce zapisania pliku.

Ręczny snapshot VM na poziomie hypervisora może być przydatnym, krótkotrwałym punktem kontrolnym (ale nie jest zamiennikiem wspieranej ścieżki odtworzenia z backupu konfiguracji 0 choć nie ukrywam, że kilka razy uratował mi trochę czasu). Trzeba go oczywiście rozpatrywać indywidualnie:

• utworzyć dopiero po zatrzymaniu aktywnych sesji i zadań;
• zapewnić spójność serwera VBR z bazą konfiguracji (w przypadku rozdzielenia usług na osobne serwery);
• pamiętać, że przy zewnętrznej bazie snapshot samej VM nie cofa całego systemu do jednego punktu;
• usunąć po pozytywnej weryfikacji aktualizacji, aby nie utrzymywać długo rosnących plików delta.

Veeam odradza chronienie konfiguracji serwera backupu zwykłym zadaniem backupu lub replikacji VBR, ponieważ operacje snapshot mogą zamrozić VM i zerwać połączenia z bazą, agentami albo storage. Dlatego pierwszą i wspieraną warstwą zabezpieczenia jest Configuration Backup. Snapshot platformy, jeśli zostanie świadomie dopuszczony w danej architekturze, pozostaje tylko dodatkiem operacyjnym.

Updater a aktualizacja zdalnych komponentów 🌍

Veeam Updater odpowiada za pobranie i instalację aktualizacji produktu na serwerze VBR. Oddzielnym usprawnieniem 13.1 jest Automatic Component Upgrade Distribution, które może rozprowadzić nową wersję komponentów na serwery zarządzane, proxy i repozytoria.

Te dwa mechanizmy zmniejszają pracę ręczną, ale nie zastępują kolejności, zależności i testów. W dużym środowisku trzeba uwzględnić:

• zakres ról objętych danym mechanizmem oraz role wymagające osobnej aktualizacji;
• VCC oraz wersje Klientów;
• długie Backup Copy i zadania taśmowe;
• wymagany restart;
• miejsce na pakiety na dysku systemowym;
• prywatne hotfixy i zależności wskazane przez Support.

Jak wdrażałbym to w zarządzanych środowiskach 🔨

U mnie kolejność wygląda tak:

1. Przeczytać Release Notes, KB i znane problemy konkretnego pakietu.
2. Sprawdzić wolne miejsce na serwerze VBR.
3. Wykonać świeży, zaszyfrowany backup konfiguracji i zweryfikować jego niezależną (od VBR) dostępność.
4. Jeśli architektura i granice wsparcia na to pozwalają, przygotować krótkotrwały snapshot jako dodatkowy punkt kontrolny.
5. Ustawić okno serwisowe na podstawie rzeczywistych czasów zakończenia zadań, a nie pozostawiać automatycznie domyślnego terminu.
6.  Zaktualizować środowisko pilotażowe (jeśli występuje) o reprezentatywnych rolach.
7. Uruchomić test backupu, Backup Copy, odtworzenia pliku i pełnego odtwarzania testowej VM.
8. W VCC najpierw zweryfikować stronę providera, a później pilotażowego Klienta i kolejne grupy.
9. Rozprowadzić komponenty zdalne w kontrolowanej kolejności.
10. Sprawdzić status wszystkich serwerów zarządzanych, proxy, repozytoriów, WAN Acceleratorów i agentów.
11. Następnego dnia (zazwyczaj) potwierdzić pierwsze pełne cykle zadań oraz raportowanie.
12. Po kilku aktualizacjach zweryfikować, czy wybrane okno nadal pasuje do rzeczywistych czasów zadań i czy nie wymaga przesunięcia.

Najpierw provider, potem klient- taką kolejność przyjmuję zwłaszcza wtedy, gdy nowa funkcja wymaga konkretnej wersji VBR po obu stronach. Nie oznacza to, że każda poprawka w obrębie wersji VBR ma formalnie tę samą regułę zgodności.

Znany problem, który trzeba uwzględnić w procedurze 💣

Po aktualizacji VBR 13.0 do 13.1 VIA z rolą WAN Accelerator może pozostać ze statusem Out of Date. Release Notes zalecają ponowne uruchomienie Host Upgrade Wizard. W środowisku VCC lub rozbudowanym Backup Copy dodaję ten punkt do weryfikacji powdrożeniowej.

Czego nie robić

• Nie odinstalowywać komponentu Updater.
• Nie czekać do 30. dnia bez zaplanowanego okna.
• Nie zakładać, że Updater ominie pracujące zadania przy wymuszonej instalacji.
• Nie kończyć testu na samym uruchomieniu konsoli po restarcie.
• Nie aktualizować całej floty serwerów jednocześnie przed przejściem pilotażu.

Jak układacie automatyczne aktualizacje? 🔮

Updater wymusza regularność, ale nie zastępuje pilotażu (w większych środowiskach). Bez właściciela procesu, okna serwisowego i testu po instalacji ta sama wadliwa aktualizacja może trafić do kolejnych środowisk.

Jak układacie to u siebie?

• ile fal aktualizacji stosujecie i jakie środowisko pełni rolę pilotażu;
• kto ustawia okno serwisowe oraz odpowiada za termin wymuszonej instalacji;
• które zadania, testy odtwarzania i integracje sprawdzacie przed przejściem do kolejnej fali;
• w jakiej kolejności aktualizujecie środowisko providera VCC, tenantów i komponenty zdalne;
• ile czasu rezerwujecie na VSA i VIA, gdy aktualizowany jest cały appliance, szczególnie na mniej wydajnej infrastrukturze;
• jak monitorujecie wymuszony restart, nieudane wdrożenie poprawki i stan po ponownym uruchomieniu;
• gdzie przechowujecie zaszyfrowany backup konfiguracji oraz jak sprawdzacie możliwość jego użycia;
• czy snapshot VM jest u Was dopuszczony jako krótkotrwałe zabezpieczenie pomocnicze i kto pilnuje jego usunięcia (a może to podstawowe i jedyne zabezpieczenie prze upgradem? - z tym też się spotkałem😐).

Pytanie do osób utrzymujących wiele niezależnych VBR: czy Updater faktycznie zmniejsza u Was liczbę zaległych poprawek, czy głównie przenosi pracę z ręcznej instalacji na zarządzanie wyjątkami i oknami serwisowymi? I czy też brakuje Wam okna zależnego od stanu zadań, zamiast wyłącznie od dnia i godziny?

Źródła 🌊

• KB4840 - Veeam Updater
• Dyskusja pod wpisem o VSA i VIA
• What's New - General Improvements
• Upgrade Checklist
• Managing Configuration Database
• Configuration Restore - Before You Begin
• VBR 13.1 Release Notes
• Wersje VBR w Veeam Cloud Connect

Jak planujecie zarządzać terminem wymuszonej instalacji: wspólne okno dla całej floty, fale według typu środowiska czy indywidualne okna serwisowe?

U mnie najlepiej sprawdza się centralne pilnowanie aktualności, ale terminy dopasowane do konkretnych grup środowisk.