Ez a megjegyzés azokat a biztonsági mentési eszközöket tárgyalja, amelyek biztonsági mentést készítenek úgy, hogy archívumot hoznak létre egy biztonsági mentési kiszolgálón.
A követelményeknek megfelelőek között van a duplicity (melynek szép felülete van deja dup formájában) és a duplicati.
Egy másik nagyon figyelemreméltó biztonsági mentési eszköz a dar, de mivel nagyon széles a lehetőségek listája - a tesztelési módszertan alig 10%-át fedi le annak, amire képes -, nem a jelenlegi ciklus részeként teszteljük.
Várható eredmények
Mivel mindkét jelölt ilyen vagy olyan módon hoz létre archívumot, a szokásos tar használható útmutatóként.
Ezen túlmenően értékelni fogjuk, hogy mennyire optimalizálható az adattárolás a tárolószerveren azáltal, hogy olyan biztonsági másolatokat készítünk, amelyek csak a teljes másolat és a fájlok aktuális állapota közötti különbséget, vagy az előző és az aktuális archívumot (növekményes, dekrementális stb.) tartalmazzák. .
Viselkedés a biztonsági mentések létrehozásakor:
- Viszonylag kevés fájl található a biztonsági mentési tárolószerveren (összehasonlítható a biztonsági másolatok számával vagy az adatok méretével GB-ban), de méretük meglehetősen nagy (tíz-száz megabájt).
- A lerakat mérete csak a változtatásokat tartalmazza – nem lesznek duplikátumok, így a lerakat mérete kisebb lesz, mint az rsync alapú szoftvereknél.
- A tömörítés és/vagy titkosítás használatakor nagy CPU-terhelésre kell számítani, és valószínűleg meglehetősen nagy hálózati és lemezterhelésre, ha az archiválási és/vagy titkosítási folyamat egy biztonsági mentési tárolókiszolgálón fut.
Futtassuk a következő parancsot referenciaértékként:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"A végrehajtás eredménye a következő volt:
Kivitelezési idő 3m12s. Látható, hogy a sebességet a mentési tárolószerver lemezes alrendszere korlátozza, mint a példában . Csak egy kicsit gyorsabban, mert... a felvétel egy fájlba megy.
A tömörítés értékeléséhez futtassuk ugyanazt az opciót, de engedélyezzük a tömörítést a tartalék szerver oldalon:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Az eredmények a következők:
Kivitelezési idő 10m11s. Valószínűleg a szűk keresztmetszet az egyáramú kompresszor a fogadó oldalon.
Ugyanez a parancs, de az eredeti adatokkal együtt a szerverre továbbított tömörítéssel, hogy teszteljék azt a hipotézist, hogy a szűk keresztmetszet egy egyszálú tömörítő.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Így alakult:
A végrehajtási idő 9m37s volt. Jól látható a kompresszor egyik magjának terhelése, mert A hálózati átviteli sebesség és a forráslemez alrendszer terhelése hasonló.
A titkosítás értékeléséhez használhatja az openssl vagy a gpg parancsot egy további parancs csatlakoztatásával openssl vagy gpg csőben. Referenciaként egy ehhez hasonló parancs lesz:
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 így jöttek ki:
A végrehajtási idő 10m30s lett, mivel 2 processz futott a fogadó oldalon - a szűk keresztmetszet ismét egy egyszálas kompresszor, plusz kis titkosítási költség.
UPS: Bliznezz kérésére adok hozzá teszteket pigz-el. Ha csak a kompresszort használod, akkor 6m30s, ha titkosítást is adsz hozzá, akkor kb 7m. Az alsó grafikonon a csökkenés egy kiürítetlen lemezgyorsítótár:
Duplikált tesztelés
A Duplicity egy python-szoftver biztonsági mentéshez titkosított archívumok létrehozásával tar formátumban.
A növekményes archívumok esetében a librsync használatos, így a következőben leírt viselkedésre számíthat .
A biztonsági másolatok titkosíthatók és aláírhatók a gnupg segítségével, ami fontos, ha különböző szolgáltatókat használ a biztonsági másolatok tárolására (s3, backblaze, gdrive stb.)
Lássuk, mik az eredmények:
Ezeket az eredményeket kaptuk titkosítás nélküli futtatáskor
spoiler
Az egyes próbaüzemek lefutási ideje:
Indítsa el 1
Indítsa el 2
Indítsa el 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
És itt vannak az eredmények, amikor a gnupg titkosítás engedélyezve van, 2048 bites kulcsmérettel:
Működési idő ugyanazon az adatokon, titkosítással:
Indítsa el 1
Indítsa el 2
Indítsa el 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
A blokkméretet jelezték - 512 megabájt, ami jól látható a grafikonokon; A processzorterhelés valójában 50% maradt, ami azt jelenti, hogy a program legfeljebb egy processzormagot használ.
A program működési elve is jól látható: vettek egy adatot, tömörítették és elküldték egy tartalék tárolószerverre, ami elég lassú lehet.
További jellemző a program kiszámítható futási ideje, amely csak a megváltozott adatok méretétől függ.
A titkosítás engedélyezése nem növelte jelentősen a program futási idejét, viszont a processzorterhelést nagyjából 10%-kal növelte, ami egészen kellemes bónusz lehet.
Sajnos ez a program nem tudta helyesen észlelni a helyzetet a címtárátnevezéssel, és az eredményül kapott lerakatméret megegyezett a változtatások méretével (azaz mind a 18 GB-os), de egyértelműen képes volt biztonsági mentéshez egy nem megbízható szervert használni. lefedi ezt a viselkedést.
Duplikált tesztelés
Ez a szoftver C# nyelven íródott, és a Mono programkönyvtárak segítségével fut. Létezik GUI és CLI verzió is.
A fő funkciók hozzávetőleges listája hasonló a duplicity-hez, beleértve a különböző biztonsági mentési tárolókat, azonban a duplicitással ellentétben a legtöbb szolgáltatás harmadik féltől származó eszközök nélkül is elérhető. Az, hogy ez plusz vagy mínusz, az adott esettől függ, de a kezdők számára valószínűleg egyszerűbb, ha egy listát készítenek az összes szolgáltatásról, és nem kell további csomagokat telepíteni a pythonhoz, ahogy az az eset a kettősséggel.
Egy másik apró árnyalat - a program aktívan ír egy helyi sqlite adatbázist a biztonsági mentést elindító felhasználó nevében, ezért emellett gondoskodnia kell arról, hogy a szükséges adatbázis helyesen legyen megadva minden alkalommal, amikor a folyamatot a cli használatával elindítják. GUI-n vagy WEGBUI-n keresztül végzett munka során a részletek rejtve lesznek a felhasználó elől.
Nézzük meg, milyen mutatókat tud produkálni ez a megoldás:
Ha kikapcsolja a titkosítást (és a WEBGUI nem javasolja ezt), az eredmény a következő:
Nyitva tartás:
Indítsa el 1
Indítsa el 2
Indítsa el 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Ha a titkosítás engedélyezve van, az aes használatával ez így néz ki:
Nyitva tartás:
Indítsa el 1
Indítsa el 2
Indítsa el 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
És ha a gnupg külső programot használja, a következő eredmények születnek:
Indítsa el 1
Indítsa el 2
Indítsa el 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Amint látható, a program több szálon is működhet, de ettől még nem lesz produktívabb megoldás, és ha összehasonlítjuk a titkosítási munkát, akkor egy külső programot indít.
gyorsabbnak bizonyult, mint a Mono készletből származó könyvtár használata. Ennek oka lehet, hogy a külső program optimalizáltabb.
További szép dolog volt, hogy a repository mérete pontosan annyit vesz fel, amennyi a ténylegesen megváltozott adat, pl. A duplicati könyvtár átnevezést észlelt, és megfelelően kezelte ezt a helyzetet. Ez látható a második teszt futtatásakor.
Összességében meglehetősen pozitív benyomások vannak a programról, beleértve azt is, hogy meglehetősen barátságosak az újoncokkal.
Álláspontja
Mindkét jelölt meglehetősen lassan dolgozott, de általában a hagyományos tarhoz képest van előrelépés, legalábbis a duplikátumokkal. Az ilyen haladás ára is egyértelmű – észrevehető teher
processzor. Általában nincs különösebb eltérés az eredmények előrejelzésében.
Álláspontja
Ha nem kell sehova rohanni, és van tartalék processzora is, akkor bármelyik megfontolt megoldás megteszi, mindenesetre elég sok munka történt, amit nem szabad megismételni a tar tetejére burkoló szkriptek írásával. . A titkosítás megléte nagyon szükséges tulajdonság, ha a biztonsági másolatok tárolására szolgáló szerverben nem lehet teljesen megbízni.
A megoldás alapú megoldásokhoz képest - a teljesítmény többször is rosszabb lehet, annak ellenére, hogy tiszta formájában a tar 20-30%-kal gyorsabban működött, mint az rsync.
A tároló méretén van megtakarítás, de csak duplikátumokkal.
Közlemény
Biztonsági mentés 3. rész: A kettősség áttekintése és tesztelése, duplicati, deja dup
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 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