Tier pojemności (lub jak nazywamy to wewnętrznie — kaptir) pojawił się jeszcze za czasów Veeam Backup and Replication 9.5 Update 4 pod nazwą Archive Tier. Pomysł na niego polegał na umożliwieniu przenoszenia kopii zapasowych, które wypadły z tak zwanego operational restore window, do obiektowych magazynów danych. Umożliwiało to zwolnienie przestrzeni dyskowej użytkownikom, którzy mieli jej niewiele. Ta opcja nazywała się Move Mode.

Aby wykonać to nieco skomplikowane (jak się wydaje) działanie, wystarczyło spełnić dwa warunki: wszystkie punkty z przenoszonej kopii zapasowej musiały znajdować się poza wcześniej wspomnianym operational restore window, które jest jednoznacznie określone w UI. I drugie: łańcuch musi być w tak zwanym «zapieczętowanym stanie» (sealed backup chain lub Inactive Backup Chain). Oznacza to, że w tym łańcuchu w miarę upływu czasu nie zachodzą żadne zmiany.

Jednak w VBR v10 koncepcja została wzbogacona o nowe funkcje — pojawiły się Copy Mode, Sealed Mode oraz rozwiązanie ze skomplikowaną nazwą Immutability.

O tych fascynujących rzeczach porozmawiamy dzisiaj. Najpierw omówimy, jak to działało w VBR 9.5u4, a później zmiany w dziesiątej wersji.

I niech mi wybaczą orędownicy czystego języka, ale zbyt wiele terminów nie da się przetłumaczyć.
Tak więc tutaj będzie mnóstwo anglicyzmów.
I dużo gifów.
I obrazków.

Bez najmniejszych wyrzutów sumienia. Autor artykułu.

Jak było

Cóż, zaczynamy od omówienia operational restore window i sealed backup (lub jak nazywają się w dokumentacji Inactive Backup Chain). Bez ich zrozumienia dalsze wyjaśnienia nie będą możliwe.

Jak widzimy na obrazku, mamy pewną sekwencję kopii zapasowych z blokami danych, która znajduje się na performance tier repozytorium SOBR, do którego podłączony jest Capacity Tier. Nasze okno operacyjne dla kopii zapasowej wynosi trzy dni.

W związku z tym, stworzony w poniedziałek .vbk zapieczętowuje poprzednią sekwencję, której okno wynosi trzy dni. Oznacza to, że z łatwością można zacząć przenosić do tieru pojemności wszystko, co jest starsze niż te trzy dni.

Ale co dokładnie oznaczało sealed chain i co mogło być wysłane do capacity tier w update 4?

Dla Forward Incremental znakiem zapieczętowania łańcucha jest stworzenie nowej pełnej kopii zapasowej. I nie ma znaczenia, jak ta pełna kopia została uzyskana: liczy się zarówno synthetic full, jak i active full backups.

W przypadku Reverse wszystkie pliki, które nie mieszczą się w operacyjnym oknie.

W przypadku Forward increment z rollbackami, wszystkie rollbacki i .vbk, jeśli na perfromansie extencie znajduje się jeszcze jeden .vbk.

Przyjrzyjmy się teraz opcji pracy z łańcuchami Backup Copy. Tutaj zbierane jest tylko to, co mieści się w GFS retention. Ponieważ wszystko, co znajduje się w nowszych łańcuchach backup copy, może zostać w ten czy inny sposób zmienione.

Teraz zajrzyjmy pod maskę. Zachodzi tam proces zwany dehydratacją - pozostawienie pustych plików backupowych na extencie i przenoszenie bloków z tych plików do pojemności tir. Do optymalizacji tego procesu używany jest tak zwany indeks dehydratacji, który pozwala nie kopiować bloków, które już zostały skopiowane do pojemności tir.

Zobaczmy, jak to wygląda na przykładzie: załóżmy, że mamy .vbk, który wyszedł z okna operacyjnego i należy do zamkniętego łańcucha. To oznacza, że mamy pełne prawo przenieść go do pojemności tir. W momencie przeprowadzki tworzony jest plik metadanych w pojemności tir oraz bloki przenoszonego pliku. W pliku metadanych na poziomie odniesień opisane jest, z jakich bloków składa się nasz plik. W przypadku na obrazku nasz pierwszy plik składa się z bloków a, b, c, a w metadanych umieszczone są odniesienia do tych bloków. Gdy pojawia się drugi plik .vbk, gotowy do przeprowadzki i składający się z bloków a, b i d, analizując indeks dehydratacji, rozumiemy, że należy przenieść tylko blok d. A jego plik metadanych będzie zawierał odniesienia do dwóch poprzednich bloków i jednego nowego.

W związku z tym, proces ponownego wypełniania tych pustych bloków danymi nazywa się rehyratacją. Używany jest już własny indeks rehyratacji, opierający się na najstarszym pliku .vbk w lokalnym performance extencie. To znaczy, że jeśli użytkownik chce przywrócić plik z pojemności tir, najpierw tworzymy indeks bloków najstarszej pełnej kopii zapasowej i przenosimy z pojemności tir tylko brakujące bloki. W przedstawionym przypadku, aby rehyratować FullBackup1.vbk zgodnie z indeksem rehyratacji, brakuje nam tylko bloku C, który zabieramy z pojemności tir. Jeśli jako pojemność tir występuje obiekt storage w chmurze, pozwala to zaoszczędzić ogromne pieniądze.

Można odnieść wrażenie, że ta technologia jest podobna do tej używanej w akceleratorach WAN, ale to tylko pozory. W akceleratorach dokonuje się globalnej deduplikacji, natomiast tutaj wykorzystywana jest lokalna w obrębie każdego pliku w określonym ofsecie. Dzieje się tak z powodu różnicy w rozwiązywanych zadaniach: musimy kopiować duże pliki pełnych kopii zapasowych, a z naszych badań wynika, że nawet jeśli między nimi minie dłuższy czas, taki algorytm deduplikacji daje lepsze rezultaty.

Ale więcej indeksów bogu indeksów! Jest jeszcze indeks do przywracania danych! Gdy uruchamiamy przywracanie maszyny znajdującej się w kapacito tir, odczytujemy tylko unikalne bloki danych, których nie ma w performance tir.

Jak to się stało

Na tym kończymy naszą wprowadzenie. Jest ono dość szczegółowe, ale, jak wspomniano wcześniej, bez tych szczegółów nie można wyjaśnić, jak działają nowe funkcje. Dlatego bez zbędnych wstępów przechodzimy do pierwszego.

Tryb kopiowania

W dużej mierze oparty na istniejących technologiach, jednak niesie ze sobą zupełnie inną logikę użytkowania.

Celem tego trybu jest zapewnienie, że wszystkie dane znajdujące się w lokalnym ekstensie mają kopię w kapacito tir.

Porównując bezpośrednio tryby Move i Copy, otrzymujemy następujące wyniki:

Można przesuwać tylko zapieczętowany łańcuch. W przypadku trybu kopiowania przewożone jest absolutnie wszystko, niezależnie od tego, co dzieje się w zadaniu backupowym.
Przesunięcie następuje, gdy pliki opuszczają granice okna operacyjnego kopii zapasowej, natomiast kopiowanie uruchamia się od razu, jak tylko pojawia się plik kopii zapasowej.
Śledzenie nowych danych do kopiowania odbywa się na bieżąco, natomiast dla przesunięcia było uruchamiane co 4 godziny.

W omawianiu nowego trybu proponuję przechodzić od prostych przykładów do bardziej złożonych.

W najprostszej sytuacji po prostu pojawiają się nowe pliki z inkrementami, a my po prostu kopiujemy je do kapacito tir. Niezależnie od tego, jaki tryb jest używany w zadaniu backupowym, niezależnie od tego, do której części łańcucha należy, niezależnie od tego, czy nasze okno operacyjne wygasło. Po prostu wzięliśmy i skopiowaliśmy.

Proces, który za tym stoi, to nadal odwodnienie w sposób opisany powyżej. W trybie kopiowania również śledzi, abyśmy nie kopiowali bloków, które już znajdują się w naszym magazynie. Jedyna różnica polega na tym, że w trybie przenoszenia zastępowaliśmy rzeczywiste pliki plikami zastępczymi, a tutaj niczego nie dotykamy i zostawiamy wszystko jak jest. W pozostałych kwestiach to dokładnie taki sam wskaźnik odwodnienia, który stara się oszczędzać Twoje pieniądze i czas.

Pojawia się pytanie — jeśli spojrzymy na interfejs, to istnieje możliwość wyboru obu opcji jednocześnie. Jak będzie działać taki tryb połączenia?

Przejdźmy do sedna.

Standardowo: tworzony jest plik kopii zapasowej i od razu jest kopiowany. Tworzony jest do niego inkrement i również jest kopiowany. Tak dzieje się do momentu, w którym zdajemy sobie sprawę, że pliki wyszły z naszego okna operacyjnego i pojawił się zapieczętowany łańcuch. W tym momencie wykonujemy operację odwodnienia i zastępujemy te pliki plikami zastępczymi. Oczywiście, ponownie nie kopiujemy do capacity tier.

Za całą tę pasjonującą logikę odpowiada zaledwie jedna opcja w interfejsie: Copy backups to object storage as soon as they are created.

A po co nam ten tryb Copy?

Jeszcze lepiej przeformułować pytanie — przed jakimi ryzykami się zabezpieczamy za jego pomocą? Jaką problematykę on nam pomaga rozwiązać?

Odpowiedź jest oczywista: oczywiście, że to odzyskiwanie danych. Jeśli mamy na obiektowym magazynie pełną kopię lokalnych danych, to nieważne, co się stanie z naszym środowiskiem produkcyjnym, zawsze możemy przywrócić dane z plików znajdujących się w warunkowym Amazonie.

Dlatego przejdźmy przez możliwe scenariusze, od najprostszych do bardziej skomplikowanych.

Najprostsza katastrofa, która może nas spotkać, to niedostępność jednego z plików w łańcuchu kopii zapasowych.

Bardziej smutna historia — jeden z fragmentów naszego repozytorium SOBR uległ awarii.

Jeszcze gorzej, gdy całe repozytorium SOBR stało się niedostępne, ale działa capacity tier.
A najgorzej — to gdy umiera serwer kopii zapasowej i twoim pierwszym pragnieniem jest spróbować dotrzeć do kanadyjskiej granicy w dziesięć minut.

A teraz przeanalizujmy każdą sytuację osobno.

Kiedy straciliśmy jeden (a nawet kilka) plików kopii zapasowej, wystarczy uruchomić proces skanowania repozytorium, a utracony plik zostanie zastąpiony plikiem pustym. A dzięki procesowi rehydratacji (o którym mówiono na początku artykułu) użytkownik będzie mógł pobrać dane z pojemnika do lokalnego przechowywania.

Teraz sytuacja jest trudniejsza. Załóżmy, że nasz SOBR składa się z dwóch ekstentów działających w trybie Performance, co oznacza, że nasze pliki .vbk i .vib są rozmieszczone po nich dość nierównomiernie. I w pewnym momencie jeden z ekstentów staje się niedostępny, a użytkownik pilnie musi przywrócić maszynę, której część danych znajduje się właśnie na tym ekstencie.

Użytkownik uruchamia kreator przywracania, wybiera punkt, do którego chce przywrócić, a kreator w trakcie pracy zdaje sobie sprawę, że nie ma lokalnie wszystkich niezbędnych danych do przywrócenia, dlatego należy je pobrać z pojemnika. Przy tym bloki, które pozostały w lokalnym przechowywaniu, nie będą pobierane z chmury. Dzięki indeksowi restore (tak, o nim też mówiono na początku artykułu).

Podtyp tej sytuacji — cały repozytorium SOBR stało się niedostępne. W takim przypadku nie mamy czego kopiować z lokalnych magazynów i wszystkie bloki są pobierane z chmury.

A najciekawsza sytuacja — serwer kopii zapasowych umarł. Są dwie możliwości: admin jest mądry i robił kopie zapasowe konfiguracji, albo admin sam sobie zgotował zło i nie robił kopii zapasowej konfiguracji.

W pierwszym przypadku wystarczy gdzieś wdrożyć czystą instalację VBR i przywrócić jego bazę z kopii zapasowej standardowymi środkami. Na zakończenie tego procesu wszystko wróci do normy. Można również przywrócić według jednego z powyższych scenariuszy.

Jednak jeśli administrator jest sam sobie wrogiem lub backup konfiguracji również napotkał mityczną niepowodzenie, to nawet tutaj nie zostawimy go na pastwę losu. W tym celu wprowadziliśmy nową procedurę, która nazywa się Import Object Storage. Umożliwia ona pominięcie ręcznego procesu przywracania repozytorium SOBR oraz dołączenia do niego pojemności tą z późniejszym reskanowaniem, a po prostu dodać storage obiektowy w interfejsie wima i uruchomić procedurę Import Storage Repository. Jedyną rzeczą, która może stanąć na drodze między wami a waszymi backupami, jest prośba o wprowadzenie hasła, jeśli wasze kopie zapasowe były szyfrowane.

Na tym kończymy temat Trybu Kopiowania, a teraz przechodzimy do

Tryb Zwycięski

Główna idea polega na tym, że na wybranym rozszerzeniu repozytorium SOBR nie mogą pojawiać się nowe kopie zapasowe. Do wersji v10 mieliśmy tylko Tryb Utrzymania, który całkowicie zabraniał jakiejkolwiek pracy z repozytorium. Taki hardkorowy tryb wyłączenia przechowalni z pracy, gdzie dostępny był tylko przycisk Ewakuacji, który jednorazowo przenosił kopie zapasowe do innego rozszerzenia.

A Tryb Zwycięski to swego rodzaju “łagodna” wersja: zabraniając tworzenia nowych kopii zapasowych i stopniowo usuwając stare zgodnie z wybraną retencją, ale w tym procesie nie tracimy możliwości przywracania z przechowywanych punktów. Bardzo przydatna rzecz, gdy kończy się czas życia sprzętu i trzeba go wymienić lub po prostu zwolnić na coś ważniejszego, a przenoszenie wszystkiego naraz jest niemożliwe lub nie można usunąć.

W związku z tym zasada działania jest dość prosta: trzeba zabronić wszystkich operacji zapisu (pojawianie się nowych danych), pozostawiając odczyty (przywrócenia) i usuwanie (retencję).

Oba tryby można używać jednocześnie, tylko trzeba pamiętać, że Tryb Utrzymania ma wyższy priorytet.

Jako przykład rozważmy SOBR składający się z dwóch rozszerzeń. Załóżmy, że przez pierwsze cztery dni tworzone były kopie zapasowe w trybie Forward Forever Incremental, a potem zamykamy rozszerzenie. To prowadzi do tego, że inicjujemy stworzenie nowego aktywnego pełnego na drugim dostępnym rozszerzeniu. Jeśli nasza retencja wynosi cztery, to gdy cały łańcuch znajdujący się na zamkniętym rozszerzeniu przekroczy jego granice, może być z czystym sumieniem usunięty.

Są sytuacje, kiedy usunięcie następuje wcześniej. Na przykład, podczas Forward incremental z okresowymi pełnymi kopami. Jeśli przez pierwsze dwa dni tworzyliśmy pełne kopie zapasowe, a w czwartek postanawiamy zablokować repozytorium, to w piątek, kiedy powstanie nowa pełna kopia, plik z poniedziałku zostanie usunięty, ponieważ do tego punktu nie ma zależności. Sam punkt nie zależy od nikogo. Następnie czekamy, aż zostaną utworzone cztery punkty na dostępnym zakresie i usuwamy pozostałe trzy, które nie mogą być usunięte niezależnie od siebie.

Prościej sprawa wygląda z Reverse Incremental. W nim najstarsze punkty nie zależą od niczego i mogą być swobodnie usunięte. Dlatego, gdy tylko zostanie utworzony nowy plik .vbk na nowym zakresie, stare .vrb będą usuwane po jednym.

Nawiasem mówiąc, dlaczego za każdym razem tworzymy nowy .vbk: gdybyśmy go nie tworzyli, a kontynuowali starą serię przyrostów, stary .vbk zawiesiłby się na nieskończenie długi czas w każdym trybie, uniemożliwiając jego usunięcie. Dlatego podjęto decyzję, że gdy tylko zakres zostanie zablokowany, tworzymy pełną kopię zapasową na wolnym zakresie.

Sprawy są bardziej skomplikowane z kapacity tier.

Najpierw rozważmy tryb copy. Załóżmy, że przez cztery dni aktywnie tworzono kopie zapasowe, a następnie kapacity tier został zablokowany. Nie usuwamy nic, tylko cierpliwie czekamy na retencję, a potem usuwamy dane z kapacity tiera.

Podobnie sprawa wygląda w trybie move — czekamy na retencję, usuwamy stare w lokalnym magazynie, usuwamy to, co jest przechowywane w obiektowym składowisku.

Ciekawy przykład z Forever forward incremental. Ustawiamy retencję na trzy punkty i zaczynamy od poniedziałku tworzyć kopie zapasowe, które sumiennie kopiują się do chmury. Po zablokowaniu magazynu, kopie zapasowe nadal się tworzą, utrzymując trzy punkty, ale dane przechowywane w kapacity tier pozostają zależne i nie mogą być usunięte. Dlatego czekamy na czwartek, kiedy nasz .vbk wychodzi poza ramy retencji, i dopiero wtedy spokojnie usuwamy cały zapisany łańcuch.

I małe zastrzeżenie: wszystkie przykłady pokazane tutaj dotyczą jednej maszyny. Jeśli w kopii zapasowej jest ich kilka, to retencja będzie różna w zależności od tego, czy została wykonana Active Full, czy nie.

Na tym w zasadzie wszystko. Przechodzimy do najtrudniejszej funkcji —

Immutability

Jak w przypadku wcześniejszych punktów, na początku omówmy, jaki problem rozwiązuje ta funkcja. Gdy tylko przesyłamy nasze kopie zapasowe gdzieś na przechowanie, pojawia się silna potrzeba zapewnienia ich bezpieczeństwa, czyli fizycznego zakazu ich usuwania oraz jakiejkolwiek modyfikacji w trakcie określonego okresu retencji. W tym także przez administratorów, również pod ich kontami roota. Pozwala to chronić je przed przypadkowym lub zamierzonym uszkodzeniem. Osoby pracujące z AWS mogły spotkać się z podobną funkcją pod nazwą Object Lock.

Teraz omówimy tryb w ogólnych słowach, a potem zagłębimy się w szczegóły. W naszym przykładzie Immutability będzie włączony dla naszego pojemności tira z retencją wynoszącą cztery dni. A w kopii zapasowej włączono tryb Copy.

Immutability nie współdziała w żaden sposób z ogólną retencją. Na przykład, nie dodaje dodatkowych punktów ani nic podobnego. Po prostu przez cztery dni człowiek nie może usunąć plików kopii zapasowych. Jeżeli w poniedziałek wykonamy kopię zapasową, to usunięcie jej pliku będzie możliwe dopiero w piątek.

Wszystkie wcześniej omówione koncepcje dehydratacji, indeksów i metadanych nadal działają dokładnie tak samo. Ale z jednym zastrzeżeniem — blok wystawiany jest nie tylko dla danych, ale i dla metadanych. Zostało to zrobione na wypadek, gdyby podstępny przestępca postanowił usunąć naszą bazę metadanych, aby bloki z danymi nie zamieniły się w bezużyteczną binarną papkę.

I teraz nastał doskonały moment na wyjaśnienie naszej technologii generowania bloków. Albo block generation. W tym celu rozważmy sytuację, która doprowadziła do jej powstania.

We take a timeline of six days and mark the expected expiration time of immutability at the bottom. On the first day, we create a file consisting of data block a and its metadata. If immutability is set for three days, it is logical to assume that on the fourth day the data will be unlocked and deleted. On the second day, we will add a new file2 consisting of block b with the same settings. Block a should still be deleted on the fourth day. But on the third day, something terrible happens — a file File3 is created, consisting of a new block d and a reference to the old block a. This means that for block a its immutability flag must be reset for a new term, which is postponed to the sixth day. And here arises the problem — in real backups of such blocks, an enormous amount is generated. To extend their immutability period, it is necessary to make a huge number of requests each time. And in fact, this will be an almost endless daily process, as there is a high probability that we will find large batches of deduplicated blocks with each copy. And what does a large number of requests mean for object storage providers? Right! A huge bill at the end of the month.

To avoid charging my valued clients an excessive amount for no reason, a mechanism called block generation was devised. This is an additional period that we add to the specified immutability period. In the example below, this period equals two days. But this is just for illustration. In reality, a specific formula is used that provides approximately ten additional days for a monthly lock.

Przyjrzymy się tej samej sytuacji, ale z generowaniem bloków. Tworzymy w pierwszy dzień file1 z bloku a i metadanych. Sumujemy okresy generacji i immutability — oznacza to, że możliwość usunięcia pliku będzie na szósty dzień. Jeśli w drugim dniu stworzymy File2, składający się z bloku b i odnośnika do bloku a, to przewidywana data usunięcia nie zmieni się. Pozostaje na szósty dzień. W ten sposób staramy się zaoszczędzić pieniądze na liczbie zapytań. Jedyną sytuacją, w której termin może być przesunięty, jest upływ okresu generacji. To znaczy, jeśli trzeciego dnia nowy File3 będzie zawierać odnośnik do bloku a, to zostanie dodana generacja 2, ponieważ Gen1 już wygasła. A przewidywana data usunięcia bloku a przesunie się na ósmy dzień. Pozwoli to drastycznie zmniejszyć liczbę zapytań o przedłużenie czasu życia zduplikowanych bloków, co oszczędza mnóstwo pieniędzy dla klientów.

Technologia ta jest dostępna dla użytkowników S3 oraz sprzętu zgodnego z S3, którego producenci gwarantują, że ich implementacja nie różni się od amazonowej. Stąd odpowiedź na uzasadnione pytanie, dlaczego Azure nie jest wspierane — mają podobną funkcję, ale działa ona na poziomie kontenerów, a nie pojedynczych obiektów. Swoją drogą, w samym Amazonie object lock występuje w dwóch trybach: compliance i governance. W drugim przypadku pozostaje możliwość, aby najpotężniejszy administrator nad administratorami i root nad rootami, mimo object lock, jednak usunął dane. W przypadku compliance wszystko jest trwałe i nikt, nawet admini Amazona (według ich oficjalnych oświadczeń), nie ma możliwości usunięcia kopii zapasowych. Wspieramy właśnie ten tryb.