W tym artykule omówiono narzędzia do tworzenia kopii zapasowych, które wykonują kopie zapasowe, tworząc archiwa na zapasowym serwerze.
Z tych, które spełniają wymagania, są duplicity (które ma przyjemny interfejs w postaci deja dup) oraz duplicati.
Innym godnym uwagi narzędziem do tworzenia kopii zapasowych jest dar, ale ponieważ ma on dość obszerną listę opcji — metoda testowania obejmuje ledwie 10% tego, na co jest on zdolny — nie testujemy go w ramach bieżącego cyklu.
Oczekiwane wyniki
Ponieważ obaj kandydaci w taki czy inny sposób tworzą archiwa, można jako punkt odniesienia wykorzystać zwykły tar.
Dodatkowo ocenimy, jak dobrze optymalizowane jest przechowywanie danych na serwerze storage poprzez tworzenie kopii zapasowych, które zawierają jedynie różnicę pomiędzy pełną kopią a aktualnym stanem plików lub pomiędzy przeszłymi a bieżącymi archiwami (inkrementalne, dekrementalne itp.).
Zachowanie przy tworzeniu kopii zapasowych:
- Relatywnie niewielka liczba plików na serwerze przechowywania kopii zapasowych (w porównaniu z liczbą kopii zapasowych lub ilością danych w GB), ale o dostatecznie dużym rozmiarze (dziesiątki-setki megabajtów).
- Rozmiar repozytorium będzie obejmował jedynie zmiany — duplikaty nie będą przechowywane, w ten sposób rozmiar repozytorium będzie mniejszy, niż w przypadku oprogramowania opartego na rsync.
- Oczekiwane jest duże obciążenie procesora przy użyciu kompresji i/lub szyfrowania, a także prawdopodobnie dość duże obciążenie sieci i subsystemu dyskowego, jeśli proces archiwizacji i/lub szyfrowania będzie działał na serwerze przechowywania kopii zapasowych.
Jako wartość odniesienia uruchomimy następujące polecenie:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Wyniki wykonania są następujące:
Czas wykonania: 3m12s. Widać, że prędkość utknęła na subsystemie dyskowym serwera przechowywania kopii zapasowych, jak w przykładzie z . Tylko nieco szybciej, ponieważ zapis odbywa się do jednego pliku.
Również w celu oceny kompresji uruchomimy ten sam wariant, ale włączymy kompresję po stronie serwera tworzenia kopii zapasowych:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Wyniki są takie:
Czas wykonania: 10m11s. Najprawdopodobniej wąskie gardło to jednowątkowy kompresor po stronie odbierającej.
Ta sama komenda, ale z przeniesieniem kompresji na serwer z danymi źródłowymi w celu sprawdzenia hipotezy, że wąskim gardłem jest jednowątkowy kompresor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Wyszło tak:
Czas wykonania wyniósł 9m37s. Wyraźnie widać obciążenie jednego rdzenia przez kompresor, ponieważ prędkość przesyłania w sieci oraz obciążenie systemu dyskowego źródła są podobne.
Do oceny szyfrowania można użyć openssl lub gpg, dodając dodatkową komendę openssl lub gpg w pipe. Dla orientacji będzie taka komenda:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Wyniki wyszły takie:
Czas wykonania wyniósł 10m30s, ponieważ uruchomiono 2 procesy po stronie odbiorczej — wąskim gardłem znów był jednowątkowy kompresor, a także niewielkie koszty dodatkowe na szyfrowanie.
UPD: Na prośbę bliznezz dodaję testy z pigz. Jeśli używać tylko kompresora — udało się to zrobić w 6m30s, jeśli dodatkowo doda się szyfrowanie — około 7m. Spadek na dolnym wykresie — niewyczyszczona pamięć podręczna dysku:
Testowanie duplicity
Duplicity — oprogramowanie w Pythonie do tworzenia kopii zapasowych poprzez tworzenie zaszyfrowanych archiwów w formacie tar.
Dla archiwów inkrementalnych używa się librsync, więc można oczekiwać zachowania opisanego w .
Kopie zapasowe mogą być szyfrowane i podpisywane za pomocą gnupg, co jest istotne przy korzystaniu z różnych dostawców do przechowywania kopii zapasowych (s3, backblaze, gdrive itp.)
Zobaczymy, jakie będą wyniki:
Oto jakie wyniki uzyskano przy uruchomieniu bez szyfrowania
spojler
Czas pracy każdego testu:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
A oto wyniki przy włączeniu szyfrowania gnupg, z rozmiarem klucza 2048 bitów:
Czas pracy na tych samych danych ze szyfrowaniem:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Został określony rozmiar bloku — 512 megabajtów, co wyraźnie widać na wykresach; obciążenie procesora rzeczywiście utrzymywało się na poziomie 50%, więc program wykorzystuje nie więcej niż jeden rdzeń procesora.
Widać również dobrze zasadę działania programu: wzięto kawałek danych, skompresowano go, wysłano na serwer przechowywania kopii zapasowych, który może być dość wolny.
Kolejną cechą jest przewidywalny czas działania programu, który zależy tylko od rozmiaru zmienionych danych.
Włączenie szyfrowania nie zwiększyło znacznie czasu działania programu, ale podniosło obciążenie procesora o około 10%, co może być całkiem miłym bonusem.
Niestety, ten program nie był w stanie prawidłowo wykryć sytuacji związanej z zmianą nazwy katalogu, więc wynikowy rozmiar repozytorium okazał się równy rozmiarowi zmian (tj. wszystkie 18 GB), ale możliwość korzystania z niezaufanego serwera do tworzenia kopii zapasowych zdecydowanie przeważa nad takim zachowaniem.
Testowanie duplicati
Oprogramowanie to zostało napisane w C#, uruchamiane jest przy użyciu zestawu bibliotek Mono. Oferuje zarówno GUI, jak i wersję CLI.
Przybliżony wykaz głównych możliwości jest zbliżony do duplicity, w tym różnych dostawców do przechowywania kopii zapasowych; jednak w odróżnieniu od duplicity, większość funkcji jest dostępna bez zewnętrznych narzędzi. To, czy to zaleta czy wada — zależy od konkretnego przypadku, ale dla nowicjuszy prawdopodobnie łatwiej jest mieć przed oczami listę wszystkich możliwości, zamiast instalować pakiety Pythona, jak w przypadku duplicity.
Jeszcze jeden drobny szczegół — program aktywnie zapisuje lokalną bazę sqlite w imieniu użytkownika, który uruchamia tworzenie kopii zapasowych, dlatego należy dodatkowo monitorować poprawne wskazanie potrzebnej bazy przy każdym uruchomieniu procesu korzystając z CLI. Przy pracy przez GUI lub WEBGUI szczegóły będą ukryte przed użytkownikiem.
Zobaczmy, jakie wyniki może dać to rozwiązanie:
Jeśli wyłączyć szyfrowanie (chociaż WEBGUI nie zaleca tego), wyniki są następujące:
Czas pracy:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Z włączonym szyfrowaniem, używając aes, wyniki są takie:
Czas pracy:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
A jeśli użyć zewnętrznego programu gnupg, wyniki są takie:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Jak widać — program potrafi działać w wielu wątkach, ale nie czyni go to bardziej wydajnym rozwiązaniem, a jeśli porównamy czas działania szyfrowania — uruchomienie zewnętrznego programu
okazało się szybsze niż zastosowanie biblioteki z zestawu Mono. Może to być związane z tym, że zewnętrzny program jest lepiej zoptymalizowany.
Przyjemnym aspektem jest również to, że rozmiar repozytorium wynosi dokładnie tyle, ile rzeczywiście zmienionych danych, tzn. duplicati wykrył zmianę nazwy katalogu i właściwie to obsłużył. Można to zobaczyć podczas przeprowadzania drugiego testu.
Ogólnie, mam pozytywne wrażenia z programu, w tym odpowiednią przyjazność dla nowicjuszy.
Wyniki
Obaj kandydaci działali dość wolno, ale w porównaniu do standardowego tar, jest postęp, przynajmniej u duplicati. Cena tego postępu jest również wyraźna — zauważalne obciążenie
procesora. Ogólnie nie ma żadnych szczególnych odchyleń w prognozowaniu wyników.
Wnioski
Jeśli nie ma potrzeby się spieszyć, a także jest zapas mocy procesora — nada się każde z rozważanych rozwiązań, w każdym razie wykonano wystarczająco dużą pracę, której nie warto powtarzać pisząc dodatkowe skrypty na bazie tar. Posiadanie szyfrowania jest bardzo potrzebnym atutem, jeśli serwer do przechowywania kopii zapasowych nie może być całkowicie zaufany.
Porównując z rozwiązaniami opartymi na — wydajność może być gorsza kilkukrotnie, mimo że czysty tar działał szybciej od rsync o 20-30%.
Oszczędność na rozmiarze repozytorium występuje tylko u duplicati.
Ogłoszenie
Kopie zapasowe, część 3: Przegląd i testowanie duplicity, duplicati, deja dup
Kopia zapasowa, część 4: Przegląd i testowanie zbackup, restic, borgbackup
Kopie zapasowe, część 5: Testowanie bacula i veeam backup for linux
Kopie zapasowe, część 6: Porównanie narzędzi do tworzenia kopii zapasowych
Kopie zapasowe, część 7: Wnioski
Autor publikacji: Paweł Demkiewicz
Źródło: habr.com
