Veeam, według potwierdzonych już informacji od stycznia 2021 wprowadza zmiany w licencjonowaniu.

• Dla nowych klientów nie będzie możliwości zakupu nowych licencji wieczystych per CPU w wersjach Veeam Backup and Replication Standard i Enterprise oraz Veeam Availability Suite Standard i Enterprise.

1. Dostępna będzie jedynie wersja VBR/VAS Enterprise Plus ze wsparciem produkcyjnym. Oznacza to, że wszystkie licencje będą w najwyższej wersji ze wszystkimi możliwymi funkcjonalnościami.
2. W przypadku produktów Veeam Backup Essentials nadal wszystkie wersje dostępne (Standard, Enterprise, Enterprise Plus). Dla przypomnienia wersja Essentials obejmuje paczki licencyjne po 2 CPU. Maksymalnie takich paczek mogą być 3 czyli możemy objąć licencjonowaniem 6 procesorów (wersją Standard, Enterprise lub Enterprise Plus).
3. W przypadku upgrade’u z wersji Essentials na wersję VBR/VAS (czyli na wersję umożliwiającą licencjonowanie większej ilości procesorów niż 6), możliwy będzie upgrade tylko do edycji Enterprise Plus ze wsparciem produkcyjnym.

• Obecni klienci posiadający już produkty VBR Standard lub Enterprise oraz VAS Standard lub Enterprise nadal będą mieli możliwość dokupienia licencji w posiadanych wersjach czyli kontynuowania wsparcia funkcjonalności na pierwotnym poziomie.

Funkcjonalności jakie w Veeam pojawią się od wersji v11.

Wszystkie informacje docierające do nas z Veeam mówią, że będzie naprawdę przełomowo. Producent zapowiada, że V11 powinniśmy spodziewać się w Q1 2021. Oto kilka z najciekawszych zmian:

• Continuous Data Protection (CDP) przeznaczone dla aplikacji, dla których nie dopuszczamy straty jakichkolwiek danych.

Rozwiązanie będzie wykorzystywać vSphere APIs for IO Filtering (VAIO) co oznacza przechwytywanie wszystkich IO jakie trafiają z wirtualnych maszyn na dyski. Przy wydajnych środowiskach oznacza to, że nie będzie praktycznie żadnej straty danych w stosunku do replikowanej maszyny. Przy mniej wydajnym środowisku może to być np. 15 sekund co i tak jest bardzo dobrym wynikiem.
Prawdopodobnie do dyspozycji będziemy mieli specjalny suwak podobnie jak w Zerto, za pomocą którego będziemy się mogli cofnąć o pojedyncze RPO. Nie będą do tego wykorzystywane snapshoty. Zaznaczymy z jakiego okresu chcemy odzyskać przechwycone zapisy (np. z 4 godzin) i tyle. Dodatkowo nadal będzie można zaznaczyć long-term retention i będzie działać zgodnie z uprzednią metodą z wykorzystaniem snapshotów.
Podsumowując, dla danej zreplikowanej maszyny będziemy mogli się odzyskiwać przykładowo co 5 sekund z 4 godzin i jednocześnie z long-term replik zrobionych np. co 12h przez 7 dni.

• Lepsze wykorzystanie wieloprocesorowych serwerów proxy (również ulepszone Linux Proxy).

Do tej pory bywały problemy z odpowiednio wydajnym wykorzystaniem mocy drzemiącej w dużych wieloprocesorowych serwerach Veeam Proxy.

• Linux proxy transport modes czyli poprawiony tryb transportowy HotAdd, dodane NBD (Network Block Device protocol) oraz Direct SAN (iSCSI, FC, NFS).

• Możliwość ustawiania priorytetów dla zadań tak aby zadania o większym priorytecie miały pierwszeństwo w kolejce zadań.

• Lepsze wykorzystanie tagów vSphere i ich łączenia operatorami AND w celu wykonywania backupu tylko maszyn wirtualnych mających komplet tagów.

• Hardened Linux repository. W wersji 10 można było odkładać kopie zapasowe na linux repository ale było to traktowane raczej jako zapasowe repozytorium backupu.

Obecnie w wersji 11 będzie można traktować Hardened Linux repository jako podstawowe miejsce składowania backupu (z podpiętymi zasobami lokalnie lub przez sieć SAN). Dodatkowo dojdzie funkcjonalność WORM 😊
W tym przypadku nawet administrator backupu nie usunie danych przed upłynięciem odpowiedniego, wcześniej ustalonego czasu (immutable flag).

• Odzyskiwanie pojedynczych plików Linux bez konieczności używania helper appliance. Czyli FLR bez FLR appliance.

Oznacza to, że będzie można podmontować backup do jakiejkolwiek istniejącej maszyny linux w celu odzyskania plików (FLR Helper appliance będzie jednak nadal dostępna, pomimo tej funkcjonalności).

• Możliwość wykorzystania backupu z użyciem sieci SAN (poprzez migawki lub bezpośrednio) również dla fizycznych serwerów.

Wcześniej było to możliwe tylko dla wirtualnych maszyn. Najczęściej będzie to oznaczać backup OS agentem a następnie poszczególnych wolumenów z użyciem sieci SAN.

• Wykorzystanie CFS (changed file tracking) dla zasobów NAS.

Pozwoli to na znaczne przyspieszenie backupu zasobów plikowych.

• Instant Recovery dla MSSQL, Oracle and NAS

Przykładowo dla serwera MSSQL może zaistnieć wiele sytuacji, w których musimy szybko przywrócić dostęp do kluczowych baz danych:

1. Uszkodzenie jednej konkretnej bazy danych, podczas gdy sam serwer działa poprawnie, podobnie jak reszta baz danych, i nie musimy przywracać całego serwera, ale rozmiar tej bazy danych nie pozwala na jej przywrócenie (w klasyczny sposób) w rozsądnym czasie i konieczne jest jak najszybsze przywrócenie jej wydajności.
2. Całkowita awaria serwera bazy danych, ale mamy zapasowy (inny) serwer bazy danych, na którym możemy szybko przywrócić dostęp do bazy. Przykładowo dysponując dużym fizycznym serwerem baz danych możemy mieć tzw. Cold standby w postaci maszyny wirtualnej, na której w przypadku awarii serwera głównego możemy szybko uruchomić krytyczny zestaw baz danych.
3. Możliwa jest również migracja bazy danych z jednego serwera na inny przy minimalnych przestojach.

Obecnie w takiej sytuacji możemy odzyskać cały serwer, uruchomić replikę, uruchomić wirtualną maszynę w trybie Instant Recovery, lub odzyskać samą bazę gdzieś na boku.
W wersji v11 będziemy mogli zamontować samą bazę w trybie Instant Recovery (natychmiast z backupu) na ten sam serwer lub inny serwer a następnie w spokojniejszej chwili zmigrować działająca bazę w całości na produkcję