Tato poznámka k recenzi pokračuje
Recenze UrBackup.
Na žádost účastníka
V režimu plné zálohy byly získány následující výsledky:
Provozní doba:
První start
Druhý běh
Třetí spuštění
První test
8m20s
8m19s
8m24s
Druhý test
8m30s
8m34s
8m20s
Třetí test
8m10s
8m14s
8m12s
V režimu přírůstkové zálohy:
Provozní doba:
První start
Druhý běh
Třetí spuštění
První test
8m10s
8m10s
8m12s
Druhý test
3m50s
4m12s
3m34s
Třetí test
2m50s
2m35s
2m38s
Velikost úložiště byla v obou případech přibližně 14 GB, což ukazuje na fungující deduplikaci na straně serveru. Je třeba také poznamenat, že existuje nesoulad mezi časem vytvoření zálohy na serveru a na klientovi, což je z grafů poměrně dobře patrné a je to velmi příjemný bonus, protože webové rozhraní zobrazuje provozní dobu procesu zálohování na straně serveru bez zohlednění
stavu klienta. Obecně platí, že grafy pro úplnou a přírůstkovou kopii jsou nerozeznatelné. Jediný rozdíl je pravděpodobně v tom, jak je to řešeno na straně serveru. Potěšila mě i malá zátěž procesoru na redundantním systému.
Recenze BackupPC
Na žádost účastníka
V režimu vytváření úplných záloh pomocí rsync byly získány následující výsledky:
První start
Druhý běh
Třetí spuštění
První test
12m25s
12m14s
12m27s
Druhý test
7m41s
7m44s
7m35s
Třetí test
10m11s
10m0s
9m54s
Pokud používáte úplné zálohy a tar:
První start
Druhý běh
Třetí spuštění
První test
12m41s
12m25s
12m45s
Druhý test
12m35s
12m45s
12m14s
Třetí test
12m43s
12m25s
12m5s
V režimu přírůstkové zálohy jsem musel opustit tar, protože zálohy nebyly vytvořeny s tímto nastavením.
Výsledky vytváření přírůstkových záloh pomocí rsync jsou:
První start
Druhý běh
Třetí spuštění
První test
11m55s
11m50s
12m25s
Druhý test
2m42s
2m50s
2m30s
Třetí test
6m00s
5m35s
5m30s
Obecně má rsync mírnou rychlostní výhodu, rsync také pracuje se sítí ekonomičtěji. To může být částečně kompenzováno menším vytížením CPU s tar jako zálohovacím programem. Další výhodou rsync je, že pracuje s přírůstkovými kopiemi. Velikost úložiště při vytváření plných záloh je stejná, 16 GB, v případě přírůstkových kopií - 14 GB na běh, což znamená fungující deduplikaci.
AMANDA recenze
Na žádost účastníka
Výsledky testovacího běhu s tar jako archivátorem a povolenou kompresí jsou následující:
První start
Druhý běh
Třetí spuštění
První test
9m5s
8m59s
9m6s
Druhý test
0m5s
0m5s
0m5s
Třetí test
2m40s
2m47s
2m45s
Program plně zatěžuje jedno jádro procesoru, ale kvůli omezenému IOPS disku na straně serveru zálohování nemůže dosáhnout vysokých rychlostí přenosu dat. Obecně bylo nastavení trochu obtížnější než pro ostatní účastníky, protože autor programu nepoužívá ssh jako transport, ale implementuje podobné schéma s klíči, vytváří a udržuje plnohodnotnou CA. Klienta a záložní server je možné široce omezit: například pokud si navzájem nemohou zcela důvěřovat, můžete jako možnost zabránit serveru v zahájení obnovy zálohy nastavením hodnoty odpovídající proměnné na nulu v soubor nastavení. Pro správu je možné připojit webové rozhraní, ale obecně lze konfigurovaný systém plně automatizovat pomocí malých bash skriptů (nebo například SCM ansible). Existuje poněkud netriviální systém nastavení úložiště, což je zřejmě způsobeno podporou rozsáhlého seznamu různých zařízení pro ukládání dat (LTO kazety, pevné disky atd.). Za zmínku také stojí, že ze všech programů probíraných v tomto článku je AMANDA jediný, který dokázal detekovat přejmenování adresářů. Velikost úložiště na jedno spuštění byla 13 GB.
Oznámení
Zálohování Část 6: Porovnání nástrojů pro zálohování
Záloha Část 7: Závěry
Zdroj: www.habr.com