Niniejsza notatka przeglądowa kontynuuje , napisana na prośbę czytelników, dotyczy UrBackup, BackupPC i AMANDA.
Przegląd UrBackup.
Na prośbę uczestnika dodaję przegląd UrBackup, systemu kliencko-serwerowego do tworzenia kopii zapasowych. Umożliwia tworzenie pełnych i inkrementalnych kopii zapasowych, obsługuje zrzuty urządzeń (tylko Win?), a także potrafi tworzyć kopie zapasowe plików. Klient może znajdować się w tej samej sieci co serwer lub łączyć się przez Internet. Zgłoszono śledzenie zmian, co pozwala szybko znaleźć różnice między kopiami zapasowymi. Istnieje również wsparcie dla deduplikacji przechowywania danych po stronie serwera, co pozwala oszczędzać miejsce. Połączenia sieciowe są szyfrowane, a także dostępny jest interfejs webowy do zarządzania serwerem. Zobaczmy, co potrafi:
W trybie tworzenia pełnej kopii zapasowej uzyskano następujące wyniki:
Czas pracy:
Pierwsze uruchomienie
Drugie uruchomienie
Trzecie uruchomienie
Pierwszy test
8m20s
8m19s
8m24s
Drugi test
8m30s
8m34s
8m20s
Trzeci test
8m10s
8m14s
8m12s
W trybie tworzenia inkrementalnych kopii zapasowych:
Czas pracy:
Pierwsze uruchomienie
Drugie uruchomienie
Trzecie uruchomienie
Pierwszy test
8m10s
8m10s
8m12s
Drugi test
3m50s
4m12s
3m34s
Trzeci test
2m50s
2m35s
2m38s
Rozmiar repozytorium w obu przypadkach wyniósł około 14 GB, co świadczy o działającej deduplikacji po stronie serwera. Należy również zauważyć, że czas tworzenia kopii zapasowej na serwerze i na kliencie się różni, co wyraźnie widać na wykresach i jest dość miłym bonusem, ponieważ interfejs webowy pokazuje czas działania procesu tworzenia kopii zapasowej po stronie serwera bez uwzględnienia
stanu klienta. Ogółem wykresy dla kopii pełnej i inkrementalnej są nieodróżnialne. Prawdopodobnie różnica tkwi tylko w tym, jak to jest przetwarzane po stronie serwera. Również niska obciążenie procesora na systemie objętym kopiowaniem cieszy.
Przegląd BackupPC
Na prośbę uczestnika Dodaję przegląd BackupPC. To oprogramowanie jest instalowane na serwerze przechowywania kopii zapasowych, napisane w Perl, działa na bazie różnych narzędzi do tworzenia kopii zapasowych — w szczególności rsync i tar. Jako transport używane są ssh i smb, a także dostępny jest interfejs webowy oparty na cgi (uruchamiany na apache). W interfejsie webowym znajduje się obszerny zestaw ustawień. Z cech, które wyróżniają to oprogramowanie, można zauważyć możliwość ustawienia minimalnego czasu między kopiami zapasowymi oraz okresu, w którym kopie zapasowe nie będą tworzone. Wybierając system plików dla serwera kopii zapasowych, należy zwrócić uwagę na wsparcie dla twardych linków. Dzięki temu system plików dla przechowalni nie będzie mógł być podzielony na punkty montowania. Ogólnie rzecz biorąc, sprawia to całkiem przyjemne wrażenie; zobaczmy, na co stać to oprogramowanie:
W trybie tworzenia pełnych kopii zapasowych z rsync uzyskano następujące wyniki:
Pierwsze uruchomienie
Drugie uruchomienie
Trzecie uruchomienie
Pierwszy test
12m25s
12m14s
12m27s
Drugi test
7m41s
7m44s
7m35s
Trzeci test
10m11s
10m0s
9m54s
Jeśli używać pełnych kopii zapasowych i tar:
Pierwsze uruchomienie
Drugie uruchomienie
Trzecie uruchomienie
Pierwszy test
12m41s
12m25s
12m45s
Drugi test
12m35s
12m45s
12m14s
Trzeci test
12m43s
12m25s
12m5s
W trybie tworzenia inkrementalnych kopii zapasowych musiałem zrezygnować z tar, ponieważ przy takich ustawieniach kopie zapasowe nie były tworzone.
Wyniki tworzenia inkrementalnych kopii zapasowych przy użyciu rsync są następujące:
Pierwsze uruchomienie
Drugie uruchomienie
Trzecie uruchomienie
Pierwszy test
11m55s
11m50s
12m25s
Drugi test
2m42s
2m50s
2m30s
Trzeci test
6m00s
5m35s
5m30s
Ogólnie widać niewielką przewagę prędkości rsync, a także rsync oszczędniej działa w sieci. Częściowo może to być zrekompensowane mniejszym użyciem CPU przy użyciu tar jako programu do tworzenia kopii zapasowych. Inną zaletą rsync jest obsługa inkrementalnych kopii. Rozmiar repozytorium przy tworzeniu pełnych kopii zapasowych jest taki sam, wynosi 16 GB, w przypadku kopii inkrementalnych wynosi 14 GB za jeden cykl, co oznacza działającą deduplikację.
Przegląd AMANDA
Na prośbę uczestnika Dodaję testy AMANDA,
Wyniki testu z tar jako archiwizatorem z aktywacją kompresji są następujące:
Pierwsze uruchomienie
Drugie uruchomienie
Trzecie uruchomienie
Pierwszy test
9m5s
8m59s
9m6s
Drugi test
0m5s
0m5s
0m5s
Trzeci test
2m40s
2m47s
2m45s
Program w pełni obciąża jedno rdzeń procesora, ale z powodu ograniczonej przepustowości iops dysku na serwerze magazynującym kopie zapasowe, nie może osiągnąć dużych prędkości transferu danych. Ogólnie rzecz biorąc, konfiguracja sprawiła nieco więcej problemów niż u pozostałych uczestników, ponieważ autor programu nie korzysta z transportu ssh, lecz wdraża podobny schemat z kluczami, tworząc i utrzymując pełnoprawną CA. Istnieje możliwość szerokiego ograniczenia klienta i serwera kopii zapasowych: jeśli na przykład nie mogą sobie w pełni ufać, można, jako opcję, zabronić inicjowania przywracania kopii zapasowej ze strony serwera, ustawiając wartość odpowiedniej zmiennej na zero w pliku konfiguracyjnym. Można podłączyć interfejs webowy do zarządzania, ale ogólnie skonfigurowany system można w pełni zautomatyzować za pomocą małych skryptów bash (lub SCM, na przykład ansible). Istnieje kilka nietrywialnych systemów konfiguracji magazynu, co najwyraźniej związane jest z wsparciem dla szerokiej listy różnych urządzeń do przechowywania danych (kasety LTO, twarde dyski itp.). Warto również zauważyć, że z wszystkich programów omawianych w tym artykule, AMANDA była jedynym, który zdołał wykryć zmianę nazwy katalogu. Rozmiar repozytorium po jednym przebiegu wyniósł 13 GB.
Ogłoszenie
Kopie zapasowe, część 6: Porównanie narzędzi do tworzenia kopii zapasowych
Kopie zapasowe, część 7: Wnioski
Źródło: habr.com
