W tej notatce omówiono narzędzia do tworzenia kopii zapasowych, które wykonują kopie zapasowe poprzez tworzenie archiwów na serwerze kopii zapasowych.
Wśród tych, które spełniają wymagania, znajdują się duplikacja (która ma ładny interfejs w postaci deja dup) i duplicati.
Kolejnym bardzo niezwykłym narzędziem do tworzenia kopii zapasowych jest dar, ale ponieważ ma bardzo obszerną listę opcji – metodologia testowania obejmuje zaledwie 10% jego możliwości – nie testujemy go w ramach bieżącego cyklu.
Oczekiwane rezultaty
Ponieważ obaj kandydaci tworzą archiwa w taki czy inny sposób, jako wskazówki można użyć zwykłego tar.
Dodatkowo ocenimy, jak dobrze zoptymalizowane jest przechowywanie danych na serwerze pamięci masowej, tworząc kopie zapasowe zawierające jedynie różnicę pomiędzy pełną kopią a bieżącym stanem plików lub pomiędzy poprzednimi i bieżącymi archiwami (przyrostowymi, dekrementalnymi itp.). .
Zachowanie podczas tworzenia kopii zapasowych:
- Stosunkowo niewielka liczba plików na serwerze magazynu kopii zapasowych (porównywalna z liczbą kopii zapasowych lub rozmiarem danych w GB), ale ich rozmiar jest dość duży (dziesiątki do setek megabajtów).
- Rozmiar repozytorium będzie uwzględniał tylko zmiany - nie będą przechowywane żadne duplikaty, więc rozmiar repozytorium będzie mniejszy niż w przypadku oprogramowania opartego na rsync.
- Należy spodziewać się dużego obciążenia procesora podczas korzystania z kompresji i/lub szyfrowania oraz prawdopodobnie dość dużego obciążenia sieci i dysku, jeśli proces archiwizacji i/lub szyfrowania jest uruchomiony na serwerze przechowywania kopii zapasowych.
Uruchommy następujące polecenie jako wartość referencyjną:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Wyniki realizacji przedstawiały się następująco:
Czas realizacji 3m12s. Można zauważyć, że prędkość jest ograniczona przez podsystem dyskowy serwera magazynu kopii zapasowych, jak w przykładzie . Tylko trochę szybciej, bo... nagranie trafia do jednego pliku.
Aby ocenić kompresję, uruchommy tę samą opcję, ale włączmy kompresję po stronie serwera kopii zapasowych:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Wyniki to:
Czas wykonania 10m11s. Najprawdopodobniej wąskim gardłem jest sprężarka jednoprzepływowa po stronie odbiorczej.
To samo polecenie, ale z kompresją przesłaną na serwer z oryginalnymi danymi w celu sprawdzenia hipotezy, że wąskim gardłem jest kompresor jednowątkowy.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Okazało się tak:
Czas realizacji wyniósł 9m37s. Obciążenie jednego rdzenia przez sprężarkę jest wyraźnie widoczne, ponieważ Szybkość transferu sieci i obciążenie podsystemu dysku źródłowego są podobne.
Aby ocenić szyfrowanie, możesz użyć openssl lub gpg, podłączając dodatkowe polecenie openssl lub gpg w rurze. Dla odniesienia będzie takie polecenie:
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 tak:
Czas wykonania wyniósł 10 m30 s, ponieważ po stronie odbierającej działały 2 procesy – wąskim gardłem jest ponownie kompresor jednowątkowy plus niewielki narzut związany z szyfrowaniem.
UPD: Na prośbę bliznezz dodaję testy z pigz. Jeśli użyjesz tylko kompresora, zajmie to 6 m30 s, jeśli dodasz także szyfrowanie, będzie to około 7 m. Spadek na dolnym wykresie to nieopróżniona pamięć podręczna dysku:
Zduplikowane testy
Duplicity to oprogramowanie Python do tworzenia kopii zapasowych poprzez tworzenie zaszyfrowanych archiwów w formacie tar.
W przypadku archiwów przyrostowych używana jest biblioteka librsync, więc można spodziewać się zachowania opisanego w .
Kopie zapasowe można szyfrować i podpisywać za pomocą gnupg, co jest ważne w przypadku korzystania z usług różnych dostawców przechowywania kopii zapasowych (s3, backblaze, gdrive itp.)
Zobaczmy, jakie są wyniki:
Oto wyniki, które uzyskaliśmy podczas działania bez szyfrowania
spojler
Czas trwania każdego uruchomienia testowego:
Uruchom 1
Uruchom 2
Uruchom 3
16m33
17m20
16m30
8m29
9m3
8m45
5m21
6m04
5m53
A oto wyniki po włączeniu szyfrowania gnupg z kluczem o rozmiarze 2048 bitów:
Czas pracy na tych samych danych, z szyfrowaniem:
Uruchom 1
Uruchom 2
Uruchom 3
17m22
17m32
17m28
8m52
9m13
9m3
5m48
5m40
5m30
Wskazano rozmiar bloku - 512 megabajtów, co wyraźnie widać na wykresach; Obciążenie procesora faktycznie pozostało na poziomie 50%, co oznacza, że program wykorzystuje nie więcej niż jeden rdzeń procesora.
Zasada działania programu jest również dość wyraźnie widoczna: pobrali fragment danych, skompresowali go i wysłali na serwer magazynu kopii zapasowych, co może być dość powolne.
Kolejną cechą jest przewidywalny czas działania programu, który zależy wyłącznie od wielkości zmienianych danych.
Włączenie szyfrowania nie wydłużyło znacząco czasu działania programu, ale zwiększyło użycie procesora o około 10%, co może być całkiem niezłym bonusem.
Niestety program ten nie był w stanie poprawnie wykryć sytuacji ze zmianą nazwy katalogu i wynikowy rozmiar repozytorium okazał się równy rozmiarowi zmian (czyli całe 18GB), ale możliwość wykorzystania niezaufanego serwera do tworzenia kopii zapasowych wyraźnie obejmuje to zachowanie.
Zduplikowane testy
To oprogramowanie jest napisane w języku C# i działa przy użyciu zestawu bibliotek firmy Mono. Dostępna jest wersja GUI oraz wersja CLI.
Przybliżona lista głównych funkcji jest podobna do duplikacji i obejmuje różnych dostawców magazynu kopii zapasowych, jednak w przeciwieństwie do duplikacji większość funkcji jest dostępna bez narzędzi stron trzecich. To, czy jest to plus, czy minus, zależy od konkretnego przypadku, ale dla początkujących najprawdopodobniej łatwiej jest mieć przed sobą listę wszystkich funkcji na raz, zamiast instalować dodatkowe pakiety dla Pythona, jak to ma miejsce sprawa z dwulicowością.
Kolejny mały niuans - program aktywnie zapisuje lokalną bazę danych sqlite w imieniu użytkownika rozpoczynającego tworzenie kopii zapasowej, dlatego należy dodatkowo upewnić się, że wymagana baza danych jest poprawnie określona za każdym razem, gdy proces jest uruchamiany za pomocą cli. Podczas pracy poprzez GUI lub WEBGUI szczegóły będą ukryte przed użytkownikiem.
Zobaczmy, jakie wskaźniki może dać to rozwiązanie:
Jeśli wyłączysz szyfrowanie (a WEBGUI tego nie zaleca), wyniki będą następujące:
godziny:
Uruchom 1
Uruchom 2
Uruchom 3
20m43
20m13
20m28
5m21
5m40
5m35
7m36
7m54
7m49
Po włączeniu szyfrowania przy użyciu aes wygląda to tak:
godziny:
Uruchom 1
Uruchom 2
Uruchom 3
29m9
30m1
29m54
5m29
6m2
5m54
8m44
9m12
9m1
A jeśli użyjesz zewnętrznego programu gnupg, wyjdą następujące wyniki:
Uruchom 1
Uruchom 2
Uruchom 3
26m6
26m35
26m17
5m20
5m48
5m40
8m12
8m42
8m15
Jak widać program może pracować w kilku wątkach, ale to nie czyni go bardziej produktywnym rozwiązaniem, a jeśli porównać pracę szyfrowania, uruchamia zewnętrzny program
okazało się szybsze niż użycie biblioteki z zestawu Mono. Może to wynikać z faktu, że program zewnętrzny jest bardziej zoptymalizowany.
Przyjemnym punktem był także fakt, że wielkość repozytorium zajmuje dokładnie tyle samo, co faktycznie zmienione dane, tj. duplicati wykrył zmianę nazwy katalogu i poprawnie poradził sobie z tą sytuacją. Można to zobaczyć podczas przeprowadzania drugiego testu.
Ogólnie rzecz biorąc, dość pozytywne wrażenia z programu, w tym w miarę przyjaznego dla początkujących.
wyniki
Obaj kandydaci pracowali dość wolno, ale ogólnie w porównaniu do zwykłej smoły jest postęp, przynajmniej przy duplikatach. Cena takiego postępu też jest jasna – zauważalne obciążenie
edytor. Ogólnie rzecz biorąc, nie ma specjalnych odchyleń w przewidywaniu wyników.
odkrycia
Jeśli nie musisz się nigdzie spieszyć i masz zapasowy procesor, każde z rozważanych rozwiązań wystarczy, w każdym razie wykonano sporo pracy, której nie należy powtarzać, pisząc skrypty opakowujące na wierzchu tar . Obecność szyfrowania jest bardzo niezbędną właściwością, jeśli nie można w pełni zaufać serwerowi do przechowywania kopii zapasowych.
W porównaniu z rozwiązaniami opartymi na - wydajność może być kilkukrotnie gorsza, mimo że w czystej postaci tar działał 20-30% szybciej niż rsync.
Istnieją oszczędności na wielkości repozytorium, ale tylko w przypadku duplikatów.
Zapowiedź
Kopia zapasowa Część 3: Przegląd i testowanie duplikacji, duplikacji, deja dup
Kopia zapasowa, część 4: Przegląd i testowanie zbackup, restic, borgbackup
Kopia zapasowa, część 5: Testowanie kopii zapasowych Bacula i Veeam dla systemu Linux
Kopia zapasowa, część 6: Porównanie narzędzi do tworzenia kopii zapasowych
Część zapasowa 7: Wnioski
Wysłane przez: Paweł Demkowicz
Źródło: www.habr.com