W tym artykule omówimy narzędzia programowe do tworzenia kopii zapasowych, które, dzieląc dane na indywidualne komponenty (chunks), tworzą repozytorium.
Komponenty repozytorium mogą być dodatkowo kompresowane i szyfrowane, a co najważniejsze — podczas kolejnych procesów tworzenia kopii zapasowych — mogą być wielokrotnie wykorzystywane.
Kopia zapasowa w takim repozytorium to nazwany łańcuch powiązanych ze sobą komponentów, na przykład oparty na różnych funkcjach skrótu hash.
Istnieje kilka takich rozwiązań, skupię się na 3: zbackup, borgbackup i restic.
Oczekiwane wyniki
Ponieważ wszyscy kandydaci w mniejszym lub większym stopniu wymagają utworzenia repozytorium, jednym z najważniejszych czynników będzie ocena rozmiaru repozytorium. W idealnym przypadku jego rozmiar powinien wynosić nie więcej niż 13 GB zgodnie z przyjętą metodą, a nawet mniej — przy dobrej optymalizacji.
Bardzo pożądane jest również, aby móc tworzyć kopie zapasowe plików bezpośrednio, bez użycia archiwizatorów takich jak tar, oraz korzystać z ssh/sftp bez dodatkowych narzędzi, takich jak rsync i sshfs.
Zachowanie przy tworzeniu kopii zapasowych:
- Rozmiar repozytorium będzie równy rozmiarowi zmian lub mniejszy.
- 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 podsystemu dyskowego, jeśli proces archiwizacji i/lub szyfrowania będzie działał na serwerze przechowującym kopie zapasowe.
- Jeśli uszkodzimy repozytorium — prawdopodobna jest opóźniona awaria zarówno podczas tworzenia nowych kopii zapasowych, jak i podczas próby przywracania. Należy zaplanować dodatkowe środki zapewniające integralność repozytorium lub skorzystać z wbudowanych narzędzi do sprawdzania jego integralności.
Jako wartość odniesienia przyjęto pracę z tar, jak pokazano w jednym z wcześniejszych artykułów.
Testowanie zbackup
Ogólny mechanizm działania zbackup polega na tym, że program znajduje w strumieniu danych dostarczanym na wejściu obszary zawierające te same dane, a następnie opcjonalnie je kompresuje, szyfruje, zachowując każdy obszar tylko raz.
Do deplikacji używana jest 64-bitowa funkcja skrótu z pierścieniem o zmiennym oknie do bajtowego sprawdzania zgodności z już istniejącymi blokami danych (podobnie jak w rsync).
Do kompresji używane są lzma i lzo w wielowątkowym wykonaniu, a do szyfrowania — aes. W najnowszych wersjach istnieje możliwość w przyszłości usuwania starych danych z repozytorium.
Program jest napisany w C++ z minimalnymi zależnościami. Autor najwyraźniej inspirował się unix-way, dlatego program przyjmuje dane na stdin podczas tworzenia kopii zapasowych, wydając odpowiedni strumień danych w stdout podczas przywracania. W ten sposób, zbackup można wykorzystać jako dość solidny 'klock' przy tworzeniu własnych rozwiązań do tworzenia kopii zapasowych. Na przykład, dla autora artykułu ten program jest głównym narzędziem do tworzenia kopii zapasowych dla komputerów domowych od około 2014 roku.
Jako strumień danych będzie używany standardowy tar, jeśli nie powiedziano inaczej.
Zobaczymy, jakie będą wyniki:
Testowanie działania odbywało się w 2 wariantach:
- tworzy się repozytorium i uruchamia zbackup na serwerze z danymi źródłowymi, a następnie zawartość repozytorium zostaje przesłana na serwer przechowywania kopii zapasowych.
- tworzy się repozytorium na serwerze przechowywania kopii zapasowych, uruchamia się zbackup przez ssh na serwerze przechowywania kopii zapasowych, któremu przez pipe wydawane są dane.
Wyniki pierwszej opcji były następujące: 43m11s — przy użyciu niezaszyfrowanego repozytorium i kompresora lzma, 19m13s — przy wymianie kompresora na lzo.
Obciążenie na serwerze z danymi źródłowymi było następujące (pokazany przykład z lzma, z lzo obraz był podobny, ale część rsync wynosiła około jednej czwartej czasu):
Wyraźnie widać, że taki proces tworzenia kopii zapasowej nadaje się tylko przy stosunkowo rzadkich i niewielkich zmianach. Wysoce zaleca się także ograniczenie pracy zbackup do 1 wątku, w przeciwnym razie obciążenie procesora będzie dość wysokie, ponieważ program bardzo dobrze potrafi działać w wielu wątkach. Obciążenie dysku było niewielkie, co w przypadku nowoczesnego systemu dyskowego opartego na SSD będzie w ogóle niezauważalne. Również wyraźnie widać rozpoczęcie procesu synchronizacji danych repozytorium na zdalnym serwerze, a prędkość pracy jest porównywalna z zwykłym rsync i napotyka na wydajność systemu dyskowego serwera przechowywania kopii zapasowych. Minusem podejścia jest przechowywanie lokalnego repozytorium i, co za tym idzie, — duplikacja danych.
Bardziej interesującą i praktyczną opcją jest drugi wariant uruchomienia zbackup bezpośrednio na serwerze przechowywania kopii zapasowych.
Na początek sprawdzimy działanie bez użycia szyfrowania z kompresorem lzma:
Czas pracy każdego testu:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Jeśli aktywujemy szyfrowanie z zastosowaniem aes, wyniki są wystarczająco zbliżone:
Czas pracy na tych samych danych ze szyfrowaniem:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Jeśli połączymy szyfrowanie z kompresją w lzo, otrzymujemy takie wyniki:
Czas pracy:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Rozmiar wynikowego repozytorium był stosunkowo jednorodny i wynosił 13 GB. Oznacza to, że deduplikacja działa poprawnie. Również na już skompresowanych danych zastosowanie lzo przynosi zauważalny efekt, a całkowity czas pracy zbackup zbliża się do duplicity/duplicati, pozostając jednak z tyłu w porównaniu do systemów opartych na librsync od 2 do 5 razy.
Zalety są oczywiste — oszczędność miejsca na dysku na serwerze przechowywania kopii zapasowych. Jeśli chodzi o narzędzia do weryfikacji repozytorium — autor zbackup ich nie przewidział, zaleca się korzystanie z rozwiązań RAID lub dostawcy chmurowego.
Ogólnie rzecz biorąc, wywarło to dość dobre wrażenie, mimo że projekt od około 3 lat stoi w miejscu (ostatnie żądanie funkcjonalności miało miejsce około roku temu, ale bez odpowiedzi).
Testowanie borgbackup
Borgbackup jest fork'iem attic, jeszcze jednego, podobnego do zbackup systemu. Napisany w Pythonie, ma podobną listę możliwości jak zbackup, ale dodatkowo potrafi:
- Montować kopie zapasowe przez fuse
- Weryfikować zawartość repozytorium
- Pracować w trybie klient-serwer
- Używać różnych kompresorów dla danych, a także heurystycznie określać typ pliku przy kompresji.
- 2 warianty szyfrowania, aes i blake
- Wbudowane narzędzie do
sprawdzania wydajności
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Wyniki okazały się następujące:
C-Z-BIG 96.51 MB/s (10 100.00 MB pliki zerowe: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB pliki zerowe: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB pliki zerowe: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB pliki zerowe: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB pliki losowe: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB pliki losowe: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB pliki losowe: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB pliki losowe: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB pliki zerowe: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB pliki zerowe: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB pliki zerowe: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB pliki zerowe: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB pliki losowe: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB pliki losowe: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB pliki losowe: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB pliki losowe: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB plików zerowych: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB plików zerowych: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB plików zerowych: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB plików zerowych: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB plików losowych: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB plików losowych: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB plików losowych: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB plików losowych: 5.32s)
W teście używana będzie heurystyka przy kompresji z określeniem typu pliku (compression auto), a wyniki będą takie:
Na początek sprawdźmy działanie bez szyfrowania:
Czas pracy:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Jeśli włączysz autoryzację repozytorium (tryb authenticated), wyniki będą zbliżone:
Czas pracy:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Po włączeniu szyfrowania aes wyniki nie pogorszyły się znacząco:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
A jeśli zmienimy aes na blake, sytuacja zupełnie się poprawi:
Czas pracy:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Jak w przypadku z zbackup, rozmiar repozytorium wyniósł 13GB, a nawet trochę mniej, co w sumie było do przewidzenia. Czas pracy zaskoczył pozytywnie, jest porównywalny z rozwiązaniami opartymi na librsync, oferując znacznie szersze możliwości. Również możliwość parametryzacji przez zmienne środowiskowe daje istotną przewagę przy używaniu borgbackup w trybie automatycznym. Zaskoczyła także niska obciążenie przy tworzeniu kopii zapasowej: sądząc po obciążeniu procesora — borgbackup działa w 1 wątku.
Nie znaleziono szczególnych wad w użytkowaniu.
Testowanie restic
Pomimo że restic jest stosunkowo nowym rozwiązaniem (pierwsze 2 kandydaci były znane od 2013 roku i starsze), ma dość dobre właściwości. Napisany jest w Go.
W porównaniu z zbackup, dodatkowo oferuje:
- Sprawdzanie integralności repozytorium (w tym sprawdzanie po częściach).
- Ogromna lista obsługiwanych protokołów i dostawców do przechowywania kopii zapasowych oraz wsparcie dla rclone — rsync dla „chmurowych” rozwiązań.
- Porównanie 2 kopii zapasowych ze sobą.
- Montaż repozytorium przez fuse.
Ogólnie rzecz biorąc, lista możliwości jest dość podobna do borgbackup, czasami więcej, czasami mniej. Zaletą jest brak możliwości wyłączenia szyfrowania, co oznacza, że kopie zapasowe będą zawsze szyfrowane. Sprawdźmy w praktyce, co można osiągnąć z tego oprogramowania:
Wyniki okazały się takie:
Czas pracy:
Uruchomienie 1
Uruchomienie 2
Uruchomienie 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Wyniki pracy są porównywalne z rozwiązaniami opartymi na rsync i ogólnie zbliżone do borgbackup, ale obciążenie procesora jest wyższe (działa kilka wątków) i ma charakter ząbkowany.
Najprawdopodobniej program napotyka na ograniczenia wydajności podsystemu dyskowego na serwerze przechowującym dane, co już miało miejsce w przypadku rsync. Rozmiar repozytorium wyniósł 13 GB, jak w przypadku zbackup lub borgbackup, nie zaobserwowano istotnych wad w korzystaniu z tego rozwiązania.
Wyniki
W rzeczywistości wszyscy kandydaci mają podobne wyniki, ale różną cenę. Najlepiej zaprezentował się borgbackup, nieco wolniej działał restic, zbackup prawdopodobnie nie warto zaczynać stosować.
Jeżeli już jest używany, warto rozważyć migrację na borgbackup lub restic.
Wnioski
Najbardziej obiecującym rozwiązaniem wydaje się restic, ponieważ ma najlepszy stosunek możliwości do prędkości pracy, ale nie spieszmy się z ogólnymi wnioskami.
Borgbackup zasadniczo nie jest gorszy, natomiast zbackup prawdopodobnie warto zastąpić. Prawda jest taka, że dla spełnienia zasady 3-2-1 zbackup wciąż można wykorzystać, na przykład w połączeniu z narzędziami do tworzenia kopii zapasowych opartymi na (lib)rsync.
Ogłoszenie
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
