W tym artykule porównamy narzędzia do tworzenia kopii zapasowych, ale najpierw warto poznać, jak szybko i skutecznie radzą sobie z przywracaniem danych z kopii zapasowych.
Dla uproszczenia porównania skupimy się na przywracaniu z pełnej kopii zapasowej, tym bardziej, że ten tryb pracy wspierają wszyscy kandydaci. Dla uproszczenia, liczby zostały uśrednione (średnia z kilku uruchomień). Wyniki zostaną przedstawione w tabeli, która również zawiera informacje o możliwościach: dostępność interfejsu webowego, łatwość konfiguracji i użytkowania, zdolność do automatyzacji, dostępność różnych dodatkowych funkcji (na przykład sprawdzanie integralności danych) itp. Wykresy będą pokazywać obciążenie serwera, na którym dane będą zastosowane (nie serwera do przechowywania kopii zapasowych).
Odzyskiwanie danych
Jako punkt odniesienia zostaną użyte rsync i tar, ponieważ najprostsze skrypty do tworzenia kopii zapasowych.
Rsync poradził sobie z testowym zestawem danych w 4 minuty i 28 sekund, pokazując
takie obciążenie.
Proces przywracania napotkał ograniczenie subsystems dyskowego serwera przechowującego kopie zapasowe (zębate wykresy). Również wyraźnie widać obciążenie jednego rdzenia bez większych problemów (niski iowait i softirq — brak problemów z dyskiem i siecią). Ponieważ dwa inne programy, mianowicie rdiff-backup i rsnapshot, opierają się na rsync, a także oferują jako narzędzie do przywracania standardowy rsync, — będą miały zbliżony profil obciążenia i czas przywracania kopii zapasowej.
Tar poradził sobie nieco szybciej, w czasie
2 minuty i 43 sekundy:
Średnie obciążenie systemu było wyższe o 20% z powodu wzrostu softirq — wzrosły koszty operacyjne związane z działaniem subsystemu sieciowego.
Jeśli archiwum zostanie dodatkowo skompresowane, czas przywracania wzrasta do 3 minut i 19 sekund z
takim obciążeniem na głównym serwerze (rozpakowywanie po stronie głównego serwera):
Proces rozpakowywania zajmuje oba rdzenie procesora, ponieważ działa dwa procesy. Ogólnie — to oczekiwany rezultat. Porównywalny wynik (3 minuty i 20 sekund) uzyskano również przy uruchomieniu gzip po stronie serwera z kopiami zapasowymi, profil obciążenia na głównym serwerze był dość podobny do uruchomienia tar bez kompresora gzip (zob. poprzedni wykres).
W rdiff-backup można zsynchronizować ostatnią wykonaną kopię zapasową za pomocą zwykłego rsync (wyniki będą podobne), ale starsze kopie zapasowe i tak należy przywracać za pomocą programu rdiff-backup, który poradził sobie z przywracaniem w 17 minut i 17 sekund, pokazując
takie obciążenie:
Możliwe, że takie miało być zamierzenie, w każdym razie aby ograniczyć prędkość autorzy . Sam proces przywracania kopii zapasowej zajmuje trochę mniej niż połowę jednego rdzenia, przy proporcjonalnie porównywalnej wydajności (tj. 2-5 razy wolniej) zarówno na dysku, jak i w sieci z rsync.
Rsnapshot do przywracania oferuje używanie zwykłego rsync, dlatego jego wyniki będą podobne. Ogólnie rzecz biorąc, tak właśnie wyszło.
Burp z zadaniem przywracania kopii zapasowej poradził sobie w 7 minut i 2 sekundy z
takim obciążeniem:
Zadziałał dość szybko, a przynajmniej o wiele wygodniej niż czysty rsync: nie trzeba pamiętać żadnych flag, prosty i intuicyjny interfejs cli, wbudowane wsparcie dla wielu kopii, — prawda, dwa razy wolniej. Jeśli dane trzeba przywracać z ostatnio wykonanej kopii zapasowej — można skorzystać z rsync, z niewielkimi zastrzeżeniami.
Podobną szybkość i obciążenie pokazał program BackupPC w trybie przesyłania rsync, przywracając kopię zapasową w
7 minut i 42 sekundy:
Natomiast w trybie przesyłania danych z tar BackupPC poradził sobie wolniej: w 12 minut i 15 sekund, a obciążenie procesora w tym przypadku było w sumie niższe
o półtora raza:
Duplicity bez szyfrowania osiągnął nieco lepsze wyniki, poradziwszy sobie z przywracaniem kopii zapasowej w ciągu 10 minut i 58 sekund. Jeśli aktywować szyfrowanie za pomocą gpg — czas przywracania wzrasta do 15 minut i 3 sekund. Można również wskazać rozmiar archiwum, które zostanie użyte do podziału strumienia danych wejściowych podczas tworzenia repozytorium do przechowywania kopii. Ogólnie, na zwykłych dyskach twardych, z uwagi na jednopoziomowy tryb pracy, nie ma szczególnej różnicy. Może ona pojawić się przy różnych rozmiarach bloków, gdy używane są hybrydowe magazyny. Obciążenie głównego serwera przy przywracaniu wyniosło:
bez szyfrowania
z szyfrowaniem
Duplicati pokazał porównywalną prędkość przywracania, poradziwszy sobie w 13 minut i 45 sekund. Około 5 minut zajęło sprawdzenie poprawności przywróconych danych (łącznie około 19 minut). Obciążenie przy tym było
dość wysokie:
Kiedy szyfrowanie aes aktywowało się wewnętrznymi środkami, czas przywracania wyniósł 21 minut 40 sekund, przy czym obciążenie procesora było maksymalne (oba rdzenie!) podczas przywracania; podczas sprawdzania danych aktywny był tylko jeden wątek, zajmujący jeden rdzeń procesora. Sprawdzanie danych po przywróceniu zajęło tyle samo 5 minut (łącznie prawie 27 minut).
Wynik
Nieco szybciej duplicati poradził sobie z przywracaniem przy użyciu zewnętrznego programu gpg do szyfrowania, ale w sumie różnice w porównaniu do poprzedniego trybu są minimalne. Czas pracy wyniósł 16 minut 30 sekund, z sprawdzaniem danych w czasie 6 minut. Obciążenie było
takie:
AMANDA, używająca tar, poradziła sobie w 2 minuty 49 sekund, co w zasadzie jest dość bliskie zwykłemu tar. Obciążenie systemu w zasadzie
jest takie same:
Podczas przywracania kopii zapasowej za pomocą zbackup uzyskano następujące wyniki:
szyfrowanie, kompresja lzma
Czas pracy 11 minut i 8 sekund
szyfrowanie aes, kompresja lzma
Czas pracy 14 minut
szyfrowanie aes, kompresja lzo
Czas pracy 6 minut, 19 sekund
Ogólnie rzecz biorąc, nieźle. Wszystko sprowadza się do prędkości procesora na serwerze kopii zapasowej, co wyraźnie widać po czasie pracy programu z różnymi kompresorami. Po stronie serwera kopii zapasowej uruchamiano zwykły tar, więc jeśli porównamy to z nim — przywracanie działa trzy razy wolniej. Być może warto sprawdzić działanie w trybie wielowątkowym, z liczbą wątków większą niż dwa.
BorgBackup w trybie bez szyfrowania poradził sobie nieco wolniej niż tar, w czasie 2 minut 45 sekund, jednak w odróżnieniu od tar pojawiła się możliwość deduplikacji repozytorium. Obciążenie przy tym wyniosło
następujące:
Jeśli aktywować szyfrowanie oparte na blake, to prędkość przywracania kopii zapasowej nieco spowalnia. Czas przywracania w tym trybie wynosi 3 minuty 19 sekund, a obciążenie wyniosło
takie:
Szyfrowanie aes działa nieco wolniej, czas przywracania wynosi 3 minuty 23 sekundy, a obciążenie szczególnie
się nie zmieniło:
Ponieważ Borg może działać w trybie wielowątkowym — obciążenie procesora jest maksymalne, przy tym aktywacja dodatkowych funkcji po prostu wydłuża czas działania. Najwyraźniej warto zbadać wielowątkowość działania analogicznie do zbackup.
Restic poradził sobie z przywracaniem nieco wolniej, czas pracy wyniósł 4 minuty 28 sekund. Obciążenie przy tym wyglądało
tak:
Najwyraźniej proces przywracania działa w kilku wątkach, ale efektywność nie jest tak wysoka jak w BorgBackup, ale czasowo porównywalna z zwykłym rsync.
Dzięki UrBackup udało się przywrócić dane w czasie 8 minut i 19 sekund, przy tym obciążenie wyniosło
takie:
Wciąż widać niewielkie obciążenie, nawet niższe niż u tar. Miejscami wzrosty, ale nie przekraczające obciążenia jednego rdzenia.
Wybór i uzasadnienie kryteriów porównania
Jak powiedziano w jednym z wcześniejszych artykułów, system tworzenia kopii zapasowych powinien odpowiadać następującym kryterium:
- Łatwość w obsłudze
- Wszechstronność
- Stabilność
- Szybkość
Warto rozważyć każdy punkt osobno bardziej szczegółowo.
Łatwość obsługi
Najlepiej, gdy jest jeden przycisk „Zrób wszystko dobrze”, ale jeśli wrócić do rzeczywistych programów — najwygodniej byłoby mieć pewną znaną i standardową zasadę działania.
Większości użytkowników z pewnością łatwiej byłoby, gdyby nie musieli zapamiętywać wielu kluczy do CLI, konfigurować różnych, często mało intuicyjnych opcji przez web lub TUI, oraz ustawiać powiadomień o nieudanej pracy. Do tego należy łatwość „wkomponowania” rozwiązania do tworzenia kopii zapasowych w istniejącą infrastrukturę oraz automatyzacja procesu tworzenia kopii zapasowych. Tutaj również możliwość instalacji za pomocą menedżera pakietów lub w jednej czy dwóch komendach w stylu „pobierz i rozpakuj”. curl link | sudo bash — trudna metoda, ponieważ trzeba sprawdzić, co przychodzi pod linkiem.
Na przykład, z rozważanych kandydatów prostym rozwiązaniem są burp, rdiff-backup i restic, które mają łatwe do zapamiętania klucze do różnych trybów pracy. Nieco bardziej skomplikowane to borg i duplicity. Najtrudniejsze było AMANDA. Pozostałe pod względem łatwości użytkowania są gdzieś pośrodku. W każdym razie, jeśli trzeba poświęcić więcej niż 30 sekund na przeczytanie instrukcji obsługi lub trzeba zajrzeć do Google lub innej wyszukiwarki, a także przewertować długi dokument pomocy — rozwiązanie jest skomplikowane, w ten czy inny sposób.
Część rozważanych kandydatów potrafi automatycznie wysłać wiadomość e-mail lub na Jabbera, inne polegają na skonfigurowanych powiadomieniach w systemie. Przy tym najczęściej skomplikowane rozwiązania mają mniej oczywiste ustawienia powiadomień. W każdym razie, jeśli program do tworzenia kopii zapasowych zwróci kod wyjścia różny od zera, który systemowy serwis do zadań cyklicznych poprawnie zrozumie (wysyłając wiadomość do administratora systemu lub od razu do monitoringu) — sytuacja jest prosta. O ile jednak system tworzenia kopii zapasowych, działający nie na serwerze kopii zapasowych, nie potrafi w oczywisty sposób zgłosić problemu bez konfiguracji — trudność jest już nadmierna. W każdym razie wydawanie ostrzeżeń i innych wiadomości tylko w interfejsie webowym lub w logach — to zła praktyka, ponieważ najczęściej będą one ignorowane.
Jeśli chodzi o automatyzację — prosta aplikacja potrafi odczytać zmienne środowiskowe, które definiują jej tryb pracy, lub posiada rozwinięty CLI, zdolny do pełnego powielania zachowania przy pracy przez interfejs webowy, na przykład. Należy tutaj również wliczyć możliwość pracy strumieniowej, obecność możliwości rozszerzenia itp.
Wszechstronność
Częściowo pokrywa się z poprzednią sekcją w zakresie automatyzacji, nie powinno być większym problemem "wkomponowanie" procesu tworzenia kopii zapasowej w istniejącą infrastrukturę.
Warto zauważyć, że użycie niestandardowych portów (z wyjątkiem interfejsu webowego) do pracy, realizacja szyfrowania w niestandardowy sposób, wymiana danych za pomocą niestandardowego protokołu — to oznaki rozwiązania nieuniwersalnego. W większości przypadków wszyscy kandydaci mają je w większym lub mniejszym stopniu z oczywistego powodu: prostota i uniwersalność zazwyczaj są ze sobą niezgodne. Wyjątkiem jest burp, są też inne.
Za oznakę można uznać możliwość pracy przy użyciu standardowego ssh.
Szybkość działania
Najbardziej kontrowersyjny i sporny punkt. Z jednej strony — uruchomiono proces, działał jak najszybciej i nie przeszkadzał w wykonywaniu podstawowych zadań. Z drugiej — skok ruchu i obciążenia procesora w czasie tworzenia kopii zapasowej. Należy również zauważyć, że najszybsze programy do tworzenia kopii zwykle są najuboższe pod względem funkcji ważnych dla użytkowników. Ponownie: jeśli aby wydobyć jeden nieszczęsny plik tekstowy o rozmiarze kilku dziesiątek bajtów z hasłem, a z powodu niego wstaje cały serwis (tak, rozumiem, że często proces tworzenia kopii zapasowej nie jest winny), trzeba kolejno przeglądać wszystkie pliki w repozytorium lub rozpakować cały archiwum — system backupowy w żadnym wypadku nie jest szybki. Innym punktem, który często staje się kamieniem napotkania, jest szybkość przywracania kopii z archiwum. Tutaj wyraźną przewagę mają ci, którzy mogą po prostu skopiować lub przenieść pliki we właściwe miejsce bez większych manipulacji (np. rsync), lecz najczęściej problem ten trzeba rozwiązywać w sposób organizacyjny, empirycznie: mierzyć czas przywracania kopii zapasowej i otwarcie go komunikować użytkownikom.
Stabilność
Należy to rozumieć w ten sposób: z jednej strony, musi być możliwość przywrócenia kopii zapasowej w każdej sytuacji, z drugiej — odporność na różnorodne problemy: przerwanie sieci, awaria dysku, usunięcie części repozytorium.
Porównanie narzędzi do tworzenia kopii zapasowych
Czas tworzenia kopii
Czas przywracania kopii
Łatwa instalacja
Prosta konfiguracja
Prosta obsługa
Prosta automatyzacja
Czy potrzebny jest klient-serwer?
Sprawdzenie integralności repozytorium
Kopii różnicowe
Praca przez pipe
Wszechstronność
Samodzielność
Przezroczystość repozytorium
Szyfrowanie
Kompresja
Dedupikacja
Interfejs webowy
Wgrywanie do chmury
Wsparcie dla Windows
Punkty
Rsync
4m15s
4m28s
tak
nie
nie
nie
tak
nie
nie
tak
nie
tak
tak
nie
nie
nie
nie
nie
tak
6
Tar
pure
3m12s
2m43s
tak
nie
nie
nie
nie
nie
tak
tak
nie
tak
nie
nie
nie
nie
nie
nie
tak
8,5
gzip
9m37s
3m19s
tak
Rdiff-backup
16m26s
17m17s
tak
tak
tak
tak
tak
nie
tak
nie
tak
nie
tak
nie
tak
tak
tak
nie
tak
11
Rsnapshot
4m19s
4m28s
tak
tak
tak
tak
nie
nie
tak
nie
tak
nie
tak
nie
nie
tak
tak
nie
tak
12,5
Burp
11m9s
7m2s
tak
nie
tak
tak
tak
tak
tak
nie
tak
tak
nie
nie
tak
nie
tak
nie
tak
10,5
Duplicity
brak szyfrowania
16m48s
10m58s
tak
tak
nie
tak
nie
tak
tak
nie
nie
tak
nie
tak
tak
nie
tak
nie
tak
11
gpg
17m27s
15m3s
Duplicati
brak szyfrowania
20m28s
13m45s
nie
tak
nie
nie
nie
tak
tak
nie
nie
tak
nie
tak
tak
tak
tak
tak
tak
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
Zbackup
brak szyfrowania
40m3s
11m8s
tak
tak
nie
nie
nie
tak
tak
tak
nie
tak
nie
tak
tak
tak
nie
nie
nie
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
brak szyfrowania
4m7s
2m45s
tak
tak
tak
tak
tak
tak
tak
tak
tak
tak
nie
tak
tak
tak
tak
nie
tak
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
tak
tak
tak
tak
nie
tak
tak
tak
tak
tak
nie
tak
nie
tak
nie
tak
tak
15,5
UrBackup
8m21s
8m19s
tak
tak
tak
nie
tak
nie
tak
nie
tak
tak
nie
tak
tak
tak
tak
nie
tak
12
Amanda
9m3s
2m49s
tak
nie
nie
tak
tak
tak
tak
nie
tak
tak
tak
tak
tak
nie
tak
tak
tak
13
BackupPC
rsync
12m22s
7m42s
tak
nie
tak
tak
tak
tak
tak
nie
tak
nie
nie
tak
tak
nie
tak
nie
tak
10,5
tar
12m34s
12m15s
Legenda tabeli:
- Zielony, czas pracy krótszy niż pięć minut lub odpowiedź „Tak” (z wyjątkiem kolumny „Czy potrzebny klient-server?”), 1 punkt
- Żółty, czas pracy od pięciu do dziesięciu minut, 0.5 punktu
- Czerwony, czas pracy dłuższy niż dziesięć minut lub odpowiedź „Nie” (z wyjątkiem kolumny „Czy potrzebny klient-server?”), 0 punktów
Zgodnie z powyższą tabelą najprostszym, najszybszym i równocześnie wygodnym i potężnym narzędziem do tworzenia kopii zapasowych jest BorgBackup. Drugie miejsce zajął Restic, a pozostałe rozważane kandydaty uplasowały się mniej więcej równo, z różnicą jednego lub dwóch punktów na końcu.
Dziękuję wszystkim, którzy dotrwali do końca cyklu, zachęcam do omówienia opcji oraz propozycji własnych, jeśli takie są. W miarę dyskusji tabela może być uzupełniona.
Wynikiem cyklu będzie artykuł końcowy, w którym spróbujemy wyłonić idealne, szybkie i łatwe w zarządzaniu narzędzie do tworzenia kopii zapasowych, które umożliwi szybkie przywracanie kopii, a jednocześnie będzie wygodne i proste w konfiguracji oraz utrzymaniu.
Ogłoszenie
Kopie zapasowe, część 6: Porównanie narzędzi do tworzenia kopii zapasowych
Kopie zapasowe, część 7: Wnioski
Źródło: habr.com
