Jak GitLab pomaga tworzyć kopie zapasowe dużych magazynów NextCloud

Hej Habra!

Dziś chcę opowiedzieć o naszych doświadczeniach w automatyzacji tworzenia kopii zapasowych dużych zbiorów danych z magazynów Nextcloud w różnych konfiguracjach. Pracuję jako stacja obsługi w Molniya AK, gdzie zajmujemy się zarządzaniem konfiguracją systemów informatycznych, a do przechowywania danych służy Nextcloud. W tym o rozproszonej strukturze, z redundancją.

Problemy wynikające z cech instalacji polegają na tym, że istnieje dużo danych. Wersjonowanie dostarczane przez Nextcloud, redundancja, przyczyny subiektywne i inne tworzą wiele duplikatów.

prehistoria

Podczas administrowania Nextcloud pojawia się problem zorganizowania skutecznej kopii zapasowej, która musi być zaszyfrowana, ponieważ dane są cenne.

Oferujemy możliwość przechowywania kopii zapasowych u nas lub u klienta na odrębnych maszynach niż Nextcloud, co wymaga elastycznego, zautomatyzowanego podejścia do administracji.

Jest wielu klientów, wszyscy z różnymi konfiguracjami, wszyscy na własnych stronach i z własnymi cechami. Jest to standardowa technika, gdy cała witryna należy do Ciebie, a kopie zapasowe są tworzone z koron; nie pasuje.

Najpierw spójrzmy na dane wejściowe. Potrzebujemy:

• Skalowalność w zakresie jednego lub kilku węzłów. W przypadku dużych instalacji używamy minio jako magazynu.
• Dowiedz się o problemach z wykonywaniem kopii zapasowych.
• Musisz przechowywać kopię zapasową u swoich klientów i/lub u nas.
• Rozwiązuj problemy szybko i łatwo.
• Klienci i instalacje bardzo się od siebie różnią - nie da się osiągnąć jednolitości.
• Szybkość odzyskiwania powinna być minimalna w dwóch scenariuszach: pełne odzyskiwanie (katastrofa), jeden folder usunięty przez pomyłkę.
• Wymagana jest funkcja deduplikacji.

Aby rozwiązać problem zarządzania kopiami zapasowymi, zainstalowaliśmy GitLab. Więcej szczegółów według ataku.

Oczywiście nie jesteśmy pierwsi, którzy rozwiązali taki problem, ale wydaje nam się, że nasze praktyczne, ciężko nabyte doświadczenia mogą być ciekawe i jesteśmy gotowi się nimi podzielić.

Ponieważ nasza firma ma politykę open source, szukaliśmy rozwiązania open source. Z kolei dzielimy się naszymi osiągnięciami i publikujemy je. Na przykład na GitHubie jest nasza wtyczka do Nextcloud, które udostępniamy Klientom, zwiększając bezpieczeństwo danych w przypadku ich przypadkowego lub celowego usunięcia.

Narzędzia do tworzenia kopii zapasowych

Poszukiwanie metod rozwiązania rozpoczęliśmy od wyboru narzędzia do tworzenia kopii zapasowych.

Zwykły tar + gzip nie działa dobrze - dane są zduplikowane. Przyrost często zawiera bardzo niewiele rzeczywistych zmian, a duża część danych w pojedynczym pliku jest powtarzana.
Jest jeszcze jeden problem – redundancja rozproszonego przechowywania danych. Używamy minio i jego dane są w zasadzie zbędne. Albo musiałeś zrobić kopię zapasową przez samo minio - załaduj ją i wykorzystaj wszystkie odstępniki pomiędzy systemem plików, a co nie mniej ważne, istnieje ryzyko zapomnienia o niektórych segmentach i metainformacjach. Lub użyj deduplikacji.

Narzędzia do tworzenia kopii zapasowych z duplikacją są dostępne w wersji open source (na Habré były Artykuł na ten temat) i naszymi finalistami byli Borg и Spokojny. Nasze porównanie obu aplikacji znajduje się poniżej, ale na razie opowiemy, jak zorganizowaliśmy cały program.

Zarządzanie kopiami zapasowymi

Borg i Restic są dobre, ale żaden z produktów nie ma scentralizowanego mechanizmu kontroli. Na potrzeby zarządzania i kontroli wybraliśmy narzędzie, które już wdrożyliśmy, bez którego nie wyobrażamy sobie naszej pracy, w tym automatyzacji - jest to dobrze znany CI/CD - GitLab.

Pomysł jest następujący: gitlab-runner instalowany jest na każdym węźle przechowującym dane Nextcloud. Runner uruchamia skrypt zgodnie z harmonogramem, który monitoruje proces tworzenia kopii zapasowej i uruchamia Borg lub Restic.

Co otrzymaliśmy? Informacje zwrotne z wykonania, wygodna kontrola nad zmianami, szczegóły w przypadku błędu.

tutaj jest tutaj na GitHubie zamieściliśmy przykłady skryptu do różnych zadań i ostatecznie dołączyliśmy go do kopii zapasowej nie tylko Nextcloud, ale także wielu innych usług. Jest tam również harmonogram, jeśli nie chcesz go konfigurować ręcznie (a my nie chcemy) i .gitlab-ci.yml

Nie ma jeszcze możliwości zmiany limitu czasu CI/CD w API Gitlab, ale jest on niewielki. Trzeba to zwiększyć, powiedzmy 1d.

GitLab na szczęście potrafi uruchomić się nie tylko zgodnie z zatwierdzeniem, ale tylko zgodnie z harmonogramem, właśnie tego nam potrzeba.

Teraz o skrypcie opakowania.

Ustawiamy następujące warunki dla tego skryptu:

• Należy go uruchomić zarówno przez biegacza, jak i ręcznie z konsoli z tą samą funkcjonalnością.
• Muszą istnieć procedury obsługi błędów:
• kod powrotu.
• wyszukaj ciąg w dzienniku. Przykładowo dla nas błędem może być komunikat, którego program nie traktuje jako krytyczny.
• Przekroczono limit czasu przetwarzania. Czas realizacji musi być rozsądny.
• Potrzebujemy bardzo szczegółowego dziennika. Ale tylko w przypadku błędu.
• Przed uruchomieniem przeprowadza się także szereg testów.
• Małe bonusy dla wygody, które uznaliśmy za przydatne podczas procesu wsparcia:
• Początek i koniec są rejestrowane w dzienniku syslog maszyny lokalnej. Pomaga to połączyć błędy systemowe i operację tworzenia kopii zapasowych.
• Część dziennika błędów, jeśli istnieje, jest wyprowadzana na standardowe wyjście, cały dziennik jest zapisywany w oddzielnym pliku. Wygodnie jest od razu spojrzeć na CI i ocenić błąd, jeśli jest trywialny.
• Tryby debugowania.

Pełny dziennik jest zapisywany jako artefakt w GitLabie; jeśli nie wystąpi żaden błąd, dziennik zostanie usunięty. Skrypt piszemy w bashu.

Chętnie rozważymy wszelkie sugestie i uwagi dotyczące open source - zapraszamy.

Jak to działa

W węźle zapasowym uruchamiany jest moduł uruchamiający z executorem Bash. Według harmonogramu zadanie CI/CD jest uruchamiane w specjalnej rzepie. Biegacz uruchamia uniwersalny skrypt wrapperowy do takich zadań, sprawdza ważność repozytorium kopii zapasowych, punkty montowania i wszystko, czego potrzebujemy, a następnie tworzy kopię zapasową i czyści stare. Gotowa kopia zapasowa jest wysyłana do S3.

Pracujemy według tego schematu – jest to zewnętrzny dostawca AWS lub jego rosyjski odpowiednik (jest szybszy i dane nie opuszczają Federacji Rosyjskiej). Lub w tym celu instalujemy dla klienta osobny klaster minio na jego stronie. Zwykle robimy to ze względów bezpieczeństwa, gdy klient nie chce, aby dane w ogóle opuściły jego obwód.

Nie korzystaliśmy z funkcji wysyłania kopii zapasowej przez ssh. Nie zwiększa to bezpieczeństwa, a możliwości sieciowe dostawcy S3 są znacznie wyższe niż w przypadku naszej jednej maszyny ssh.

Aby chronić komputer lokalny przed hakerem, ponieważ może on usunąć dane na S3, musisz włączyć wersjonowanie.
Kopia zapasowa zawsze szyfruje kopię zapasową.

Borg ma tryb niezaszyfrowany none, ale zdecydowanie nie zalecamy jego włączania. W tym trybie nie tylko nie będzie szyfrowania, ale suma kontrolna tego, co jest zapisywane, nie jest obliczana, co oznacza, że ​​integralność można sprawdzić jedynie pośrednio, za pomocą indeksów.

Oddzielny program planujący sprawdza kopie zapasowe pod kątem integralności indeksów i zawartości. Kontrola jest powolna i długa, dlatego przeprowadzamy ją osobno raz w miesiącu. Może to zająć kilka dni.

Przeczytaj w języku rosyjskim

Główne funkcje

• prepare szkolenie
• testcheck kontrola gotowości
• maincommand podstawowy zespół
• forcepostscript funkcja wykonywana na końcu lub przez błąd. Używamy go do odmontowania partycji.

Funkcje serwisowe

• cleanup Rejestrujemy błędy lub usuwamy plik dziennika.
• checklog przeanalizuj dziennik pod kątem wystąpienia linii z błędem.
• ret obsługa wyjścia.
• checktimeout sprawdź limit czasu.

Środowisko

• VERBOSE=1 Błędy wyświetlamy natychmiast na ekranie (stdout).
• SAVELOGSONSUCCES=1 zapisz dziennik po pomyślnym zakończeniu.
• INIT_REPO_IF_NOT_EXIST=1 Utwórz repozytorium, jeśli nie istnieje. Domyślnie wyłączone.
• TIMEOUT maksymalny czas operacji głównej. Na końcu możesz ustawić go jako „m”, „h” lub „d”.

Tryb przechowywania starych kopii. Domyślny:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Zmienne wewnątrz skryptu

• ERROR_STRING — ciąg znaków dla dziennika odprawy pod kątem błędów.
• EXTRACT_ERROR_STRING — wyrażenie pokazujące ciąg znaków w przypadku błędu.
• KILL_TIMEOUT_SIGNAL — sygnał zabicia w przypadku przekroczenia limitu czasu.
• TAIL — ile ciągów znaków zawiera błędy na ekranie.
• COLORMSG — kolor wiadomości (domyślnie żółty).

Ten skrypt, który nazywa się wordpress, ma nazwę warunkową, a jego sztuczka polega na tym, że tworzy również kopię zapasową bazy danych mysql. Oznacza to, że można go używać w jednowęzłowych instalacjach Nexcloud, w których można również tworzyć kopie zapasowe bazy danych. Wygoda polega nie tylko na tym, że wszystko jest w jednym miejscu, ale także zawartość bazy danych jest zbliżona do zawartości plików, ponieważ różnica czasu jest minimalna.

Restic kontra Borg

Istnieją również porównania Borga i Restica tutaj, na Habréi nie mieliśmy za zadanie zrobić kolejnego, ale własnego. Ważne było dla nas jak to będzie wyglądało na naszych danych, z naszą specyfiką. Przynosimy je.

Nasze kryteria wyboru, oprócz tych już wymienionych (deduplikacja, szybkie odzyskiwanie itp.):

• Opór wobec niedokończonej pracy. Sprawdź zabicie -9.
• Rozmiar dysku.
• Zapotrzebowanie na zasoby (procesor, pamięć).
• Rozmiar przechowywanych obiektów BLOB.
• Praca z S3.
• Sprawdzanie integralności.

Do testów wzięliśmy jednego klienta z rzeczywistymi danymi i łącznym rozmiarem 1,6 TB.
Regulamin.

Borg nie wie jak pracować bezpośrednio z S3, więc zamontowaliśmy dysk jako bezpiecznik, via głupkowaty. Restic wysłał to do samego S3.

Goofys działa bardzo szybko i dobrze, i są moduł pamięci podręcznej dyskuco jeszcze bardziej przyspiesza pracę. Jest w fazie beta i szczerze mówiąc, zawiesiliśmy się z utratą danych podczas testów (innych). Ale wygodą jest to, że sama procedura tworzenia kopii zapasowej nie wymaga dużo czytania, ale głównie pisania, dlatego używamy pamięci podręcznej tylko podczas sprawdzania integralności.

Aby zmniejszyć wpływ sieci, skorzystaliśmy z lokalnego dostawcy - Yandex Cloud.

Wyniki testów porównawczych.

• Obydwa zabójstwa -9 i ponowne uruchomienie zakończyły się sukcesem.
• Rozmiar dysku. Borg może kompresować, więc wyniki są zgodne z oczekiwaniami.

Kopia zapasowa
Rozmiar

Borg
562Gb

Spokojny
628Gb

• Według procesora
  Sam Borg zużywa niewiele, przy domyślnej kompresji, ale należy to ocenić łącznie z procesem głupkowatym. W sumie są one porównywalne i wykorzystują około 1,2 rdzeni na tej samej testowej maszynie wirtualnej.
• Pamięć. Restic zajmuje około 0,5 GB, Borg około 200 MB. Ale to wszystko jest nieistotne w porównaniu z pamięcią podręczną plików systemowych. Dlatego wskazane jest przydzielenie większej ilości pamięci.
• Różnica w wielkości kropelek była uderzająca.

Kopia zapasowa
Rozmiar

Borg
około 500MB

Spokojny
około 5MB

• Doświadczenie Restica z S3 jest doskonałe. Praca z Borgiem za pośrednictwem Goofys nie rodzi żadnych pytań, ale zauważono, że zaleca się wykonanie operacji umount po zakończeniu tworzenia kopii zapasowej, aby całkowicie zresetować pamięć podręczną. Osobliwością S3 jest to, że niedopompowane fragmenty nigdy nie zostaną wysłane do wiadra, co oznacza, że ​​niekompletnie wypełnione dane prowadzą do poważnych uszkodzeń.
• Kontrola integralności działa dobrze w obu przypadkach, ale prędkość znacznie się różni.
  Restyczny 3,5 godzin.
  Borg, z pamięcią podręczną plików SSD 100 GB – 5 godzin.W przybliżeniu taki sam wynik prędkości, jeśli dane znajdują się na dysku lokalnym.
  Borg czyta bezpośrednio z S3 bez pamięci podręcznej 33 godzin. Potwornie długi.

Najważniejsze jest to, że Borg może kompresować i ma większe obiekty blob, co sprawia, że ​​przechowywanie danych i operacje GET/PUT w S3 są tańsze. Dzieje się to jednak kosztem bardziej złożonej i wolniejszej weryfikacji. Jeśli chodzi o szybkość odzyskiwania, nie zauważyliśmy żadnej różnicy. Restic wykonuje kolejne kopie zapasowe (po pierwszej) nieco dłużej, ale nie znacząco.

Ostatnią kwestią przy wyborze była wielkość społeczności.

I wybraliśmy Borg.

Kilka słów o kompresji

Borg ma w swoim arsenale doskonały nowy algorytm kompresji - zstd. Jakość kompresji nie jest gorsza niż gzip, ale znacznie szybsza. I porównywalna pod względem szybkości do domyślnego lz4.

Na przykład zrzut bazy danych MySQL jest kompresowany dwa razy lepiej niż lz4 przy tej samej szybkości. Jednak doświadczenie z rzeczywistymi danymi pokazuje, że różnica we współczynniku kompresji węzła Nextcloud jest bardzo niewielka.

Borg ma raczej dodatkowy tryb kompresji - jeśli plik ma wysoką entropię, wówczas kompresja w ogóle nie jest stosowana, co zwiększa prędkość. Włączone przez opcję podczas tworzenia
-C auto,zstd
dla algorytmu zstd
Tak więc przy tej opcji, w porównaniu z domyślną kompresją, otrzymaliśmy
Odpowiednio 560 Gb i 562 Gb. Dane z powyższego przykładu, przypomnę, bez kompresji wynik to 628Gb. Wynik różnicy 2 GB nieco nas zaskoczył, ale myśleliśmy, że mimo wszystko go wybierzemy. auto,zstd.

Metoda weryfikacji kopii zapasowej

Według harmonogramu maszyna wirtualna jest uruchamiana bezpośrednio od dostawcy lub od klienta, co znacznie zmniejsza obciążenie sieci. Przynajmniej jest to tańsze niż samodzielne podnoszenie i generowanie ruchu.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

W ten sam sposób sprawdzamy pliki za pomocą programu antywirusowego (po fakcie). W końcu użytkownicy przesyłają różne rzeczy do Nextcloud i nie każdy ma program antywirusowy. Przeprowadzanie kontroli w momencie zalewania zajmuje zbyt dużo czasu i zakłóca prowadzenie działalności.

Skalowalność osiąga się poprzez uruchamianie modułów uruchamiających w różnych węzłach z różnymi znacznikami.
Nasz monitoring gromadzi statusy kopii zapasowych za pośrednictwem GitLab API w jednym oknie, dzięki czemu w razie potrzeby problemy są łatwo zauważalne i równie łatwo lokalizowane.

wniosek

Dzięki temu mamy pewność, że wykonujemy kopie zapasowe, że nasze kopie zapasowe są ważne, problemy z nimi powstające zajmują niewiele czasu i są rozwiązywane na poziomie administratora dyżurnego. Kopie zapasowe zajmują naprawdę mało miejsca w porównaniu do tar.gz czy Bacula.

Źródło: www.habr.com