W tym artykule omówimy oprogramowanie do tworzenia kopii zapasowych, które dzieląc strumień danych na osobne komponenty (porcje) tworzy repozytorium.
Komponenty repozytorium można dalej kompresować i szyfrować, a co najważniejsze – podczas wielokrotnych procesów tworzenia kopii zapasowych – ponownie wykorzystywać.
Kopia zapasowa w takim repozytorium to nazwany łańcuch komponentów połączonych ze sobą, na przykład w oparciu o różne funkcje skrótu.
Istnieje kilka podobnych rozwiązań, skupię się na 3: zbackup, borgbackup i restic.
Oczekiwane rezultaty
Ponieważ wszyscy wnioskodawcy w ten czy inny sposób wymagają utworzenia repozytorium, jednym z najważniejszych czynników będzie oszacowanie wielkości repozytorium. Idealnie, jego rozmiar nie powinien przekraczać 13 GB zgodnie z przyjętą metodologią, a nawet mniej - pod warunkiem dobrej optymalizacji.
Wysoce pożądana jest również możliwość bezpośredniego tworzenia kopii zapasowych plików, bez korzystania z archiwizatorów takich jak tar, a także praca z ssh/sftp bez dodatkowych narzędzi, takich jak rsync i sshfs.
Zachowanie podczas tworzenia kopii zapasowych:
- Rozmiar repozytorium będzie równy rozmiarowi zmian lub mniejszy.
- Podczas korzystania z kompresji i/lub szyfrowania oczekuje się dużego obciążenia procesora, a dość duże obciążenie sieci i dysku jest prawdopodobne, jeśli proces archiwizacji i/lub szyfrowania jest uruchomiony na serwerze przechowywania kopii zapasowych.
- Jeśli repozytorium jest uszkodzone, prawdopodobny jest opóźniony błąd zarówno podczas tworzenia nowych kopii zapasowych, jak i podczas próby ich przywrócenia. Konieczne jest zaplanowanie dodatkowych działań zapewniających integralność repozytorium lub wykorzystanie wbudowanych narzędzi sprawdzających jego integralność.
Praca z tarem jest traktowana jako wartość odniesienia, jak pokazano w jednym z poprzednich artykułów.
Testuję zbackup
Ogólny mechanizm zbackup polega na tym, że program znajduje w wejściowym strumieniu danych obszary zawierające te same dane, a następnie opcjonalnie je kompresuje i szyfruje, zapisując każdy obszar tylko raz.
Deduplikacja wykorzystuje 64-bitową funkcję skrótu pierścieniowego z przesuwanym oknem do sprawdzania dopasowań bajt po bajcie z istniejącymi blokami danych (podobnie jak implementuje to rsync).
Do kompresji używane są wielowątkowe lzma i lzo, a do szyfrowania aes. Najnowsze wersje posiadają możliwość usunięcia w przyszłości starych danych z repozytorium.
Program napisany jest w języku C++ z minimalnymi zależnościami. Autor najwyraźniej zainspirował się unix-wayem, więc program przyjmuje dane na stdin podczas tworzenia kopii zapasowych, tworząc podobny strumień danych na stdout podczas przywracania. Dlatego zbackup może być używany jako bardzo dobry „element konstrukcyjny” podczas pisania własnych rozwiązań do tworzenia kopii zapasowych. Na przykład autor artykułu używa tego programu jako głównego narzędzia do tworzenia kopii zapasowych komputerów domowych od około 2014 roku.
Strumień danych będzie zwykłym plikiem tar, chyba że określono inaczej.
Zobaczmy, jakie są wyniki:
Praca została sprawdzona w 2 opcjach:
- tworzone jest repozytorium i uruchamiane jest zbackup na serwerze z danymi źródłowymi, następnie zawartość repozytorium jest przesyłana na serwer magazynu kopii zapasowych.
- na serwerze magazynu kopii zapasowych tworzone jest repozytorium, zbackup jest uruchamiany przez ssh na serwerze magazynu kopii zapasowych, a dane są do niego wysyłane za pośrednictwem potoku.
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 serwera oryginalnymi danymi było następujące (pokazano przykład z lzma; z lzo obraz był mniej więcej taki sam, ale udział rsync był w przybliżeniu jedną czwartą czasu):
Oczywiste jest, że taki proces tworzenia kopii zapasowych nadaje się tylko w przypadku stosunkowo rzadkich i małych zmian. Wysoce wskazane jest również ograniczenie zbackup do 1 wątku, w przeciwnym razie nastąpi bardzo duże obciążenie procesora, ponieważ Program bardzo dobrze radzi sobie z pracą w wielu wątkach. Obciążenie dysku było niewielkie, co w sumie nie byłoby zauważalne w przypadku nowoczesnego podsystemu dyskowego opartego na dyskach SSD. Wyraźnie widać też rozpoczęcie procesu synchronizacji danych repozytorium ze zdalnym serwerem, prędkość działania jest porównywalna ze zwykłym rsync i zależy od wydajności podsystemu dyskowego serwera magazynu kopii zapasowych. Wadą tego podejścia jest przechowywanie lokalnego repozytorium i w efekcie duplikacja danych.
Bardziej interesująca i mająca zastosowanie w praktyce jest druga opcja, uruchamiająca zbackup bezpośrednio na serwerze magazynu kopii zapasowych.
Najpierw sprawdzimy działanie bez użycia szyfrowania za pomocą kompresora lzma:
Czas trwania każdego uruchomienia testowego:
Uruchom 1
Uruchom 2
Uruchom 3
39m45
40m20
40m3
7m36
8m3
7m48
15m35
15m48
15m38
Jeśli włączysz szyfrowanie za pomocą aes, wyniki będą dość zbliżone:
Czas pracy na tych samych danych, z szyfrowaniem:
Uruchom 1
Uruchom 2
Uruchom 3
43m40
44m12
44m3
8m3
8m15
8m12
15m0
15m40
15m25
Jeśli szyfrowanie jest połączone z kompresją przy użyciu lzo, wygląda to tak:
godziny:
Uruchom 1
Uruchom 2
Uruchom 3
18m2
18m15
18m12
5m13
5m24
5m20
8m48
9m3
8m51
Rozmiar powstałego repozytorium był stosunkowo taki sam i wynosił 13 GB. Oznacza to, że deduplikacja działa poprawnie. Również na już skompresowanych danych użycie lzo daje zauważalny efekt; pod względem całkowitego czasu działania zbackup jest bliski duplikacji/duplikacji, ale pozostaje w tyle za tymi opartymi na librsync 2-5 razy.
Korzyści są oczywiste – oszczędność miejsca na serwerze przechowywania kopii zapasowych. Jeśli chodzi o narzędzia do sprawdzania repozytoriów, autor zbackup ich nie udostępnia; zaleca się korzystanie z macierzy dyskowej odpornej na uszkodzenia lub dostawcy chmury.
Ogólnie bardzo dobre wrażenie, mimo że projekt stoi w miejscu już jakieś 3 lata (ostatnia prośba o dodanie funkcji była jakiś rok temu, ale bez odzewu).
Testuję borgbackup
Borgbackup to rozwidlenie strychu, kolejny system podobny do zbackup. Napisany w Pythonie, posiada listę możliwości podobną do zbackup, ale dodatkowo może:
- Montuj kopie zapasowe za pomocą bezpiecznika
- Sprawdź zawartość repozytorium
- Pracuj w trybie klient-serwer
- Używaj różnych kompresorów danych, a także heurystycznego określania typu pliku podczas jego kompresji.
- 2 opcje szyfrowania, aes i blake
- Wbudowane narzędzie do
kontrole wydajności
borgbackup benchmark crud ssh://backup_server/repo/path lokal_katalog
Wyniki były następujące:
CZ-BIG 96.51 MB/s (10 100.00 MB plików zerowych: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB plików zerowych: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB plików zerowych: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB plików zerowych: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB losowych plików: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB losowych plików: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB losowych plików: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB losowych plików: 13.77 s)
CZ-ŚREDNI 108.59 MB/s (1000 1.00 MB plików zerowych: 9.21 s)
RZ-ŚREDNI 76.16 MB/s (1000 1.00 MB plików zerowych: 13.13 s)
UZ-ŚREDNI 331.27 MB/s (1000 1.00 MB plików zerowych: 3.02 s)
DZ-ŚREDNI 387.36 MB/s (1000 1.00 MB plików zerowych: 2.58 s)
CR-ŚREDNI 37.80 MB/s (1000 1.00 MB losowych plików: 26.45 s)
RR-ŚREDNI 68.90 MB/s (1000 1.00 MB losowych plików: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB losowych plików: 2.88 s)
DR-ŚREDNI 48.80 MB/s (1000 1.00 MB losowych plików: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB plików zerowych: 8.53 s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB plików zerowych: 3.07 s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB plików zerowych: 5.16 s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB plików zerowych: 2.97 s)
CR-SMALL 6.85 MB/s (10000 10.00 kB plików losowych: 14.60 s)
RR-SMALL 31.27 MB/s (10000 10.00 kB plików losowych: 3.20 s)
UR-SMALL 12.28 MB/s (10000 10.00 kB plików losowych: 8.14 s)
DR-SMALL 18.78 MB/s (10000 10.00 kB plików losowych: 5.32 s)
Podczas testowania do określenia typu pliku zostanie użyta heurystyka kompresji (kompresja automatyczna), a wyniki będą następujące:
Na początek sprawdźmy jak to działa bez szyfrowania:
godziny:
Uruchom 1
Uruchom 2
Uruchom 3
4m6
4m10
4m5
56s
58s
54s
1m26
1m34
1m30
Jeśli włączysz autoryzację repozytorium (tryb uwierzytelniony), wyniki będą zbliżone:
godziny:
Uruchom 1
Uruchom 2
Uruchom 3
4m11
4m20
4m12
1m0
1m3
1m2
1m30
1m34
1m31
Po włączeniu szyfrowania aes wyniki nie uległy znacznemu pogorszeniu:
Uruchom 1
Uruchom 2
Uruchom 3
4m55
5m2
4m58
1m0
1m2
1m0
1m49
1m50
1m50
A jeśli zmienisz aes na blake, sytuacja ulegnie całkowitej poprawie:
godziny:
Uruchom 1
Uruchom 2
Uruchom 3
4m33
4m43
4m40
59s
1m0
1m0
1m38
1m43
1m40
Podobnie jak w przypadku zbackup, wielkość repozytorium wyniosła 13 GB, a nawet trochę mniej, czego się powszechnie oczekuje. Byłem bardzo zadowolony z czasu działania, jest on porównywalny z rozwiązaniami opartymi na librsync, zapewniającymi znacznie szersze możliwości. Byłem również zadowolony z możliwości ustawienia różnych parametrów poprzez zmienne środowiskowe, co daje bardzo poważną przewagę podczas korzystania z borgbackup w trybie automatycznym. Byłem również zadowolony z obciążenia podczas tworzenia kopii zapasowych: sądząc po obciążeniu procesora, borgbackup działa w 1 wątku.
Podczas korzystania z niego nie było żadnych szczególnych wad.
testy restrykcyjne
Pomimo tego, że restic jest rozwiązaniem dość nowym (pierwszych 2 kandydatów było znanych jeszcze w 2013 roku i starszych), ma całkiem niezłe parametry. Napisane w Go.
W porównaniu z zbackup dodatkowo daje:
- Sprawdzenie integralności repozytorium (w tym sprawdzenie części).
- Ogromna lista obsługiwanych protokołów i dostawców do przechowywania kopii zapasowych, a także obsługa rclone - rsync dla rozwiązań chmurowych.
- Porównanie 2 kopii zapasowych ze sobą.
- Montaż repozytorium za pomocą bezpiecznika.
Ogólnie rzecz biorąc, lista funkcji jest dość zbliżona do borgbackup, w niektórych miejscach więcej, w innych mniej. Jedną z funkcji jest to, że nie ma możliwości wyłączenia szyfrowania, dlatego kopie zapasowe będą zawsze szyfrowane. Zobaczmy w praktyce, co da się wycisnąć z tego oprogramowania:
Wyniki były następujące:
godziny:
Uruchom 1
Uruchom 2
Uruchom 3
5m25
5m50
5m38
35s
38s
36s
1m54
2m2
1m58
Wyniki wydajności są również porównywalne z rozwiązaniami opartymi na rsync i ogólnie bardzo zbliżone do borgbackup, ale obciążenie procesora jest wyższe (działa wiele wątków) i jest piłokształtne.
Najprawdopodobniej program jest ograniczony wydajnością podsystemu dyskowego na serwerze przechowywania danych, tak jak miało to już miejsce w przypadku rsync. Rozmiar repozytorium wynosił 13 GB, podobnie jak zbackup czy borgbackup, nie było żadnych oczywistych wad korzystania z tego rozwiązania.
wyniki
Tak naprawdę wszyscy kandydaci osiągnęli podobne wyniki, ale przy różnych cenach. Borgbackup spisał się najlepiej, restic był trochę wolniejszy, zbackup chyba nie warto zaczynać używać,
a jeśli jest już używany, spróbuj zmienić go na borgbackup lub restic.
odkrycia
Najbardziej obiecujące rozwiązanie wydaje się być restrykcyjne, ponieważ... to on ma najlepszy stosunek możliwości do prędkości działania, ale na razie nie spieszmy się z wnioskami ogólnymi.
Borgbackup w zasadzie nie jest gorszy, ale zbackup chyba lepiej zastąpić. To prawda, że zbackup może być nadal używany, aby zapewnić działanie reguły 3-2-1. Na przykład oprócz funkcji tworzenia kopii zapasowych opartych na (lib) rsync.
Zapowiedź
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