Warstwa pojemnościowa (lub jak ją nazywamy w Vimie – captir) pojawiła się już w czasach Veeam Backup and Replication 9.5 Update 4 pod nazwą Archive Tier. Ideą jest umożliwienie przenoszenia kopii zapasowych, które wypadły z tzw. okna przywracania operacyjnego, do magazynu obiektowego. Pomogło to zwolnić miejsce na dysku użytkownikom, którzy mieli go mało. Ta opcja została nazwana trybem ruchu.
Aby wykonać tę prostą (jak się wydaje) czynność wystarczyło spełnić dwa warunki: wszystkie punkty z przenoszonej kopii zapasowej muszą znajdować się poza granicami wspomnianego wyżej okna przywracania operacyjnego, które jest ustawiane jawnie w interfejsie użytkownika. Po drugie: łańcuch musi mieć tak zwaną „formę zapieczętowaną” (zamknięty łańcuch kopii zapasowych lub nieaktywny łańcuch kopii zapasowych). Oznacza to, że z biegiem czasu w tym łańcuchu nie zachodzą żadne zmiany.
Ale w VBR v10 koncepcja została uzupełniona o nowe funkcje - Copy Mode, Sealed Mode i pojawiła się rzecz o trudnej do wymówienia nazwie Immutability.
To są fascynujące rzeczy, o których dzisiaj porozmawiamy. Najpierw o tym, jak to działało w VBR9.5u4, a potem o zmianach w dziesiątej wersji.
I niech mi wybaczą zwolennicy czystego języka, ale jest zbyt wiele terminów, których nie da się przetłumaczyć.
Będzie więc tutaj mnóstwo anglicyzmów.
I mnóstwo gifów.
I zdjęcia.
- Bez najmniejszego żalu. Autor artykułu.
Tak jak było
Cóż, zacznijmy od analizy okna przywracania operacyjnego i zapieczętowanej kopii zapasowej (lub jak się je nazywa w dokumentacji Inactive Backup Chain). Bez ich zrozumienia dalsze wyjaśnienia nie będą możliwe.
Jak widać na obrazku, mamy coś w rodzaju łańcucha kopii zapasowych z blokami danych, który znajduje się na warstwie SOBR repozytorium, do którego podłączona jest warstwa pojemności. Nasze okno operacyjne dotyczące tworzenia kopii zapasowych wynosi trzy dni.
W związku z tym plik .vbk utworzony w poniedziałek pieczętuje poprzedni łańcuch, którego okno jest ustawione na trzy dni. A to oznacza, że można bezpiecznie rozpocząć transport na strzelnicę wszystkiego starszego niż te trzy dni.
Ale co dokładnie oznaczał uszczelniony łańcuch i co można było wysłać na strzelnicę pojemnościową w aktualizacji 4?
W przypadku Forward Inclusion oznaką zamknięcia łańcucha jest utworzenie nowej pełnej kopii zapasowej. Nie ma znaczenia, w jaki sposób zostanie uzyskana pełna kopia zapasowa: pod uwagę bierze się zarówno syntetyczne pełne, jak i aktywne pełne kopie zapasowe.
W przypadku Reverse są to wszystkie pliki, które nie wpadają do okna operacyjnego.
W przypadku przyrostu w przód z wycofywaniem są to wszystkie wycofywania i .vbk, jeśli w zakresie wydajności istnieje inny .vbk
Rozważmy teraz opcję pracy z łańcuchami kopii zapasowych. Przewożono tu wyłącznie przedmioty objęte zatrzymaniem GFS. Ponieważ wszystko przechowywane w nowszych łańcuchach kopii zapasowych można zmienić w taki czy inny sposób.
Zajrzyjmy teraz pod maskę. Tam następuje proces zwany odwodnieniem – pozostawienie pustych plików kopii zapasowych na danym obszarze i przeciągnięcie bloków z tych plików na pojemność strzelnicy. Aby zoptymalizować ten proces, stosuje się tzw. wskaźnik odwodnienia, który pozwala uniknąć kopiowania bloków, które zostały już skopiowane na strzelnicę pojemnościową.
Zobaczmy, jak to wygląda na przykładzie: Załóżmy, że mamy plik .vbk, który wyszedł z okna transakcji i należy do zapieczętowanego łańcucha. Oznacza to, że mamy pełne prawo przenieść go na strzelnicę pojemnościową. W momencie przenoszenia w obszarze pojemności i blokach przesyłanego pliku tworzony jest plik metadanych. Plik metadanych na poziomie łącza opisuje, z jakich bloków składa się nasz plik. W przypadku z obrazka nasz pierwszy plik składa się z bloków a, b, c, a metadane zawierają linki do tych bloków. Kiedy mamy drugi plik .vbk, gotowy do przeniesienia i składający się z bloków a, b i d, analizując wskaźnik odwodnienia, rozumiemy, że należy przenieść tylko blok d. A jego plik metadanych będzie zawierał łącza do dwóch poprzednich bloków i jednego nowego.
W związku z tym proces ponownego wypełniania tych pustych przestrzeni danymi nazywa się rehydratacją. Wykorzystuje już swój własny wskaźnik rehydratacji, oparty na najstarszym pliku .vbk dotyczącym lokalnego zakresu wydajności. Oznacza to, że jeśli użytkownik chce zwrócić plik ze strzelnicy pojemnościowej, najpierw tworzymy indeks bloków najstarszej pełnej kopii zapasowej i przesyłamy tylko brakujące bloki z galerii strzeleckiej pojemnościowej. W przypadku pokazanym na rysunku, aby nawodnić FullBackup1.vbk według wskaźnika nawodnienia potrzebny jest nam jedynie blok C, który pobieramy ze strzelnicy pojemnościowej. Jeśli obiekt w chmurze magazynowej służy jako strzelnica o pojemności, pozwala to zaoszczędzić ogromne kwoty pieniędzy.
Tutaj może się wydawać, że jest to technologia identyczna z tą stosowaną w akceleratorach WAN, ale tylko tak się wydaje. W akceleratorach deduplikacja ma charakter globalny; w tym przypadku deduplikacja lokalna jest stosowana w obrębie każdego pliku z określonym przesunięciem. Dzieje się tak ze względu na różnicę w rozwiązywanych zadaniach: tutaj musimy skopiować duże pliki pełnej kopii zapasowej i według naszych badań, nawet jeśli między nimi upłynie długi okres czasu, ten algorytm deduplikacji daje najlepszy wynik.
Ale więcej indeksów dla boga indeksów! Istnieje również indeks odzyskiwania danych! Kiedy zaczniemy przywracać maszynę znajdującą się na słupku pojemności, odczytamy tylko unikalne bloki danych, których nie ma na słupku wydajności.
Jak to się stało?
To wszystko, jeśli chodzi o część wprowadzającą. Jest dość szczegółowy, ale jak wspomniano powyżej, bez tych szczegółów nie będzie możliwe wyjaśnienie, jak działają nowe funkcje. Dlatego bez zbędnych ceregieli przejdźmy do pierwszego.
Tryb kopiowania
Opiera się w dużej mierze 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 zasięgu lokalnym mają kopię w obszarze pojemności.
Jeśli bezpośrednio porównasz tryby Przenieś i Kopiuj, będzie to wyglądać następująco:
- Można przesuwać tylko uszczelniony łańcuch. W przypadku trybu kopiowania przesyłane jest absolutnie wszystko, niezależnie od tego, co dzieje się w zadaniu tworzenia kopii zapasowej.
- Przenoszenie jest uruchamiane, gdy pliki wykraczają poza granice okna kopii zapasowej, a kopiowanie jest uruchamiane, gdy tylko pojawi się plik kopii zapasowej.
- Monitoring nowych danych pod kątem kopiowania odbywa się stale, a w przypadku przenoszenia uruchamiany był raz na 4 godziny.
Rozważając nowy tryb, proponuję przejść od prostych przykładów do skomplikowanych.
W najczęstszym przypadku po prostu mamy nowe pliki z przyrostami i po prostu kopiujemy je na strzelnicę pojemnościową. Niezależnie od tego, jaki tryb zostanie zastosowany w zadaniu tworzenia kopii zapasowej, niezależnie od tego, czy należy ona do zapieczętowanej części łańcucha, czy nie, niezależnie od tego, czy nasze okno operacyjne wygasło. Po prostu to wzięli i skopiowali.
Proces, który za tym stoi, to nadal odwodnienie, jak opisano powyżej. W trybie kopiowania pilnuje również, aby nie kopiować bloków, które już znajdują się w naszej pamięci. Jedyna różnica polega na tym, że jeśli w trybie filmowym zastąpiliśmy prawdziwe pliki plikami fikcyjnymi, tutaj nie dotykamy ich w żaden sposób i zostawiamy wszystko tak, jak jest. W przeciwnym razie jest to dokładnie ten sam wskaźnik odwodnienia, który starannie stara się zaoszczędzić pieniądze i czas.
Powstaje pytanie – jeśli spojrzeć na interfejs użytkownika, istnieje możliwość wybrania obu opcji jednocześnie. Jak będzie działać taki tryb łączony?
Zrozummy to.
Początek jest standardowy: tworzony jest plik kopii zapasowej, który jest natychmiast kopiowany. Tworzony jest do niego przyrost, który również jest kopiowany. Dzieje się tak do momentu, kiedy zorientujemy się, że pliki opuściły nasze okno operacyjne i pojawił się zapieczętowany łańcuszek. W tym momencie wykonujemy operację odwadniania i zastępujemy te pliki plikami fikcyjnymi. Oczywiście nie kopiujemy już niczego na strzelnicę pojemnościową.
Cała ta fascynująca logika odpowiada za tylko jedno pole wyboru w interfejsie: Kopiuj kopie zapasowe do pamięci obiektowej zaraz po ich utworzeniu.
Dlaczego potrzebujemy tego trybu kopiowania?
Jeszcze lepiej sformułować pytanie w ten sposób: przed jakimi zagrożeniami chronimy się za jego pomocą? Jaki problem pomaga nam rozwiązać?
Odpowiedź jest oczywista: oczywiście jest to odzyskiwanie danych. Jeśli posiadamy pełną kopię danych lokalnych na nośniku obiektowym, to niezależnie od tego, co stanie się z naszym produktem, zawsze będziemy mogli przywrócić dane z plików znajdujących się w warunkowym Amazonie.
Przyjrzyjmy się więc możliwym scenariuszom, od najprostszego do bardziej złożonego.
Najprostszym nieszczęściem, jakie może spaść na naszą głowę, jest niedostępność jednego z plików w łańcuchu kopii zapasowych.
Smutniejsza historia jest taka, że zepsuł się jeden z elementów naszego repozytorium SOBR.
Jeszcze gorzej jest, gdy całe repozytorium SOBR stanie się niedostępne, ale strzelnica pojemnościowa działa.
I wszystko jest naprawdę źle - w tym momencie umiera serwer zapasowy i Twoim pierwszym pragnieniem jest próba dobiegnięcia w ciągu dziesięciu minut do granicy z Kanadą.
Przyjrzyjmy się teraz każdej sytuacji osobno.
Gdy utracimy jeden (a nawet kilka) plików kopii zapasowych, wystarczy, że uruchomimy proces ponownego skanowania repozytorium, a utracony plik zostanie zastąpiony plikiem fikcyjnym. Z kolei wykorzystując proces rehydratacji (o którym była mowa na początku artykułu) użytkownik będzie mógł pobrać dane z pojemności strzelnicy do lokalnego magazynu.
Teraz sytuacja jest bardziej skomplikowana. Załóżmy, że nasz SOBR składa się z dwóch zakresów działających w trybie Performance, co oznacza, że nasze pliki .vbk i .vib są rozłożone w nich w dość nierównej warstwie. W pewnym momencie jeden z zakresów staje się niedostępny i użytkownik musi pilnie przywrócić maszynę, której część danych leży właśnie w tym zakresie.
Użytkownik uruchamia kreator odzyskiwania, wybiera punkt, do którego chce przywrócić, a kreator podczas pracy dochodzi do wniosku, że nie ma wszystkich danych niezbędnych do odzyskania lokalnie i dlatego należy je pobrać z pamięci masowej Galeria. Jednocześnie bloki pozostające w pamięci lokalnej nie zostaną pobrane z chmury. Chwała indeksowi przywracania (tak, o nim też wspomniano na początku artykułu).
Podtypem tego przypadku jest niedostępność całego repozytorium SOBR. W tym przypadku nie mamy nic do kopiowania z lokalnej pamięci, a wszystkie bloki pobierane są z chmury.
A najciekawsza sytuacja jest taka, że serwer zapasowy padł. Są tu dwie opcje: administrator jest świetny i zrobił kopie zapasowe konfiguracji, a administrator sam jest złym Pinokio i nie zrobił kopii zapasowych konfiguracji.
W pierwszym przypadku wystarczy, że po prostu wdroży gdzieś czystą instalację VBR i przywróci jego bazę danych z kopii zapasowej standardowymi sposobami. Pod koniec tego procesu wszystko wróci do normy. Lub zostanie przywrócony zgodnie z jednym z powyższych scenariuszy.
Ale jeśli administrator jest albo swoim własnym wrogiem, albo kopia zapasowa konfiguracji również poniosła imponującą awarię, to nawet tutaj nie pozostawimy go na łasce losu. W tym przypadku wprowadziliśmy nową procedurę o nazwie Import Object Storage. Pozwala pominąć proces ręcznego odtwarzania repozytorium SOBR i dołączania do niego strzelnicy pojemnościowej z późniejszym ponownym skanowaniem, a po prostu dodać obiekt pamięci do interfejsu Vima i uruchomić procedurę Import Storage Repository. Jedyną rzeczą, która może stanąć na drodze między Tobą a Twoimi kopiami zapasowymi, jest prośba o podanie hasła, jeśli Twoje kopie zapasowe były zaszyfrowane.
Prawdopodobnie chodzi o tryb kopiowania i przechodzimy dalej
Tryb zamknięty
Główną ideą jest to, że nowe kopie zapasowe nie mogą pojawiać się w wybranym zakresie SOBR repozytorium. Przed v10 mieliśmy tylko Tryb Konserwacji, kiedy wszelka praca z repozytorium była całkowicie zabroniona. Rodzaj hardcorowego trybu zamykania magazynu, w którym dostępny jest tylko przycisk Ewakuuj, który jednorazowo przenosi kopie zapasowe w innym zakresie.
Tryb zapieczętowany jest rodzajem opcji „miękkiej”: zabraniamy tworzenia nowych kopii zapasowych i stopniowo usuwamy stare zgodnie z wybranym przechowywaniem, ale w tym procesie nie tracimy możliwości przywracania z przechowywanych punktów. Bardzo przydatna rzecz, gdy albo mamy jakiś sprzęt, którego żywotność dobiega końca i musimy go wymienić, albo po prostu potrzebujemy go zwolnić na coś ważniejszego, ale nie mamy gdzie go zabrać i przenieść wszystkiego na raz. Lub nie można go usunąć.
W związku z tym zasada działania jest dość prosta: należy zabronić wszelkich operacji zapisu (pojawienie się nowych danych), pozostawienia odczytu (przywrócenie) i usunięcia (zatrzymanie).
Obydwa tryby mogą być używane jednocześnie, należy jednak pamiętać, że konserwacja ma wyższy priorytet.
Jako przykład rozważmy SOBR składający się z dwóch zakresów. Załóżmy, że przez pierwsze cztery dni tworzyliśmy kopie zapasowe w trybie Forever Forever Inkrementalnym, a następnie pieczętujemy zakres, co prowadzi do tego, że inicjujemy tworzenie nowego aktywnego pełnego na drugim dostępnym zakresie. Jeżeli nasza retencja wynosi cztery, to gdy cały łańcuch znajdujący się na zapieczętowanym zasięgu przekroczy swoje granice, zostaje on z czystym sumieniem usunięty.
Są sytuacje, gdy usunięcie następuje wcześniej. Na przykład jest to przyrostowe forwardowanie z okresowymi uzupełnieniami. Jeśli przez pierwsze dwa dni tworzyliśmy pełne kopie zapasowe, a w czwartek zdecydujemy się na zapieczętowanie repozytorium, to w piątek, gdy zostanie utworzona nowa kopia zapasowa, plik z poniedziałku zostanie usunięty, ponieważ nie ma w tym zakresie żadnych zależności. A sam punkt nie zależy od nikogo. Następnie czekamy aż na dostępnym zakresie utworzą się cztery punkty i usuwamy pozostałe trzy, których nie da się usunąć niezależnie od siebie.
Sprawa jest prostsza dzięki odwrotnemu przyrostowi. W nim najstarsze punkty nie zależą od niczego i można je bezpiecznie usunąć. Dlatego też, gdy tylko nowy plik .vbk zostanie utworzony w nowym zakresie, stare pliki .vrb zostaną jeden po drugim usunięte.
Swoją drogą, po co za każdym razem tworzymy nowy plik .vbk: gdybyśmy go nie utworzyli, ale kontynuowali stary łańcuch przyrostów, to stary plik .vbk zawieszałby się na nieskończenie długi czas w dowolnym trybie, uniemożliwiając jego usunięcie. Dlatego zdecydowano, że jak tylko zakres zostanie zapieczętowany, utworzymy pełną kopię zapasową wolnego zakresu.
Sprawa się komplikuje w przypadku strzelnicy pojemnościowej.
Przyjrzyjmy się najpierw trybowi kopiowania. Załóżmy, że przez cztery dni aktywnie tworzyliśmy rezerwy, a następnie zamknięto pojemność strzelnicy. Niczego nie usuwamy, ale pokornie znosimy zatrzymanie, po czym usuwamy dane z pojemności strzelnicy.
Mniej więcej to samo dzieje się w trybie przenoszenia - czekamy na retusz, usuwamy stary w pamięci lokalnej, a usuwamy ten zapisany w pamięci obiektów.
Ciekawy przykład z przyrostowym forwardem Forever. Instalujemy retencję w trzech punktach i od poniedziałku zaczynamy robić kopie zapasowe, które są regularnie kopiowane do chmury. Po zamknięciu magazynu kopie zapasowe są nadal tworzone z zachowaniem trzech punktów, ale dane przechowywane na pasku pojemności pozostają zależne i nie można ich usunąć. Dlatego czekamy do czwartku, kiedy nasz .vbk wyjdzie poza retencję i dopiero wtedy spokojnie usuwamy cały zapisany łańcuch.
I małe zastrzeżenie: wszystkie przykłady pokazano na jednej maszynie. Jeśli masz ich kilka w kopii zapasowej, to ich retusz będzie się różnił w zależności od tego, czy wykonano Active Full, czy nie.
To w zasadzie wszystko, co na ten temat można powiedzieć. Przejdźmy więc do najbardziej hardcorowej funkcji -
Niezmienność
Podobnie jak w poprzednich punktach, pierwszą rzeczą jest to, jaki problem rozwiązuje ta funkcja. Gdy tylko przesyłamy gdzieś nasze kopie zapasowe do przechowywania, istnieje silna chęć zagwarantowania ich bezpieczeństwa, czyli fizycznego zakazu ich usuwania i jakiejkolwiek modyfikacji w trakcie danego przechowywania. W tym administratorzy, w tym na ich kontach root. Pozwala to zabezpieczyć je przed przypadkowym lub celowym uszkodzeniem. Każdy, kto pracuje z AWS, mógł natknąć się na podobną funkcję o nazwie Object Lock.
Przyjrzyjmy się teraz trybowi ogólnie, a następnie zagłębimy się w szczegóły. W naszym przykładzie niezmienność zostanie włączona dla naszej strzelnicy pojemnościowej z zachowaniem czterech dni. W kopii zapasowej włączony jest tryb kopiowania.
Niezmienność nie wpływa w żaden sposób na ogólne zachowanie. Na przykład nie dodaje dodatkowych punktów ani nic podobnego. Po prostu nikt nie może usunąć plików kopii zapasowych w ciągu czterech dni. Jeśli wykonasz kopię zapasową w poniedziałek, usunięcie jej pliku będzie możliwe dopiero w piątek.
Wszystkie wcześniej wyjaśnione koncepcje odwodnienia, indeksów i metadanych nadal działają dokładnie tak samo. Ale pod jednym warunkiem - blok jest ustawiony nie tylko na dane, ale także na metadane. Dzieje się tak na wypadek, gdyby przebiegły atakujący zdecydował się usunąć naszą bazę danych metadanych i zapobiec przekształceniu bloków danych w bezużyteczną papkę binarną.
Teraz jest świetny czas, aby wyjaśnić naszą technologię generowania bloków. Lub generowanie bloków. Aby to zrobić, rozważ sytuację, która doprowadziła do jego pojawienia się.
Przyjmijmy sześciodniową skalę czasową i poniżej zaznaczymy czas oczekiwanego wygaśnięcia niezmienności. Pierwszego dnia pobieramy i tworzymy plik składający się z bloku danych a i jego metadanych. Jeśli niezmienność jest ustawiona na trzy dni, logiczne jest założenie, że czwartego dnia dane zostaną odblokowane i usunięte. Drugiego dnia dodamy nowy plik2, składający się z bloku b z tymi samymi ustawieniami. Blok destylacyjny należy usunąć czwartego dnia. Ale trzeciego dnia dzieje się coś strasznego - tworzony jest plik File3, składający się z nowego bloku d i łącza do starego bloku a. Oznacza to, że dla bloku i jego flagi niezmienności należy ustawić nową datę, która zostaje przesunięta na szósty dzień. I tu pojawia się problem – w prawdziwych kopiach zapasowych takich bloków jest ogromna ilość. Aby przedłużyć okres ich niezmienności, trzeba za każdym razem składać ogromną liczbę żądań. W rzeczywistości będzie to niemal niekończący się codzienny proces, ponieważ z dużym prawdopodobieństwem w każdej kopii znajdziemy ogromne stosy deduplikowanych bloków. Co oznacza duża liczba żądań od dostawców obiektowych magazynów danych? Prawidłowy! Ogromny rachunek na koniec miesiąca.
Aby nie narażać Twoich ulubionych klientów na znaczne pieniądze, wynaleziono mechanizm generowania bloków. Jest to dodatkowy okres, który doliczamy do ustawionego okresu niezmienności. W poniższym przykładzie okres ten wynosi dwa dni. Ale to tylko przykład. W rzeczywistości stosują własną formułę, która daje około dziesięciu dodatkowych dni podczas miesięcznej blokady.
Rozważmy w dalszym ciągu tę samą sytuację, ale z generacją bloków. Pierwszego dnia tworzymy plik 1 z bloku a i metadanych. Sumujemy okres generacji i niezmienność - oznacza to, że możliwość usunięcia pliku będzie szóstego dnia. Jeśli drugiego dnia utworzymy Plik2, składający się z bloku b i odnośnika do bloku a, to z oczekiwaną datą usunięcia nic się nie stanie. Stała tak, jak szóstego dnia. W ten sposób staramy się oszczędzać na liczbie żądań. Przesunięcie terminu możliwe jest jedynie wtedy, gdy upłynął okres generacji. Oznacza to, że jeśli trzeciego dnia nowy plik 3 będzie zawierał łącze do bloku a, wówczas dodana zostanie generacja 2, ponieważ Gen1 już wygasła. A przewidywany termin usunięcia bloku a przesunie się na dzień ósmy. Pozwala nam to radykalnie zmniejszyć liczbę żądań wydłużenia czasu życia deduplikowanych bloków, co pozwala klientom zaoszczędzić mnóstwo pieniędzy.
Sama technologia dostępna jest dla użytkowników sprzętu kompatybilnego z S3 i S3, których producenci gwarantują, że ich wdrożenie nie odbiega od Amazona. Stąd odpowiedź na zasadne pytanie, dlaczego Azure nie jest obsługiwany – mają podobną funkcję, ale działają na poziomie kontenerów, a nie poszczególnych obiektów. Nawiasem mówiąc, sam Amazon ma blokadę obiektów w dwóch trybach: zgodności i zarządzania. W drugim przypadku istnieje możliwość, że największy administrator nad administratorami i root nad rootami, pomimo blokady obiektu, nadal usunie dane. W przypadku zgodności wszystko jest mocno przybite i nikt nie może usunąć kopii zapasowych. Nawet administratorzy Amazona (według ich oficjalnych wypowiedzi). To jest tryb, który wspieramy.
I jak zwykle kilka przydatnych linków:
- Про w każdym szczególe.
- Wszystkie informacje dot w najlepszym wydaniu
- О szczegółowo
Źródło: www.habr.com