A cikkben a biztonsági mentési eszközök összehasonlítása fog történni, de először is érdemes megtudni, hogy ezek milyen gyorsan és jól kezelik az adatok helyreállítását a biztonsági mentésekből.
Az összehasonlítás egyszerűsítése érdekében a teljes biztonsági mentésből való helyreállítást fogjuk vizsgálni, annál is inkább, mivel ezt a működési módot minden jelölt támogatja. Az egyszerűség kedvéért az adatok már átlagolt formában kerülnek bemutatásra (több futtatás átlagos értéke). Az eredmények egy táblázatban lesznek összegyűjtve, amely tartalmazni fogja a lehetőségeket is: a webes felület meglétét, a beállítás és a használat egyszerűségét, a automatizálás lehetőségét, valamint a különböző kiegészítő funkciók meglétét (például az adatok integritásának ellenőrzése) stb. A grafikonok mutatni fogják a szerver terhelését, ahol az adatok alkalmazásra kerülnek (nem a biztonsági mentések tárolására szolgáló szerverek).
Adatok helyreállítása
Horgonyként az rsync és a tar fog szolgálni, mivel a legegyszerűbb biztonsági mentési szkriptek.
Az Rsync 4 perc 28 másodperc alatt megoldotta a tesztadat-készletet, bemutatva
ilyen terhelést.
A helyreállítási folyamat a biztonsági mentések tárolására szolgáló lemezes alrendszer korlátjába ütközött (fogazott grafikonok). Szintén egyértelműen látható egy mag terhelése különösebb problémák nélkül (alacsony iowait és softirq – a lemez és a hálózat esetében nincsenek problémák). Mivel a másik két program, nevezetesen a rdiff-backup és az rsnapshot, az rsyncre építkezik, és szintén az rsync-ot kínálja helyreállítási eszközként, - ezeknek körülbelül hasonló terhelési profiljuk és helyreállítási idejük lesz.
A Tar kicsivel gyorsabban,
2 perc 43 másodperc alatt teljesítette:
A rendszer teljes terhelése átlagosan 20%-kal magasabb volt a megnövekedett softirq miatt – a hálózati alrendszer működése megnövekedett költségeket okozott.
Ha a fájlt további tömörítésnek vetjük alá, a helyreállítási idő 3 perc 19 másodpercre nő ezzel
ilyen terheléssel a fő szerveren (kicsomagolás a fő szerveren):
A kibővítési folyamat mindkét processzort használja, mivel két folyamatot futtat. Összességében ez egy elvárt eredmény. Hasonló eredményt (3 perc 20 másodperc) kaptunk, amikor a gzip szerveroldali futtatását teszteltük a biztonsági mentésekkel, a fő szerveren a terhelési profil meglehetősen hasonló volt a tar gzip nélküli futtatásához (ld. az előző grafikont).
A rdiff-backup az utolsó készített biztonsági mentést a szokásos rsync segítségével lehet szinkronizálni (az eredmények hasonlóak lesznek), de a régebbi biztonsági mentések helyreállításához mindenképpen az rdiff-backup programot kell használni, amely 17 perc 17 másodperc alatt végezte el a helyreállítást, mutatva
ilyen terhelést:
Lehetséges, hogy ez volt a szándék, mindenesetre a sebesség korlátozására a szerzők . Maga a biztonsági mentés helyreállítása folyamat körülbelül egy mag kevesebb mint felét igényli, arányosan összehasonlítható teljesítménnyel (azaz 2-5-ször lassabb) a lemezen és a hálózaton az rsync-hez képest.
Rsnapshot helyreállításhoz a szokásos rsync használatát ajánlja, így az eredményei hasonlóak lesznek. Összességében ez így is történt.
Burp a biztonsági mentés helyreállítását 7 perc 2 másodperc alatt végrehajtotta,
ilyen terhelés mellett:
Elég gyorsan működött, és legalább sokkal kényelmesebb, mint a tiszta rsync: nem kell emlékezni semmilyen flagre, egyszerű és intuitív parancssori felület, beépített támogatás több példányhoz, — igaz, körülbelül kétszer lassabb. Ha az adatokat az utolsó készített biztonsági mentésből szükséges helyreállítani, használhatjuk az rsync-et, néhány apró megszorítással.
Hasonló sebességet és terhelést mutatott a program BackupPC az rsync adatátviteli mód bekapcsolásával, a biztonsági mentés kiterjesztését
7 perc 42 másodperc alatt végezte el:
Viszont az adatok tar-al való átvitelének módjában a BackupPC lassabban teljesített: 12 perc 15 másodperc alatt, miközben a processzor terhelés összességében alacsonyabb volt
másfél szer:
Duplicity titkosítás nélkül kicsit jobb eredményeket mutatott, a biztonsági másolat helyreállítása 10 perc 58 másodpercet vett igénybe. Ha a titkosítást a gpg segítségével aktiválják, a helyreállítási idő 15 percre és 3 másodpercre nő. A biztonsági másolatok tárolására szolgáló tároló létrehozásakor megadható az archívum mérete is, amelyet a bejövő adatok folyamának bontásakor használnak. Összességében a hagyományos merevlemezek esetében, valamint az egyszálú működési mód miatt, különösebb eltérés nem tapasztalható. Ez esetleg különbséget jelenthet eltérő blokk méretek esetén, amikor hibrid tárolókat használnak. A helyreállítás során a fő szerveren a terhelés a következő volt:
titkosítás nélkül
titkosítással
Duplicati összehasonlítható helyreállítási sebességet mutatott, 13 perc 45 másodperc alatt végzett. További körülbelül 5 percet vett igénybe az helyreállított adatok épségének ellenőrzése (összesen körülbelül 19 perc). A terhelés eközben
meglehetősen magas volt:
Amikor az aes titkosítást belső eszközökkel aktiválták, a helyreállítási idő 21 perc 40 másodpercre nőtt, és a processzorfelhasználás maximális volt (mindkét mag!) a helyreállítás alatt; az adatok ellenőrzése során csak egy szál volt aktív, amely egy processzormagot használt. Az adatok ellenőrzése a helyreállítás után ugyanannyi 5 percet vett igénybe (összesen közel 27 perc).
Eredmény
A duplicati egy kicsit gyorsabban végezte el a helyreállítást külső gpg program használatával titkosításkor, de összességében a korábbi módtól való eltérés minimális. A folyamat időtartama 16 perc 30 másodperc volt, az adatok ellenőrzése 6 percet vett igénybe. A terhelés pedig
a következő volt:
AMANDA, amely a tar-t használta, 2 perc 49 másodperc alatt végzett, ami gyakorlatilag nagyon közel van a hagyományos tar-hoz. A rendszer terhelése alapvetően
ugyanaz:
A biztonsági másolat helyreállítása a zbackup eszközeivel a következő eredményeket produkálta:
titkosítás, lzma tömörítés
A működési idő 11 perc 8 másodperc
aes titkosítás, lzma tömörítés
A működési idő 14 perc
aes titkosítás, lzo tömörítés
A működési idő 6 perc 19 másodperc
Összességében nem rossz. Minden a biztonsági mentési szerver proceszorszámában dől el, ami jól látható a program különböző tömörítőkkel végzett működési idejében. A biztonsági mentési szerverről egy szokásos tar indult, tehát ha ehhez viszonyítjuk — a visszaállítás háromszor lassabb. Lehet, hogy érdemes ellenőrizni a teljesítményt több szálon, több mint két szál használatával.
BorgBackup a titkosítás nélküli módban kicsit lassabb volt, mint a tar, 2 perc 45 másodperc alatt, azonban, ellentétben a tar-ral, lehetőség nyílt a tároló deduplikációjára. Az e közben fellépő terhelés
a következő volt:
Ha aktiváljuk a blake alapú titkosítást, a biztonsági mentés visszaállításának sebessége kicsit lelassul. A visszaállítási idő ebben a módban 3 perc 19 másodperc, a terhelés pedig a következő:
ilyen volt:
Az aes titkosítás kicsit lassabban működik, a visszaállítás ideje 3 perc 23 másodperc, a terhelés lényegében
nem változott:
Mivel a Borg képes több szálon működni — a processzor terhelése maximális, ugyanakkor az extra funkciók aktiválása csak a működési időt növeli. Nyilvánvaló, hogy érdemes lenne a több szálas működést a zbackup-hoz hasonlóan megvizsgálni.
Restic kicsit lassabban birkózott meg a visszaállítással, a működési ideje 4 perc 28 másodperc volt. A terhelés ekkor
így nézett ki:
Nyilvánvaló, hogy a visszaállítási folyamat több szálon dolgozik, de a hatékonysága nem olyan magas, mint a BorgBackup-nál, de az időben összehasonlítható a szokásos rsync-kel.
A segítségével UrBackup az adatok visszaállítása 8 perc 19 másodperc alatt valósult meg, a terhelés pedig
a következő volt:
Még mindig láthatóan nem volt túl magas, még a tar-hoz képest is alacsonyabb. Helyenként kiugrások voltak, de nem haladták meg egy mag terhelését sem.
A kritériumok kiválasztása és indoklása a összehasonlításhoz
Amint azt egy korábbi cikkben említettük, a biztonsági mentési rendszernek a következő kritériumoknak kell megfelelnie:
- Könnyű használat
- Univerzalitás
- Stabilitás
- Gyorsaság
Érdemes részletesebben megvizsgálni minden egyes pontot.
Könnyű működés
A legjobb, ha van egy gomb, hogy "Minden jól csinálva legyen", de ha a valódi programokra gondolunk — a legkényelmesebb egy bizonyos megszokott és standard működési elv.
A legtöbb felhasználónak valószínűleg jobb lenne, ha nem kellene megjegyeznie rengeteg CLI kulcsot, beállítania különféle, gyakran nehezen érthető opciókat weben vagy TUI-n, és értesítéseket beállítania a sikertelen működésről. Ide tartozik a meglévő infrastruktúrába való könnyű integráció lehetősége a biztonsági mentési megoldás számára, valamint a biztonsági másolat készítésének automatizálása. Itt van a lehetőség csomagkezelőn keresztüli telepítésre, vagy egy-két parancsot használva, mint a „letöltés és kicsomagolás”. curl link | sudo bash — bonyolult módszer, mivel ellenőrizni kell, hogy mi érkezik a linken.
Például a megvizsgált jelöltek közül a legegyszerűbb megoldás a burp, rdiff-backup és restic, amelyek emlékezetbarát kulcsokat használnak a különböző működési módokhoz. Kicsit bonyolultabb a borg és a duplicity. A legbonyolultabb az AMANDA volt. A többiek használhatóság szempontjából valahol a középúton helyezkednek el. Bármi is legyen, ha több mint 30 másodpercbe telik elolvasni a felhasználói kézikönyvet, vagy ha Google-be vagy más keresőbe kell menni, és hosszú help szöveget kell átfutni — a megoldás bonyolult.
A megvizsgált jelöltek egy része automatikusan tud üzenetet küldeni e-mailben jabberen, míg mások a beállított rendszert értesítéseire támaszkodnak. A bonyolultabb megoldások esetében azonban gyakran nem teljesen nyilvánvalóak az értesítési beállítások. Bármi legyen is, ha a biztonsági mentési program nem nullát ad vissza, amit a rendszerszolgáltatás helyesen értelmez, hogy értesítést küldjön a rendszergazdának vagy azonnal a nyomonkövetésbe — a helyzet egyszerű. Azonban ha a biztonsági mentési rendszer, amely nem a biztonsági mentések kiszolgálóján működik, nem tud nyilvánvaló módon jelezni a problémáról beállítás nélkül — a bonyolultság már túlzó. Mindazonáltal a figyelmeztetések és egyéb üzenetek kiadása csak a webes felületen vagy a naplóban — rossz gyakorlat, mivel a legtöbb esetben figyelmen kívül hagyják őket.
Ami az automatizálást illeti — egy egyszerű program képes olvasni a környezeti változókat, amelyek meghatározzák a működési módját, vagy fejlett CLI-jel rendelkezik, amely teljes mértékben képes tükrözni a webes felületen végzett működését. Ide tartozik a folyamatok párhuzamos végrehajtásának lehetősége, valamint a bővíthetőség.
Univerzalitás
Részben átfedésben van az előző fejezettel az automatizálás terén, nem kellett volna különösebb probléma lenni a biztonsági mentési folyamat integrálásával a meglévő infrastruktúrába.
Érdemes megjegyezni, hogy a nem szabványos portok (kivéve a webes interfészt) használata, a titkosítás nem szabványos módon, az adatok cseréje nem szabványos protokollal - az nem univerzális megoldás jelei. A legtöbb jelölt így vagy úgy rendelkezik ezekkel nyilvánvaló okból: az egyszerűség és az univerzalitás általában nem kompatibilisek. Kivételként ott van a burp, de vannak mások is.
Az egyik jel, hogy lehetőség van rendes ssh használatára.
Működési sebesség
A legellentmondásosabb és legvitatottabb pont. Egyrészt - elindították a folyamatot, működött a lehető leggyorsabban és nem zavarja az alapvető feladatokat. Másrészt - a forgalom és a processzorra nehezedő nyomás ugrása a biztonsági mentés idején. Érdemes megjegyezni, hogy a leggyorsabb biztonsági másolatkészítő programok általában a legszegényebbek a felhasználók számára fontos funkciókban. Ismétlem: ha egy nyomorúságos szöveges fájlt, amely néhány tucat bájt méretű jelszóval rendelkezik, a teljes szolgáltatás miatt túl kell nézni, (igen, tudom, hogy itt a biztonsági mentési folyamat gyakran nem hibás), és fokozatosan kell olvasni az összes fájlt a tárolóban vagy egy teljes archívumot kell kibővíteni - akkor a biztonsági mentési rendszer egyáltalán nem gyors. Egy másik pont, ami gyakran akadályt jelent - a biztonsági másolat helyreállításának sebessége az archívumból. Itt egyértelmű előnyben vannak azok, akik egyszerűen csak másolhatják vagy áthelyezhetik a fájlokat a megfelelő helyre különösebb manipuláció nélkül (például rsync), de a problémát általában szervezési módon vagy empirikus úton kell megoldani: mérni a biztonsági másolat helyreállításának idejét és nyíltan tájékoztatni a felhasználókat erről.
Stabilitás
Úgy kell érteni, hogy egyrészt lehetőséget kell adni a biztonsági mentés visszaállítására bármilyen módon, másrészt pedig ellenállónak kell lennie a különböző problémákkal szemben: hálózati megszakadás, lemez meghibásodása, a tároló egy részének törlése.
A biztonsági mentési eszközök összehasonlítása
A másolat létrehozásának ideje
A másolat helyreállításának ideje
Egyszerű telepítés
Egyszerű beállítás
Egyszerű használat
Egyszerű automatizálás
Szükséges a kliens-szerver?
A tárhely integritásának ellenőrzése
Differenciális másolatok
Munkavégzés pipe-on keresztül
Univerzalitás
Önállóság
A tárhely átláthatósága
Titkosítás
Tömörítés
Deduplikálás
Webes felület
Felhőbe tölteni
Windows támogatás
Pontszám
Az Rsync
4p15mp
4p28mp
igen
nem
nem
nem
igen
nem
nem
igen
nem
igen
igen
nem
nem
nem
nem
nem
igen
6
A Tar
tiszta
3p12mp
2p43mp
igen
nem
nem
nem
nem
nem
igen
igen
nem
igen
nem
nem
nem
nem
nem
nem
igen
8,5
gzip
9p37mp
3p19mp
igen
Rdiff-backup
16p26mp
17p17mp
igen
igen
igen
igen
igen
nem
igen
nem
igen
nem
igen
nem
igen
igen
igen
nem
igen
11
Rsnapshot
4p19mp
4p28mp
igen
igen
igen
igen
nem
nem
igen
nem
igen
nem
igen
nem
nem
igen
igen
nem
igen
12,5
Burp
11p9mp
7p2mp
igen
nem
igen
igen
igen
igen
igen
nem
igen
igen
nem
nem
igen
nem
igen
nem
igen
10,5
Duplicity
nincs titkosítás
16p48mp
10p58mp
igen
igen
nem
igen
nem
igen
igen
nem
nem
igen
nem
igen
igen
nem
igen
nem
igen
11
gpg
17p27mp
15p3mp
Duplicati
nincs titkosítás
20m28s
13p45mp
nem
igen
nem
nem
nem
igen
igen
nem
nem
igen
nem
igen
igen
igen
igen
igen
igen
11
aes
29p41mp
21p40mp
gpg
26p19mp
16m30s
Zbackup
nincs titkosítás
40p3mp
11p8mp
igen
igen
nem
nem
nem
igen
igen
igen
nem
igen
nem
igen
igen
igen
nem
nem
nem
10
aes
42p0mp
14p1mp
aes+lzo
18p9mp
6p19mp
BorgBackup
nincs titkosítás
4p7mp
2p45mp
igen
igen
igen
igen
igen
igen
igen
igen
igen
igen
nem
igen
igen
igen
igen
nem
igen
16
aes
4p58mp
3p23mp
blake2
4p39mp
3p19mp
Restic
5p38mp
4p28mp
igen
igen
igen
igen
nem
igen
igen
igen
igen
igen
nem
igen
nem
igen
nem
igen
igen
15,5
UrBackup
8p21mp
8p19mp
igen
igen
igen
nem
igen
nem
igen
nem
igen
igen
nem
igen
igen
igen
igen
nem
igen
12
Amanda
9m3s
2p49mp
igen
nem
nem
igen
igen
igen
igen
nem
igen
igen
igen
igen
igen
nem
igen
igen
igen
13
BackupPC
rsync
12p22mp
7p42mp
igen
nem
igen
igen
igen
igen
igen
nem
igen
nem
nem
igen
igen
nem
igen
nem
igen
10,5
tar
12p34mp
12p15mp
A táblázat legendája:
- Zöld, működési idő kevesebb mint öt perc, vagy válasz „Igen” (kivéve a „Szükséges a kliens-szerver?” oszlop), 1 pont
- Sárga, működési idő öt-tíz perc, 0,5 pont
- Piros, működési idő több mint tíz perc, vagy válasz „Nem” (kivéve a „Szükséges a kliens-szerver?” oszlop), 0 pont
A fenti táblázat alapján a legegyszerűbb, leggyorsabb és egyben kényelmes, erőteljes eszköz az adatmentéshez a BorgBackup. A második helyet a Restic szerezte meg, a többi vizsgált jelölt körülbelül azonos pontszámot kapott az ízlelés végén, egy-két pont eltéréssel.
Köszönöm mindazoknak, akik a ciklus végéig eljutottak, javaslom, hogy beszéljük meg a lehetőségeket, és tegyük fel saját javaslatainkat, ha vannak. A vita folyamatában a táblázat kiegészíthető.
A ciklus végső eredménye egy befejező cikk lesz, amelyben megpróbáljuk megfogalmazni az ideális, gyors és kezelhető adatmentési eszközt, amely lehetővé teszi az adatok gyors helyreállítását, miközben a beállítás és az üzemeltetés is kényelmes és egyszerű.
Bejelentés
Biztonsági mentés, 6. rész: A biztonsági mentési eszközök összehasonlítása
Biztonsági mentés, 7. rész: Következtetések
Forrás: habr.com
