Ez a cikk olyan biztonsági mentési szoftverekkel foglalkozik, amelyek az adatfolyamot különálló összetevőkre (darabokra) bontva egy adattárat képeznek.
A repository komponensei tovább tömöríthetők és titkosíthatók, és ami a legfontosabb - ismételt mentési folyamatok során - újra felhasználhatók.
A biztonsági másolat egy ilyen tárolóban egy elnevezett lánc, amely össze van kapcsolva, például különféle hash függvények alapján.
Több hasonló megoldás is létezik, én a 3-ra koncentrálok: zbackup, borgbackup és restic.
Várható eredmények
Mivel ilyen vagy olyan módon minden jelentkezőnek szüksége van egy adattár létrehozására, az egyik legfontosabb tényező a repository méretének becslése lesz. Ideális esetben a mérete nem haladhatja meg a 13 GB-ot az elfogadott módszertan szerint, vagy még kevesebbet - jó optimalizálás mellett.
Az is nagyon kívánatos, hogy közvetlenül, archiválók, például tar használata nélkül készíthessünk biztonsági másolatot a fájlokról, valamint az ssh/sftp-vel további eszközök, például rsync és sshfs nélkül is dolgozhassunk.
Viselkedés a biztonsági mentések létrehozásakor:
- A tár mérete megegyezik a változtatások méretével, vagy kisebb.
- Tömörítés és/vagy titkosítás használatakor nagy CPU-terhelés várható, és meglehetősen nagy hálózati és lemezterhelés valószínű, ha az archiválási és/vagy titkosítási folyamat egy biztonsági mentési tárolókiszolgálón fut.
- Ha a lerakat megsérült, késleltetett hiba valószínű mind az új biztonsági mentések létrehozásakor, mind a visszaállítási kísérlet során. A repository integritásának biztosítására további intézkedéseket kell tervezni, vagy beépített eszközöket kell használni az integritás ellenőrzésére.
A kátránnyal végzett munka referenciaértéknek számít, amint azt az egyik előző cikkben bemutattuk.
A zbackup tesztelése
A zbackup általános mechanizmusa, hogy a program megkeresi a bemeneti adatfolyamban ugyanazokat az adatokat tartalmazó területeket, majd opcionálisan tömöríti és titkosítja azokat, így minden területet csak egyszer ment el.
A deduplikáció egy 64 bites gyűrűs hash függvényt használ csúszó ablakkal, hogy bájtról bájtra egyezik-e a meglévő adatblokkokkal (hasonlóan ahhoz, ahogyan az rsync megvalósítja).
A többszálú lzma és lzo a tömörítésre, az aes pedig a titkosításra szolgál. A legújabb verziók képesek a régi adatok törlésére a tárolóból a jövőben.
A program C++ nyelven íródott minimális függőséggel. A szerzőt láthatóan a unix-way ihlette, így a program biztonsági mentések készítésekor elfogadja az stdin-en lévő adatokat, visszaállításkor pedig hasonló adatfolyamot állít elő az stdout-on. Így a zbackup nagyon jó „építőelemként” használható saját biztonsági mentési megoldások írásakor. A cikk szerzője például körülbelül 2014 óta használja ezt a programot az otthoni gépek fő biztonsági mentési eszközeként.
Az adatfolyam normál tar lesz, hacsak másképp nem jelezzük.
Lássuk, mik az eredmények:
A munkát 2 opcióban ellenőrizték:
- létrejön egy repository, és a zbackup elindul a szerveren a forrásadatokkal, majd a tároló tartalma átkerül a mentési tárolókiszolgálóra.
- egy repository jön létre a mentési tárolókiszolgálón, a zbackup elindul ssh-n keresztül a mentési tárolószerveren, és az adatok csövön keresztül kerülnek elküldésre.
Az első opció eredménye a következő volt: 43m11s - titkosítatlan tároló és lzma kompresszor használatakor, 19m13s -kompresszor lzo-ra cserélésekor.
A szerver terhelése az eredeti adatokkal a következő volt (az lzma-val egy példa látható; az lzo-val körülbelül ugyanaz a kép volt, de az rsync aránya körülbelül negyede volt):
Nyilvánvaló, hogy egy ilyen biztonsági mentési folyamat csak viszonylag ritka és kis változtatásokra alkalmas. Szintén nagyon ajánlatos a zbackup-ot 1 szálra korlátozni, különben nagyon nagy CPU terhelés lesz, mert A program nagyon jól működik több szálon. A lemez terhelése kicsi volt, ami általában nem lenne észrevehető egy modern ssd alapú lemezalrendszerrel. Tisztán láthatja a lerakatadatok távoli szerverrel való szinkronizálási folyamatának kezdetét is; a működési sebesség a normál rsynchez hasonlítható, és a biztonsági mentési tárolószerver lemezalrendszerének teljesítményétől függ. Ennek a megközelítésnek a hátránya a helyi adattár tárolása, és ennek eredményeként az adatok megkettőzése.
Érdekesebb és a gyakorlatban is használhatóbb a második lehetőség, a zbackup futtatása közvetlenül a mentési tárolókiszolgálón.
Először is teszteljük a műveletet titkosítás használata nélkül az lzma tömörítővel:
Az egyes próbaüzemek lefutási ideje:
Indítsa el 1
Indítsa el 2
Indítsa el 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Ha engedélyezi a titkosítást az Aes használatával, az eredmények meglehetősen közel állnak:
Működési idő ugyanazon az adatokon, titkosítással:
Indítsa el 1
Indítsa el 2
Indítsa el 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Ha a titkosítást az lzo használatával kombinálják a tömörítéssel, akkor ez így néz ki:
Nyitva tartás:
Indítsa el 1
Indítsa el 2
Indítsa el 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Az így létrejövő adattár mérete viszonylag azonos volt, 13 GB-os. Ez azt jelenti, hogy a deduplikáció megfelelően működik. A már tömörített adatokon is az lzo használata érezhető hatást fejt ki, a teljes működési időt tekintve a zbackup közel áll a duplicity/duplicatihoz, de 2-5-ször elmarad a librsync alapútól.
Az előnyök nyilvánvalóak – lemezterület megtakarítása a biztonsági mentési tárolókiszolgálón. Ami a tárhely-ellenőrző eszközöket illeti, azokat a zbackup szerzője nem biztosítja, hibatűrő lemeztömb vagy felhőszolgáltató használata javasolt.
Összességében nagyon jó benyomás, annak ellenére, hogy a projekt körülbelül 3 éve álldogál (a legutóbbi funkciókérés kb. egy éve volt, de válasz nélkül).
A borgbackup tesztelése
A Borgbackup egy padlásvilla, egy másik, a zbackuphoz hasonló rendszer. Pythonban írva, a zbackuphoz hasonló képességek listája van, de emellett képes:
- Rögzítse a biztonsági mentéseket biztosítékkal
- Ellenőrizze a tár tartalmát
- Dolgozzon kliens-szerver módban
- Használjon különféle tömörítőket az adatokhoz, valamint a tömörítés során a fájltípus heurisztikus meghatározását.
- 2 titkosítási lehetőség, aes és blake
- Beépített eszköz a
teljesítményellenőrzések
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Az eredmények a következők voltak:
CZ-BIG 96.51 MB/s (10 100.00 MB teljesen nulla fájlok: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB teljesen nulla fájlok: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB teljesen nulla fájlok: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB teljesen nulla fájlok: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB véletlenszerű fájlok: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB véletlenszerű fájlok: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB véletlenszerű fájlok: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB véletlenszerű fájlok: 13.77 s)
CZ-KÖZEPES 108.59 MB/s (1000 1.00 MB teljesen nulla fájlok: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB teljesen nulla fájlok: 13.13 s)
UZ-KÖZEPES 331.27 MB/s (1000 1.00 MB teljesen nulla fájlok: 3.02 s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB teljesen nulla fájlok: 2.58 s)
CR-KÖZEPES 37.80 MB/s (1000 1.00 MB véletlenszerű fájlok: 26.45 s)
RR-KÖZEPES 68.90 MB/s (1000 1.00 MB véletlenszerű fájlok: 14.51 s)
UR-KÖZEPES 347.24 MB/s (1000 1.00 MB véletlenszerű fájlok: 2.88 s)
DR-KÖZEPES 48.80 MB/s (1000 1.00 MB véletlenszerű fájlok: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB teljesen nulla fájlok: 8.53 s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB teljesen nulla fájlok: 3.07 s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB teljesen nulla fájlok: 5.16 s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB teljesen nulla fájlok: 2.97 s)
CR-SMALL 6.85 MB/s (10000 10.00 kB véletlenszerű fájlok: 14.60 s)
RR-SMALL 31.27 MB/s (10000 10.00 kB véletlenszerű fájlok: 3.20 s)
UR-SMALL 12.28 MB/s (10000 10.00 kB véletlenszerű fájlok: 8.14 s)
DR-SMALL 18.78 MB/s (10000 10.00 kB véletlenszerű fájlok: 5.32 s)
A tesztelés során tömörítési heurisztikát használunk a fájltípus meghatározásához (automatikus tömörítés), és az eredmények a következők lesznek:
Először is nézzük meg, hogyan működik titkosítás nélkül:
Nyitva tartás:
Indítsa el 1
Indítsa el 2
Indítsa el 3
4m6s
4m10s
4m5s
Ötvenes évek
Ötvenes évek
Ötvenes évek
1m26s
1m34s
1m30s
Ha engedélyezi a lerakat engedélyezését (hitelesített mód), az eredmények közel lesznek:
Nyitva tartás:
Indítsa el 1
Indítsa el 2
Indítsa el 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Amikor az AES titkosítást aktiválták, az eredmények nem sokat romlottak:
Indítsa el 1
Indítsa el 2
Indítsa el 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
És ha az aes-t blake-re változtatja, a helyzet teljesen javulni fog:
Nyitva tartás:
Indítsa el 1
Indítsa el 2
Indítsa el 3
4m33s
4m43s
4m40s
Ötvenes évek
1m0s
1m0s
1m38s
1m43s
1m40s
Akárcsak a zbackup esetében, az adattár mérete 13 GB volt, sőt egy kicsit kevesebb is, ami általában elvárható. A futási idővel nagyon meg voltam elégedve, a librsync alapú megoldásokhoz hasonlítható, sokkal szélesebb képességeket biztosítva. Örültem annak is, hogy környezeti változókon keresztül különböző paramétereket lehet beállítani, ami nagyon komoly előnyt jelent a borgbackup automatikus módban történő használatakor. A mentés közbeni terheléssel is elégedett voltam: a processzorterhelésből ítélve a borgbackup 1 szálon működik.
Használata során különösebb hátrány nem volt.
restic tesztelés
Annak ellenére, hogy a restic egy meglehetősen új megoldás (az első 2 jelöltet még 2013-ban és régebben ismerték), meglehetősen jó tulajdonságokkal rendelkezik. Go-ban írva.
A zbackup-pal összehasonlítva a következőket nyújtja:
- A repository integritásának ellenőrzése (beleértve az egyes részek ellenőrzését is).
- A támogatott protokollok és szolgáltatók hatalmas listája a biztonsági mentések tárolására, valamint az rclone - rsync támogatása a felhőmegoldásokhoz.
- 2 biztonsági mentés összehasonlítása egymással.
- A tároló felszerelése biztosítékon keresztül.
Általánosságban elmondható, hogy a szolgáltatások listája meglehetősen közel áll a borgbackuphoz, helyenként több, máshol kevesebb. Az egyik jellemző, hogy nincs mód a titkosítás letiltására, ezért a biztonsági másolatok mindig titkosítva lesznek. Lássuk a gyakorlatban, mit lehet kipréselni ebből a szoftverből:
Az eredmények a következők voltak:
Nyitva tartás:
Indítsa el 1
Indítsa el 2
Indítsa el 3
5m25s
5m50s
5m38s
Ötvenes évek
Ötvenes évek
Ötvenes évek
1m54s
2m2s
1m58s
A teljesítmény eredményei szintén összehasonlíthatók az rsync-alapú megoldásokkal, és általában nagyon közel állnak a borgbackuphoz, de a CPU-terhelés nagyobb (több szál fut) és fűrészfogas.
Valószínűleg az adattároló szerveren lévő lemezalrendszer teljesítménye korlátozza a programot, ahogy az már az rsync esetében is történt. A repository mérete 13 GB volt, a zbackuphoz vagy a borgbackuphoz hasonlóan ennek a megoldásnak sem volt nyilvánvaló hátránya.
Álláspontja
Valójában minden jelölt hasonló eredményeket ért el, de eltérő áron. A Borgbackup teljesített a legjobban, a restic kicsit lassabb volt, a zbackupot valószínűleg nem érdemes elkezdeni használni,
és ha már használatban van, próbáld megváltoztatni borgbackup vagy restic értékre.
Álláspontja
A legígéretesebb megoldásnak a resticus tűnik, mert... ő rendelkezik a legjobb képességekkel a működési sebességhez képest, de most ne rohanjunk le általános következtetésekkel.
A Borgbackup alapvetően nem rosszabb, de a zbackup-ot valószínűleg jobb helyettesíteni. Igaz, a zbackup továbbra is használható a 3-2-1 szabály működésének biztosítására. Például a (lib)rsync alapú biztonsági mentési lehetőségek mellett.
Közlemény
Biztonsági mentés 5. rész: A bacula és a veeam biztonsági mentés tesztelése linuxhoz
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
Általa megosztva: Pavel Demkovich
Forrás: will.com