W poprzedniej artykule Opowiedzieliśmy wam o nowych funkcjach w styczniowej aktualizacji Update 4 dla Veeam Backup & Replication 9.5 (VBR), gdzie świadomie nie wspomnieliśmy o kopiach zapasowych na taśmach magnetycznych. Temat tej dziedziny zasługuje na osobny artykuł, ponieważ nowych funkcji było naprawdę wiele.

– Chłopaki z QA, napiszecie artykuł?
– A czemu nie!

Napędy taśmowe w XXI wieku

Przechowywanie danych na taśmach magnetycznych (kasetach, „taśmach”, jak my w R&D je nazywamy) nie ogranicza się do przestarzałego komputera ZX-Spectrum, w którego pamięci operacyjnej mogła ładować się jedna gra przez kilka minut z kasety magnetofonowej . Przez ćwierć wieku prędkości i pojemności kaset wzrosły o 6-7 rzędów wielkości. To nie do końca poprawne porównanie, a według prawa Moore'a standard LTO nie nadąża. Niemniej jednak, nowoczesne technologie pozwalają na zapisanie na kilometrowej taśmie jednej kasety 12 terabajtów danych (do 30 terabajtów w trybie kompresji), w ten sposób 160-dolarowy napęd zostawia konkurentów w tyle pod względem kosztu długoterminowego przechowywania dużych ilości danych, nawet przy uwzględnieniu inwestycji w sprzęt do zapisu/odczytu. Dane na takich kasetach są bezpiecznie przechowywane przez 15-30 lat.

Podchodzę z innej strony. W ostatnim czasie ransomware osiągnęły nowy poziom. Mogą czekać na swoją okazję w infrastrukturze dużej firmy przez tygodnie i miesiące, a wraz z pojawieniem się kolejnej luki zero-day – zniszczyć (nie bez pomocy człowieka, bo na szali są duże pieniądze) nie tylko wszystkie dane, ale i wszystkie kopie zapasowe, do których tylko można się dostać. Oto świeży przykład, kiedy firma musiała zapłacić hakerom. Tak zwane air gap, czyli fizycznie odizolowane od infrastruktury kopie zapasowe stały się w zasadzie jedynym niezawodnym ratunkiem przed takimi sytuacjami. Taśma magnetyczna tutaj – jedno z ponadczasowych rozwiązań.

Jednak jedna specyfikacja i technologiczne nowinki z branży barowo-ferytowych od czołowych producentów (IBM, HPE, Oracle, Dell) nie wystarczą do skutecznej ochrony danych, potrzebne jest dobre oprogramowanie. W Veeam mamy cały zespół zajmujący się kopiami zapasowymi na taśmach, około 10 osób codziennie analizuje, planuje, bada, rozwija i testuje. Wyniki tej pracy mogliście zobaczyć w poprzednich artykułach (raz, dwa). Co zostało zrobione w ostatnim roku?

Słownik terminów

Staje przed wyborem między swobodą wobec ojczystego języka a komplikującymi czytelność biurokratyzmami. Preferuję pierwsze, dlatego z góry przepraszam, jeśli dla kogoś żargonowe słowa z poniższej listy będą razić w oczy. Tutaj w skrócie przypomnę, co oznacza dany termin.

Mistrzowie VBR mogą pominąć tę częśćJob – job – zadanie kopii zapasowej. Właściwie całe VBR opiera się na jobach. Oprócz backupu i replikacji, może to być również kopiowanie na taśmę magnetyczną (backup to tape job, tape job). Zastrzegam, że przywrócenie z kopii zapasowej (restore) – to także job, ale w tym artykule przez to słowo będziemy rozumieć właśnie backup.

Storage – storage – historycznie ugruntowana nazwa. To pliki w repozytorium (repository – repozytorium), zawierające kopie zapasowe – pełne i inkrementalne. W jednym storage może znajdować się zarówno jedna, jak i kilka maszyn wirtualnych.

Ciąg – chain – sekwencja powiązanych ze sobą storage. Do przywrócenia danych z n-tego inkrementalnego storage potrzebne są wszystkie poprzednie od (n-1) do 1 oraz pełny storage, do którego odnosi się pierwszy inkrementalny.

Source, target – source, target. Source – pierwotna jednostka, którą przetwarza job. W przypadku backupów/replikacji jest to zazwyczaj maszyna wirtualna w hypervisorze. W przypadku tape job source to sama job backupowa (lub pliki w przypadku job file to tape). Target dla job backupowej – to repozytorium, w którym przechowywane są kopie zapasowe. Natomiast dla tape job jest to pula nośników.

Media pool – media pool – pula nośników informacji, w naszym przypadku – kaset. Logiczny kontener tworzony przez użytkownika, zawierający kasety z jednej lub kilku bibliotek. Tak więc tape job zawsze ma media pool jako target, to znaczy, że dane są zapisywane nie na konkretnej kasecie ani na dowolnej kasecie w bibliotece, lecz na określonym zestawie. Media pool ma ustawienie czasu przechowywania danych, po którym kaseta może być nadpisana. Użytkownik może tworzyć zwykłe (standard) oraz pule GFS.. Każdy z tych rodzajów może być teraz również WORM i nie-WORM, o tym poniżej.

Media set – media set – zestaw taśm w pulach mediów, na które nieprzerywanie zapisywane są kopie zapasowe/pliki. Dla pul GFS zestawy mediów są powiązane również z interwałem (na przykład rocznym – yearly), taśmy rotują tylko w swoim interwale.

Napęd, zmiennik – elementy biblioteki taśmowej. Napęd odczytuje i przewija taśmę, zmiennik – to robot, który przesuwa taśmy pomiędzy slotami przechowywania, slotami wyładunku i napędem. Są także napędy standalone (standalone – stojący osobno), rolę zmiennika tutaj pełni człowiek. Dla napędu kluczowe jest prawidłowo zainstalowane sterownik producenta na maszynie Windows, do której podłączona jest biblioteka; ze zmiennikiem możemy pracować i bez sterowników, przez native SCSI.

Najemca na taśmę. Chroniony dostawca – chronieni klienci

Od razu asy na stole. Najbardziej rozbudowana funkcjonalność naszej aktualizacji, przeznaczona dla dostawców chmurowych, którzy w swojej infrastrukturze wykorzystują VBR. Prace rozpoczęły się dwa lata temu. Niedługo zorientowaliśmy się, że nie damy rady sprostać temu poważnemu zadaniu przed najbliższym wydaniem, wzięliśmy małą pauzę, a w końcu wypuściliśmy funkcjonalność w 9.5 Update 4.

Krótko mówiąc, teraz dostawcy mają możliwość kopiowania kopii zapasowych swoich klientów na taśmy za pomocą zadań taśmowych w GFS-puli. Daje to dostawcom – a są to bardzo ważni dla nas i naszego działu handlowego klienci – dwie możliwości:

• ochronić swoich klientów (najemców, najemca – osoba wynajmująca) przed utratą danych na skutek przypadkowego usunięcia lub problemów infrastrukturalnych („powódź w serwerowni”);
• umożliwić najemcom dodatkową usługę przywracania danych z starej kopii zapasowej, która już dawno została usunięta z chmurowego repozytorium zgodnie z polityką przechowywania danych, ale na taśmach nadal pozostała.

Z punktu widzenia marketingowego funkcjonalność jest bardzo atrakcyjna, z naszej perspektywy nie mniej skomplikowana w realizacji.

Rozwój

Główny problem, który się pojawił – to szyfrowanie danych. Większość chmurowych kopii zapasowych jest zaszyfrowana, statystyki mówią o ⅔ z ogólnej liczby. Ta liczba była dla nas zaskoczeniem, przypuszczaliśmy, że szyfrowanych jest prawie wszystko, ale nie – wielu klientów, zdaje się, bezwarunkowo ufa swoim dostawcom.

Paradigma jest prosta: dostawca nie powinien być w stanie odszyfrować danych swoich najemców. W ramach nowej funkcji wymagane jest otwieranie magazynów z kopiami zapasowymi po stronie dostawcy. Jest to potrzebne, aby przenosić bloki danych, na przykład w celu stworzenia wirtualnej pełnej kopii zapasowej. Najważniejsze jest, aby robić to niezależnie od najemcy, kiedy klucze nie są przekazywane do dostawcy podczas wykonywania zadania.

Rozwiązanie tego problemu, zaangażowane zresztą również w innej ważnej funkcji wydanego dodatku – Capacity Tier – polega na dodaniu dodatkowego klucza szyfrującego. Klucz archiwalny (Archive key) jest przechowywany w bazie dostawcy w postaci zaszyfrowanej. Dzięki sprytnej schemie po stronie dostawcy można używać go do otwierania magazynu, przenoszenia i ponownego szyfrowania bloków danych między magazynami (przecież każdy ma swój klucz), ale nie można odszyfrować samych danych.

Sprytna schemat (działająca wersja)

Dodam, że wszyscy inżynierowie w R&D bardzo lubią szyfrowanie w naszym produkcie, chociaż nikt nie wie dokładnie, jak to działa. (Tutaj była jeszcze żart „dlaczego w ogóle to działa”, ale redaktorzy tego nie puścili.)

Testowanie

Na funkcję zostały zgłoszone setki błędów. Najtrudniejsze obszary to – szyfrowanie, interfejs użytkownika, problemy podczas przywracania.

Z punktu widzenia testowania trudność polegała na dużej zmienności, „kombinatoryce” rodzajów i typów zadań najemców oraz repozytoriów – mam na myśli zarówno źródło, jak i cel podczas przywracania kopii zapasowych w infrastrukturze. Wszystko to jest związane z logiką w ramach modelu GFS (w tym nowym – równoległość i codzienne zestawy mediów, o tym poniżej), a także ogólnie z nietypową dla typu specyfiką chmurową. Nie zapomnij przyprawić obficie szyfrowaniem. Kontynuując metaforę, dobrze się tym daniem najadaliśmy – ale i degustowaliśmy ze wszystkich stron.

Fragment planu testów

W rezultacie

Szczegółowy opis można znaleźć w podręczniku użytkownika (na razie w języku angielskim): kopiowanie zapasowe, przywracanie. Zatrzymam się na głównych punktach.

Kopia zapasowa

Dostawca dodaje najemców do zadania typu tape z pulą GFS jako celem. W przypadku posiadania licencji chmurowej na drugim kroku kreatora dostępna jest opcja NajemcyMożna dodać wszystkich najemców jednocześnie lub osobno, a także wybrać tylko osobną kwotę (ale nie subkwotę) danego najemcy. Nie można łączyć w jednym zadaniu kopii zapasowych najemców i standardowych lokalnych.

Pozostałe ustawienia są prawie całkowicie identyczne jak w zwykłym zadaniu w GFS-pulu.

Przywracanie danych jest możliwe zarówno po stronie dostawcy, jak i po stronie samego najemcy.

Przywracanie po stronie dostawcy

Przeprowadzane jest przez nowy kreator. Można zejść na poziom pojedynczego zadania, przywraca się całą sekwencję, która znajdowała się w repozytorium w określonym dniu.

Są trzy opcje przywracania:

1. Do oryginalnej lokalizacji. W takim przypadku oryginalna kopia zapasowa, jeśli istnieje, jest usuwana; zadania najemcy są automatycznie rekonfigurowane na przywróconą sekwencję. Zakłada się, że takie przywracanie będzie całkowicie niezauważalne dla klienta, jedynie na krótki czas będzie on odłączony od chmurowego repozytorium.
2. Do nowej kwoty/repozytorium. Dostawca może na przykład stworzyć w tym celu osobne tymczasowe konto, które później zostanie usunięte. Kopia zapasowa pojawia się w infrastrukturze najemcy po synchronizacji z bazą dostawcy.
3. Po prostu na dysk serwera Linux lub Windows, zarejestrowanego w infrastrukturze dostawcy. Następnie tę sekwencję można nagrać na pendrive'a i wysłać do najemcy.

Przywracanie po stronie najemcy

Ta opcja zakłada posiadanie przez klienta własnej infrastruktury taśmowej oraz dużej objętości danych do przywrócenia. Taśmę z zapisanymi kopiami zapasowymi dostawca może fizycznie wysłać klientowi pocztą, ten kataloguje ją na swoim sprzęcie, deszyfruje taśmy i kopie zapasowe i pracuje z kopiami zapasowymi tak, jakby to on je sam nagrał na taśmę. Taki sposób, aby nie pobierać terabajtów przez WAN.

Ogromne ulepszenia GFS-pulu

GFS-media-pule pojawiły się w VBR dwa lata temu, w wersji 9.5. W wydanej aktualizacji, zarówno w związku z pojawieniem się funkcji Najemca na taśmie, jak i na prośbę użytkowników, znacznie poprawiliśmy tę funkcjonalność.

Codzienne zestawy multimedialne

Pojawił się nowy codzienny (daily) media-set. Teraz w pule GFS można przechowywać kopie zapasowe za każdy dzień, nie tylko pełne, ale i inkrementalne. Te ostatnie zajmują znacznie mniej miejsca i zostały wprowadzone w celu oszczędności taśmy. Zakłada się, że te kasety są stale rotowane w bibliotece i nie są przewożone do archiwum. Przy tym, dla restauracji z inkrementalnego punktu potrzebne będą kasety z jednego z starszych zestawów mediów (tygodniowego, miesięcznego, kwartalnego lub rocznego). Nie można włączyć codziennego zestawu mediów bez włączenia tygodniowego, aby w większości przypadków do przywracania z kopii inkrementalnej wymagana była właśnie kaseta tygodniowa. Są one albo zawsze w bibliotece, albo przechowywane w mniej odległym magazynie.

Logika działania tape-jobs w GFS-media-pool nie jest najprostsza, pisarze techniczni nie dadzą kłamać. Jeśli w dwóch słowach, pomijając szczegóły, to w tygodniowe i starsze zestawy mediów kopiowane są tylko pełne kopie zapasowe (w tym wirtualne pełne kopie zapasowe), po jednej na każdą datę, a w codziennym – wszystkie znajdujące się w repozytorium kopie zapasowe z bieżącego dnia, ponieważ backup-job może być uruchamiane częściej niż raz dziennie.

Równoległość, czas uruchomienia i oczekiwanie w GFS-pulach

Teraz równoległe zapisywanie kilku łańcuchów lub zadań na kilku dyskach biblioteki jest możliwe również w GFS-media-pulach (wcześniej – tylko w zwykłych). Włącza się to na etapie Options media-pulu.

Ważne uzupełnienie: ten sam plik zawsze jest zapisywany w jednym strumieniu, dlatego w przypadku kilku dużych maszyn wirtualnych zaleca się włączenie ustawienia per-VM w repozytorium, aby kopia zapasowa składała się z kilku łańcuchów.

Oprócz tego stało się możliwe wybieranie czasu uruchomienia samej GFS-job. Wiele użytkowników nie lubiło uruchamiania o północy, a następnie czekania prawie całego dnia, aż źródłowa praca się zakończy. Teraz ten czas można na przykład ustawić na późny wieczór, kiedy jest już co kopiować na taśmę. Co więcej, na prośby użytkowników wprowadziliśmy do zaawansowanych ustawień opcję, którą wcześniej można było aktywować tylko za pomocą klucza rejestru. Wystarczy wybrać Przetwarzaj najnowszy punkt przywracania zamiast czekać – na taśmę kopiowane są dane z repozytorium w momencie rozpoczęcia procesu tape job (punkt na wczoraj, na przykład), a oczekiwanie jest całkowicie wyeliminowane.

Udoskonalone zarządzanie wieloma bibliotekami

Mowa będzie o sytuacji, gdy do jednego media pool dodano więcej niż jedną bibliotekę. Wcześniej również wspieraliśmy takie rozwiązania, jednak czasami otrzymywaliśmy skargi od klientów dotyczące nie do końca przewidywalnego zachowania.

Było

Na przykład, rozpoczęto tape job, które zajęło dwa napędy w pierwszej bibliotece, ale ustawienia równoległości pozwalają na użycie od razu 4 napędów. Czy to zadanie powinno przełączyć się na drugą bibliotekę media pool i używać jej również, czy byłoby to marnotrawstwem zasobów?

Inny przypadek. Wybrano opcję przełączania w warunku „brak dostępnych taśm”, w pierwszej bibliotece jest tylko jedna taśma, lecz potencjalnie można na nią umieścić wszystkie dane. Jednak ustawienia pozwalają na równoległe zapisywanie na dwóch taśmach. Czy w takim przypadku należy zaangażować drugą bibliotekę?

Postanowiliśmy uporządkować tę sferę, dając możliwość wyraźnego dostosowania zachowania.

Stało się

Biblioteki w media pool zyskały role – aktywną i pasywną. A sam media pool ma dwa tryby: odpornościowy, czyli failover (failover) oraz równoległe zapisywanie (paralleling). Teraz, w zależności od potrzeb, można skonfigurować media pool w różny sposób.

• Jeśli masz kilka równoprawnych bibliotek i potrzebujesz rozproszyć zapisywanie pomiędzy nimi – włączasz tryb równoległego zapisywania, przy czym wszystkim bibliotekom należy przypisać aktywne role. W takim przypadku nowe taśmy i napędy będą angażowane natychmiast, gdy zajdzie taka potrzeba, niezależnie od tego, w której bibliotece się znajdują. Priorytet jest zachowany – najpierw będziemy starali się znaleźć zasoby w bibliotece znajdującej się wyżej na liście.
• Jeśli jednak masz jedną główną bibliotekę oraz jeden starszy lub stndalonowy napęd w rezerwie, włączasz tryb failover, umieszczając główną bibliotekę na górze listy i wybierając pasywną rolę dla rezerwowych urządzeń. Przełączenie na takie urządzenie nastąpi tylko wtedy, gdy jest to naprawdę konieczne, by job w ogóle działał. Taka sytuacja będzie uznawana za awaryjną, o czym zostanie wysłane powiadomienie na e-mail.

Istnieje bardziej skomplikowana sytuacja, której obecnie nie wspieramy – kilka aktywnych bibliotek przy obecności pasywnych. Informacje zwrotne pokażą, czy istnieje potrzeba takich konfiguracji i czy należy »dopracować« tę funkcję w przyszłości. To standardowa praktyka.

Wsparcie WORM

WORM – Write Once Read Many – taśmy, których nie można wymazać ani nadpisać na poziomie sprzętu, można jedynie dopisywać dane. Ich obowiązkowe użycie reguluje zasady niektórych organizacji, przykładowo działających w obszarze medycyny. Głównym problemem z takimi taśmami wcześniej było to, że VBR przy inwentaryzacji lub katalogizacji zapisywał nagłówek, który następnie nie mógł być usunięty, a zadania tape job kończyły się błędami podczas takiej próby.

W wersji 9.5 Update 4 wprowadzono pełne wsparcie dla takich taśm. Dodano pule mediów WORM, zwykłe i GFS, do których można umieszczać tylko taśmy tego typu.

Nowe taśmy mają niebieską, »zamrożoną« ikonę. Z perspektywy użytkownika praca z taśmami WORM nie różni się od pracy z zwykłymi.

„Wormowość” taśm pierwotnie określa się na podstawie sufiksu kod kreskowy, a jeśli kod kreskowy jest zwykły lub nieczytelny, informacje przekazuje sterownik przy pierwszym włożeniu taśmy. Nie można umieścić taśm WORM w zwykłej puli mediów i pisać na nich. Z zabawnych rzeczy: już znaleźli się użytkownicy, którzy naklejali kody kreskowe WORM na zwykłe taśmy i byli zaskoczeni zmianami w swojej infrastrukturze po aktualizacji.

Chip taśmy

Jednocześnie z wdrażaniem taśm nieprzerwalnych zaczęto pracować z chipem. Standardowe atrybuty w chipie wcześniej przez nas nie były wykorzystywane, obecnie w niektórych z nich piszemy i czytamy, ale nie traktujemy ich jako główne źródło danych. Głównym wskaźnikiem – nadal jest nagłówek taśmy. To rozwiązanie okazało się trafne: po miesiącu od wydania widzimy, jak »zoo« sprzętu użytkowników przynosi niespodzianki w zakresie pracy z chipem.

Backup tomów NDMP na taśmę

Na zakończenie – o najbardziej pożądanej funkcji według liczby opinii w tej aktualizacji. Umożliwiono wykonanie backupu tomów NDMP na taśmy. Do infrastruktury VBR należy dodać serwer NDMP, po czym w zadaniach z użyciem taśm można wybrać wolumeny z tego hosta. Zostaną one zapisane na taśmach w postaci plików z odpowiednim atrybutem, aby odróżnić je od zwykłych podczas katalogowania.

W pierwszej implementacji istnieją pewne ograniczenia: nie obsługiwane są rozszerzenia (extensions), a także możliwy jest tylko backup i restauracja całego wolumenu, a nie pojedynczych plików. Backup działa przez dump (w przypadku NetApp – ufsdump), są tutaj pewne szczegóły: maksymalna liczba inkrementalnych punktów – 9, po czym wymuszany jest pełny backup.

Na zakończenie

To były jedynie najważniejsze nowości w zakresie backupu na taśmach w VBR 9.5 Update 4. Pozostałe zmiany przedstawiam w formie listy:

• możliwość ustalania kolejności zadań źródłowych i plików w zadaniach z użyciem taśm;
• dodana rola Operatora Taśm (użytkownik może robić wszystko, oprócz przywracania z taśm – na to jest Operator Przywracania);
• dodano pełne maski include/exclude w zadaniach z użyciem taśm (z wyjątkiem NDMP);
• doprecyzowane przywracanie w zadaniach z użyciem taśm (folder przywraca się z tymi plikami, które tam były w momencie backupu, a nie ze wszystkimi, które były tam kiedykolwiek w historii jego backupów – bardzo pożądana funkcja, nawiasem mówiąc);
• zwiększona szybkość przywracania bardzo dużej liczby plików z taśm;
• udoskonalono algorytm wyboru następnej taśmy do nagrywania, w szczególności przy równej ilości informacji sprawdzamy objętość zapisanych/przeczytanych danych przez cały jej okres eksploatacji, bierzemy najnowszą;
• ulepszono stabilność produktu.

Przydatne linki

Dla urozmaicenia przedstawiam kilka linków i do polskojęzycznych zasobów:

• Link do pobrania bezpłatnej wersji próbnej VBR 9.5 Update 4
• Artykuł na Habrze „Przydatne porady dotyczące archiwizacji backupów Veeam na taśmach magnetycznych”
• Artykuł na Habrze „7 przydatnych porad dotyczących zabezpieczania kopii zapasowych przed wirusami szyfrującymi”
• Sekcja podręcznika użytkownika dotycząca taśm (w języku angielskim)
• I wracamy do wcześniejszego miejsca z przeglądami wideo „Jak to działa” (choć na razie w języku angielskim) – można obejrzeć tutaj. O taśmach mówi się na slajdach 95 – 102.

Źródło: habr.com