Ebben a megjegyzésben azokat a biztonsági mentési eszközöket tárgyaljuk, amelyek archívumokat hoznak létre a biztonsági szerveren.
A következő eszközök felelnek meg a követelményeknek: a duplicity (melyhez van egy kellemes interfész a deja dup formájában) és a duplicati.
Egy másik figyelemre méltó biztonsági mentési eszköz a dar, de mivel széleskörű opciók listája van — a tesztelési módszer alig fedi le a képességeinek 10%-át —, ezért ezt a megfelelő ciklus keretein belül nem teszteljük.
Várt eredmények
Mivel mindkét jelölt valahogy archívumokat hoz létre, a normál tar fájlt is lehet referenciaként használni.
Továbbá értékeljük, hogy mennyire optimálisan tárolódnak az adatok a biztonsági mentési szerveren, úgy, hogy csak a teljes másolat és a fájlok aktuális állapota közötti eltérés, vagy a múltbeli és jelenlegi archívumok közötti eltérés kerül tárolásra (inkrementális, dekremetális stb.).
Biztonsági mentés létrehozásának viselkedése:
- Viszonylag kevés fájl található a biztonsági mentési szerver tárolójában (összehasonlítva a biztonsági mentések számával vagy a gb-ban mért adatok méretével), de elegendően nagy méretben (tízes-hundrek megabájtnyi).
- A tároló mérete csak a változásokat fogja tartalmazni — a másolatok nem fognak tárolódni, így a tároló mérete kisebb lesz, mint ha rsync alapú szoftverrel működne.
- Nagyobb CPU-terhelés várható a tömörítés és/vagy titkosítás alkalmazásakor, és valószínűleg elegendő terhelés a hálózaton és a lemezalrendszeren, ha a tömörítési és/vagy titkosítási folyamat a biztonsági mentési szerveren végzi a munkáját.
Referenciaértékként futtatjuk a következő parancsot:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"A végrehajtás eredménye a következő:
A végrehajtási idő 3m12s. Látható, hogy a sebesség a biztonsági mentési szerver lemezalrendszerének korlátjába ütközött, mint a példában a . Csak egy kicsit gyorsabb, mivel az írás egy fájlba történik.
A tömörítés értékelésére ugyanazt a verziót futtatjuk, de bekapcsolva a tömörítést a biztonsági mentési szerver oldalán:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Az eredmények a következők:
Futási idő: 10m11s. Valószínűleg a szűk keresztmetszet az egyszálú tömörítő a fogadó oldalon.
Ugyanez a parancs, de a tömörítést az eredeti adatok szerverére helyezzük át, hogy ellenőrizzük a hipotézist, hogy a szűk keresztmetszet az egyszálú tömörítő.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Így alakult:
Futási idő: 9m37s. Egyértelműen látható a tömörítő egy magjának terhelése, mivel a hálózati sebesség és a forrással szembeni lemezrendszer terhelése hasonló.
A titkosításhoz használható az openssl vagy a gpg, egy további paranccsal csatlakozva openssl vagy gpg a pipe-on. Itt egy ilyen parancs lesz az irányadó:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Az eredmények a következőek lettek:
Futási idő: 10m30s, mivel 2 folyamat fut a fogadó oldalon — a szűk keresztmetszet ismét az egyszálú tömörítő, plusz a titkosítás miatt kis többletterhelés.
UPD: Bliznezz kérésére hozzáadom a teszteket pigz-zel. Ha csak a tömörítőt használjuk, 6m30s-ra sikerült, ha a titkosítást is hozzáadjuk, körülbelül 7m-re. Az alsó grafikonon a zuhanás — a ki nem ürített lemezpuffer:
Duplicity tesztelése
A Duplicity egy Python alapú szoftver, amely titkosított archívumokat készít tar formátumban történő biztonsági másolat készítése érdekében.
Az inkrementális archívumokhoz a librsync alkalmazása szükséges, ezért a fent említett viselkedésre lehet számítani .
A biztonsági másolatokat titkosítani és aláírni lehet gnupg segítségével, ami fontos, ha különböző szolgáltatókat használunk a biztonsági másolatok tárolásához (s3, backblaze, gdrive stb.)
Nézzük meg, mik lesznek az eredmények:
Íme ezek az eredmények, amikor titkosítás nélkül futottak
spoiler
Minden tesztindítás futási ideje:
Indítás 1
Indítás 2
Indítás 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Íme a gnupg titkosítás használatával kapott eredmények, 2048 bites kulcsmérettel:
Ugyanezek a adatok titkosítással futó ideje:
Indítás 1
Indítás 2
Indítás 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
A blokkméret 512 megabájt volt, amit a grafikonokon világosan látni lehet; a processzor terhelése gyakorlatilag 50%-on állt, tehát a program nem hasznosít több mint egy processz magot.
A program működésének alapelve is jól látható: egy adatdarabot vettünk, tömörítettük, és elküldtük egy biztonsági mentési tároló szerverre, amely elég lassú lehet.
Egy másik jellemző a program működésének előre jelezhető ideje, amely csak a megváltozott adatok méretétől függ.
A titkosítás bekapcsolása nem különösebben növelte a program működési idejét, de körülbelül 10%-kal megnövelte a CPU terhelést, ami lehet némi kellemes bónusz.
Sajnos, ez a program nem tudta helyesen észlelni a könyvtár átnevezésének helyzetét, és a kapott tároló mérete megegyezett a változások méretével (tehát mind a 18 GB), de a lehetőség, hogy megbízhatatlan szervert használjunk biztonsági mentéshez, határozottan megcáfolja ezt a viselkedést.
Duplicati tesztelése
Ez a szoftver C# nyelven íródott, a Mono könyvtárainak használatával fut, van GUI-ja és cli verziója is.
A főbb funkciók listája hasonló a duplicityhoz, beleértve különféle szolgáltatókat a biztonsági mentéshez, azonban a duplicitytól eltérően a legtöbb funkció harmadik fél eszköze nélkül is elérhető. Hogy ez előny vagy hátrány, az a konkrét esetektől függ, de valószínűleg a kezdők számára egyszerűbb, ha az összes lehetőséget egy listában látják, mint hogy Python csomagokat kelljen telepíteni, mint a duplicity esetében.
Még egy kis részlet — a program aktívan ír egy helyi sqlite adatbázist annak a felhasználónak a nevében, aki a biztonsági mentést indítja, ezért figyelni kell a megfelelő adatbázis helyes megadására minden egyes cli indításnál. GUI vagy WEBGUI használata esetén a részletek rejtve maradnak a felhasználó elől.
Nézzük meg, milyen mutatókat tud adni ez a megoldás:
Ha kikapcsoljuk a titkosítást (bár a WEBGUI ezt nem ajánlja), az eredmények a következők:
Működési idő:
Indítás 1
Indítás 2
Indítás 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Titkosítással bekapcsolva, aes használatával, az eredmények a következők:
Működési idő:
Indítás 1
Indítás 2
Indítás 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Ha a gnupg külső programot használjuk, az eredmények a következők:
Indítás 1
Indítás 2
Indítás 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Mint a program képes párhuzamosan működni, de ettől még nem hatékonyabb megoldás, és ha az érések működését összehasonlítjuk — egy külső program indítása
gyorsabb lett, mint a Mono könyvtár használata. Ezt valószínűleg az magyarázza, hogy a külső program jobban optimalizált.
Kellemes meglepetés volt, hogy a tároló mérete pontosan annyi, amennyi a ténylegesen módosított adatokat jelenti, azaz a duplicati észlelte a könyvtár átnevezését és megfelelően kezelte a helyzetet. Ezt a második teszt futtatásakor láthatjuk.
Összességében, nagyon pozitív benyomásaim vannak a programról, beleértve a kezdők számára való elég barátságos kezelhetőséget is.
Eredmények
Mindkét jelölt viszonylag lassan működött, de összességében a hagyományos tar-hoz képest van fejlődés, legalábbis a duplicati esetében. Ennek a fejlődésnek az ára is érthető - jelentős terhelés
a processzorra. Összességében nincsenek különösebb eltérések az eredmények előrejelzésekor.
Következtetések
Ha nincs hova sietni, és van tartalék a processzorban - bármelyik vizsgált megoldás megfelel, mindenesetre elég nagy munkát végeztek el, amit nem érdemes újra megcsinálni a tar-nál elhelyezett szkriptek írásával. A titkosítás megléte nagyon szükséges tulajdonság, ha a biztonsági mentések tárolására szolgáló szerver nem teljes mértékben megbízható.
Ha a megoldásokat összehasonlítjuk a - a teljesítmény több mint kétszer rosszabb lehet, annak ellenére, hogy a tiszta tar 20-30%-kal gyorsabban működött a rsync-nél.
A tároló méretének megtakarítása csak a duplicati-nál van.
Bejelentés
Biztonsági mentés, 3. rész: A duplicity, duplicati, deja dup áttekintése és tesztelése
Biztonsági mentés, 4. rész: A zbackup, restic, borgbackup áttekintése és tesztelése
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
