A cikkben a szoftvereszközöket fogjuk tárgyalni, amelyek az adatfolyam darabokra (chunks) bontásával képeznek egy tárolót.
A tároló elemei további tömörítést és titkosítást is kaphatnak, és ami a legfontosabb — a későbbi biztonsági mentési folyamatok során újra felhasználhatók.
A biztonsági mentés ebben a tárolóban egy elnevezett, egymással összekapcsolt elemek láncolata, például különböző hash-funkciók alapján.
Több hasonló megoldás létezik, én háromra fogok összpontosítani: zbackup, borgbackup és restic.
Várt eredmények
Mivel minden jelölt valamilyen formában tároló létrehozását igényli, az egyik legfontosabb tényező a tároló méretének értékelése lesz. Az ideális esetben ennek méretének nem szabad meghaladnia a 13 GB-ot, szerint a megállapított módszertan szerint, vagy még kevesebbnek kell lennie — megfelelő optimalizálás mellett.
Emellett nagyon kívánatos, hogy lehetőség legyen a fájlok közvetlen biztonsági mentésére, archiváló használata nélkül, mint például a tar, valamint az ssh/sftp közvetlen használata, további eszközök, például rsync és sshfs nélkül.
Biztonsági mentés létrehozásának viselkedése:
- A tároló mérete az eltérések méretének, vagy annál kisebbnek fog megfelelni.
- Nagy terhelés várható a CPU-ra a tömörítés és/vagy titkosítás használata esetén, és valószínűleg jelentős terhelés éri a hálózatot és a lemezalrendszert, ha a mentés és/vagy titkosítás folyamata a biztonsági mentési tároló szerveren zajlik.
- Ha a tároló megsérül — várhatóan késleltetett hiba lép fel új biztonsági mentések létrehozása során, valamint a helyreállítási kísérletek során is. További intézkedéseket kell tervezni a tároló épségének biztosítására, vagy beépített integritásellenőrző eszközöket kell használni.
A referenciaértékként a tar használatát tekintjük, ahogy azt az előző cikkek egyikében bemutatták.
A zbackup tesztelése
A zbackup működési mechanizmusa az, hogy a program a bemeneti adatfolyamban megtalálja az azonos adatokat tartalmazó területeket, majd opcionálisan tömöríti, titkosítja őket, megőrzi minden területet csak egyszer.
A deduplikáláshoz 64-bites körkörös hash-funkciót alkalmaznak, amely csúszó ablakot használ byte-alapú összehasonlításra a már meglévő ad blokkokkal (hasonlóan a rsync-hez).
A tömörítéshez lzma és lzo kerül alkalmazásra, több szálon futva, míg a titkosításhoz aes-t használnak. Az utolsó verziókban lehetőség van a jövőbeli régi adatok eltávolítására a tárolóból.
A program C++ nyelven készült minimális függőségekkel. Úgy tűnik, a szerző a unix-módszert inspirációnak tekintette, mivel a program stdin-en fogadja az adatokat a biztonsági másolatok létrehozásakor, és hasonló adatfolyamot ad ki stdout-on a visszaállításkor. Így a zbackup egy nagyon hasznos «építőelem» lehet a saját biztonsági másolat megoldásainkhoz. Például a cikk szerzője 2014 óta ezt a programot használja a háztartási gépek alapvető biztonsági másolatául.
Az adatfolyam hagyományos tar formátumban kerül felhasználásra, hacsak másként nem rendelkeznek.
Nézzük meg, mik lesznek az eredmények:
A működés ellenőrzése 2 változatban történt:
- repository jön létre, és a zbackup a forrásadatokat tartalmazó szerveren fut, majd a repository tartalmát átkonvertálják a biztonsági másolatokat tároló szerverre.
- repository jön létre a biztonsági másolatokat tároló szerveren, a zbackup ssh-n keresztül fut a biztonsági másolatokat tároló szerveren, és a data pipe-on kerülnek átadásra.
Az első változat eredményei a következők voltak: 43m11s — titkosítatlan repository és lzma tömörítő használatával, 19m13s — a tömörítő lzo-ra cserélésekor.
A forrásadatokat tartalmazó szerveren a terhelés a következő volt (ez egy lzma példát mutat, az lzo hasonlóan viselkedett, de az rsync aránya a körülbelül a negyede volt az időnek):
Jól látható, hogy egy ilyen biztonsági másolat készítési folyamat csak viszonylag ritka és kis változtatások esetén alkalmazható. Ezenkívül erősen ajánlott, hogy a zbackup 1 szálra legyen korlátozva, mivel különben nagyon magas CPU-terhelést okozhat, mivel a program nagyon jól tud párhuzamosan működni. A lemezterhelés alacsony volt, ami összességében a modern SSD-alapú lemezrendszernél észrevehetetlen. A távoli szerverre való adatszinchronizálás folyamatának elindulása is egyértelműen látható, a sebesség hasonló a megszokott rsync-hez, és a biztonsági másolatokat tároló szerver lemezrendszerének teljesítményébe ütközik. A megközelítés hátránya a helyi repository tárolása, és ennek eredményeként az adatok duplikálódása.
A más gyakorlatias és érdekesebb változat a zbackup azonnali indítása a biztonsági másolatok tárolására szolgáló szerveren.
Először a titkosítás nélküli, lzma tömörítővel végzett működést fogjuk ellenőrizni:
Minden tesztindítás futási ideje:
Indítás 1
Indítás 2
Indítás 3
39m45s
40m20s
40p3mp
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Ha az aes titkosítást aktiváljuk, az eredmények meglehetősen hasonlóak:
Ugyanezek a adatok titkosítással futó ideje:
Indítás 1
Indítás 2
Indítás 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Ha a titkosítást az lzo tömörítéssel kombináljuk, az alábbi eredményeket kapjuk:
Működési idő:
Indítás 1
Indítás 2
Indítás 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
A kapott tároló mérete relatíve azonos volt, 13 GB-ra rúgott. Ez azt jelenti, hogy a deduplikáció helyesen működik. Az lzo alkalmazása a már tömörített adatokon is kézzelfogható hatást gyakorol, a zbackup összesített futási ideje szorosan megközelíti a duplicity/duplicati időt, de 2-5-ször elmarad a librsync alapú megoldásoktól.
A előnyök nyilvánvalóak — a helymegtakarítás a biztonsági másolatok tárolására szolgáló szerveren. A tároló ellenőrzésére szolgáló eszközöket a zbackup szerzője nem biztosítja, ezért javasolt a hibamentes lemezmeghajtó tömb vagy felhőszolgáltató használata.
Összességében meglehetősen jó benyomást kelt, annak ellenére, hogy a projekt körülbelül 3 éve stagnál (az utolsó funkciókérést körülbelül egy éve adták be, de válasz nélkül).
Borgbackup tesztelése
A Borgbackup az attic forkja, egy hasonló zbackup rendszer. Python nyelven készült, és hasonló képességlistával rendelkezik, de további funkciókkal bővült:
- Biztonsági másolatok mountolása fuse-on keresztül
- A tároló tartalmának ellenőrzése
- Kliens-szerver módban működik
- Különböző tömörítőkkel dolgozik, valamint heuristikus fájltípus-azonosítást alkalmaz a tömörítés során.
- 2 titkosítási lehetőség, aes és blake
- Beépített eszköz a
teljesítmény ellenőrzésére
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Az eredmények a következők lettek:
C-Z-BIG 96.51 MB/s (10 100.00 MB all-zero files: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB all-zero files: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB all-zero files: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB all-zero files: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB random files: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB random files: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB random files: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB random files: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB all-zero files: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB all-zero files: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB all-zero files: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB all-zero files: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB random files: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB random files: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB random files: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB random files: 20.49s)
C-Z-KIS 11,72 MB/s (10000 10,00 kB üres fájlok: 8,53s)
R-Z-KIS 32,57 MB/s (10000 10,00 kB üres fájlok: 3,07s)
U-Z-KIS 19,37 MB/s (10000 10,00 kB üres fájlok: 5,16s)
D-Z-KIS 33,71 MB/s (10000 10,00 kB üres fájlok: 2,97s)
C-R-KIS 6,85 MB/s (10000 10,00 kB véletlenszerű fájlok: 14,60s)
R-R-KIS 31,27 MB/s (10000 10,00 kB véletlenszerű fájlok: 3,20s)
U-R-KIS 12,28 MB/s (10000 10,00 kB véletlenszerű fájlok: 8,14s)
D-R-KIS 18,78 MB/s (10000 10,00 kB véletlenszerű fájlok: 5,32s)
A tesztelés során a fájltípus meghatározásával történő tömörítési heurisztika (compression auto) lesz használatban, az eredmények a következőképpen alakulnak:
Kezdjük a munka ellenőrzésével titkosítás nélkül:
Működési idő:
Indítás 1
Indítás 2
Indítás 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Ha engedélyezzük a repository hitelesítést (authenticated mód), az eredmények közeliek lesznek:
Működési idő:
Indítás 1
Indítás 2
Indítás 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
A titkosítás AES aktiválásakor az eredmények nem romlottak drámaian:
Indítás 1
Indítás 2
Indítás 3
4m55s
5m2s
4p58mp
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
De ha az AES-t Blake-re cseréljük, a helyzet jelentősen javul:
Működési idő:
Indítás 1
Indítás 2
Indítás 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Ahogyan a zbackup esetében, a repository mérete 13 GB volt, és kicsit kevesebb, ami összességében várható. Az időtartam meglehetősen kielégítő volt, összehasonlítható a librsync alapú megoldásokkal, és sokkal szélesebb lehetőségeket biztosít. Az is örömteli volt, hogy különböző paraméterek megadását környezeti változókon keresztül is lehetett végezni, ami jelentős előnyt nyújt a borgbackup automatikus használatakor. Emellett a biztonsági mentés alatt tapasztalt terhelés is kedvező volt, a CPU terhelés alapján — a borgbackup egy szálon működik.
Nem tapasztaltam különösebb hátrányokat a használat során.
Restic tesztelése
Bár a Restic viszonylag új megoldás (az első két jelölt már 2013-ból ismert), elég jó teljesítménnyel bír. Go nyelven készült.
Ha a zbackuphoz hasonlítjuk, további lehetőségeket kínál:
- A repository integritásának ellenőrzése (beleértve a részleges ellenőrzést is).
- Hatalmas lista a támogatott protokollokról és szolgáltatókról a biztonsági másolatok tárolásához, valamint támogatás az rclone számára — rsync a „felhős” megoldásokhoz.
- Két biztonsági másolat összehasonlítása.
- A repository összekapcsolása fúziós módszerrel.
Összességében a lehetőségek listája elég közel áll a borgbackuphoz; helyenként több, helyenként kevesebb. Különlegesség, hogy a titkosítást nincs lehetőség kikapcsolni, így a biztonsági másolatok mindig titkosítottak lesznek. Nézzük meg gyakorlatban, mit lehet kihozni ebből a szoftverből:
Az eredmények a következőképpen alakultak:
Működési idő:
Indítás 1
Indítás 2
Indítás 3
5m25s
5m50s
5p38mp
35s
38s
36s
1m54s
2m2s
1m58s
A munkájuk eredményei összehasonlíthatók az rsync-alapú megoldásokkal, és általában nagyon közel állnak a borgbackuphoz, de a CPU terhelése magasabb (több szálon fut), és a teljesítmény ingadozó.
Valószínűleg a program a tárolószerver lemezalrendszerének teljesítményébe ütközik, ahogy az rsync esetében is történt. A repository mérete 13 GB volt, mint a zbackup vagy borgbackup esetében, nyilvánvaló hátrányokat e megoldás használatakor nem találtunk.
Eredmények
Valójában az összes jelölt hasonló mutatókkal rendelkezett, de különböző áron. A borgbackup teljesítménye volt a legjobb, kicsit lassabb volt a restic, a zbackupot valószínűleg nem érdemes elkezdeni használni,
ha pedig már használatban van — érdemes átváltani borgbackupra vagy resticre.
Következtetések
A legígéretesebb megoldásnak a restic tűnik, mert a legjobb lehetőség- és sebességarányt kínálja, de egyelőre ne siessünk a végső következtetésekkel.
A borgbackup alapvetően nem rosszabb, de a zbackupot valószínűleg érdemes lenne lecserélni. Igaz, a 3-2-1 szabály érvényesítése érdekében a zbackupot még használhatjuk például az (lib)rsync-alapú mentési eszközök mellett.
Bejelentés
Biztonsági mentés, 5. rész: A bacula és a veeam backup for linux tesztelése
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
A publikáció szerzője: Pavel Demkovics
Forrás: habr.com
