Jak wykonać kopię zapasową Gitlab na dużą skalę?

Pytając wsparcie Gitlab, jak wykonać kopię zapasową o pojemności 3 TB na lokalnym Gitlab, odpowiadają, korzystając z naszego narzędzia, które tworzy tarball.

Wydaje mi się to niewłaściwe na wszystkich poziomach. Ten archiwum zawiera zrzut postgres, obrazy dokerów, dane repo, GIT LFS itp. Konfiguracja itd. Tworzenie kopii zapasowych TB danych statycznych wraz z bardzo dynamicznymi danymi KB nie jest właściwe. A potem pojawia się kwestia: chcemy tworzyć kopie zapasowe co godzinę.

Pytanie

Naprawdę chciałbym wiedzieć od innych, jak to robią, aby uzyskać spójną kopię zapasową.

ZFS w systemie Linux byłby dla mnie w porządku, jeśli jest to część rozwiązania.

linux backup postgresql zfs gitlab Sandra
źródło

Dlaczego to źle? Całkowicie wykonaj kopię zapasową Gitlab, aby go całkowicie przywrócić. Nie sądzę, że to źle. Oczywiście zajmuje dużo więcej miejsca niż powiedzmy, przyrostowe kopie zapasowe, ale ... nie dbałbym o rozmiar kopii zapasowej.

Lenniey

Posiadanie kopii zapasowej co godzinę nie jest niespotykane, ale nie można zrobić 3 TB w mniej niż godzinę z ich podejściem. A kopie zapasowe tylko na jeden dzień wyniosłyby ~ 100 TB, przy czym w danych może być tylko 10 MB zmian.

Sandra

OK, to inne pytanie, nie dotyczy ogólnie tworzenia kopii zapasowej, ale częstych kopii zapasowych.

Lenniey

W swoich oficjalnych dokumentach wspominają nawet o swojej metodzie jako powolnej i sugerują alternatywy:

If your GitLab server contains a lot of Git repository data you may find the GitLab backup script to be too slow. In this case you can consider using filesystem snapshots as part of your backup strategy.

nie mogę jednak mówić z doświadczenia. Ale być może wkrótce będę musiał dołączyć coś takiego ...

Lenniey

Gitlab ma opcje w pliku konfiguracyjnym i flagach kopii zapasowych, które pozwolą ci wykluczyć sekcje lub posunąć się do przechowywania obrazów i artefaktów w magazynie obiektów

ssube

Odpowiedzi:

Przez tak krótki czas między kopiami zapasowymi (1 godz.) Najlepiej jest polegać na migawce na poziomie systemu plików i send/recv obsłudze.

Jeśli korzystanie z ZoL nie stanowi problemu w twoim środowisku, zdecydowanie zalecamy jego użycie. ZFS to bardzo solidny system plików i naprawdę spodobają Ci się wszystkie oferowane przez niego dodatki (np. Kompresja). W połączeniu z sanoid/syncoid, może zapewnić bardzo silną strategię tworzenia kopii zapasowych. Główną wadą jest to, że nie jest dołączony do jądra głównego, więc musisz go zainstalować / zaktualizować osobno.

Alternatywnie, jeśli naprawdę musisz ograniczyć się do rzeczy zawartych w mainline, możesz użyć BTRFS. Ale pamiętaj, aby zrozumieć (wiele) wad i pita .

Wreszcie, alternatywnym rozwiązaniem jest zastosowanie lvmthindo regularnych kopii zapasowych (np: z snapper), powołując się na narzędzi firm trzecich (np bdsync, blocksyncitp), aby skopiować tylko / delty statku.

Innym podejściem byłoby posiadanie dwóch replikowanych maszyn (via DRBD), przez które można wykonywać niezależne migawki lvmthin.

Shodanshok
źródło

Co z postgresami? Czy chciałbyś zatrzymać Gitlab i Postgres na minutę, aby uzyskać spójne zdjęcie? Idealnie byłoby świetnie, gdyby postgres mógł zostać ustawiony w trybie tylko do odczytu podczas tworzenia migawki.

Sandra

@Sandra przywracanie z migawek systemu plików powinno wyglądać na postgresql (i wszelkie inne poprawnie napisane bazy danych) jako ogólny scenariusz „awarii hosta”, uruchamiając własną procedurę odzyskiwania (tj. Zobowiązanie do głównej bazy danych dowolnej częściowo napisanej strony). Innymi słowy, nie trzeba przełączać postgres w tryb tylko do odczytu podczas robienia zdjęć.

shodanshok

Chciałbym przejrzeć to, co tworzysz, i ewentualnie zastosować podejście „wielościeżkowe”. Na przykład, możesz wykonać kopię zapasową repozytoriów Git, stale uruchamiając pliki Git na serwerach kopii zapasowych. Spowodowałoby to skopiowanie tylko pliku różnicowego i pozostawienie drugiej kopii wszystkich repozytoriów Git. Przypuszczalnie można wykryć nowe repozytoria za pomocą interfejsu API.

I skorzystaj z „wbudowanych” procedur tworzenia kopii zapasowych, aby wykonać kopię zapasową problemów itp. Wątpię, że 3 TB pochodzi z tej części, więc będziesz mógł wykonywać kopie zapasowe bardzo często przy bardzo niskim koszcie. Można również skonfigurować bazę danych PostgreSQL z ciepłym trybem gotowości z replikacją.

Możliwe, że twój 3 TB pochodzi z obrazów kontenera w rejestrze Docker. Czy potrzebujesz kopii zapasowej? Jeśli tak, to może istnieć lepsze podejście właśnie do tego.

Zasadniczo poleciłbym naprawdę przyjrzeć się temu, co składa się na kopię zapasową i tworzyć kopię zapasową danych w różnych częściach.

Nawet narzędzie do tworzenia kopii zapasowych z GitLab ma opcje włączenia / wyłączenia niektórych części systemu, takich jak Rejestr Docker.

ETL
źródło

git pulls nie jest idealną przyrostową kopią zapasową. git push --forcealbo przerwie tworzenie kopii zapasowych, albo usunie z nich historię, w zależności od tego, jak zostanie ona zaimplementowana.

user371366

@ dn3s dlatego zawsze wyłączasz git push --force w głównym repozytorium. Jeśli ktoś chce zmienić historię, może zrobić własny widelec i zaakceptować wszystkie związane z tym ryzyko.

charlie_pl,

może to być przydatne do replikacji , ale nie chcesz, aby integralność kopii zapasowych polegała na poprawnym zachowaniu aplikacji. co się stanie, jeśli w aplikacji wystąpi błąd lub zostanie on źle skonfigurowany? co się stanie, jeśli Twój serwer zostanie zainfekowany przez złośliwego użytkownika? jeśli aplikacja ma możliwość usuwania zawartości z hosta kopii zapasowych, znaczna część wartości przyrostowych zdalnych kopii zapasowych jest tracona.

user371366,