Ez a cikk összehasonlítja a biztonsági mentési eszközöket, de először meg kell találnia, hogy milyen gyorsan és jól birkózik meg a biztonsági mentésekből származó adatok visszaállításával.
Az összehasonlítás megkönnyítése érdekében fontolóra vesszük a teljes biztonsági másolatból történő visszaállítást, különösen mivel minden jelölt támogatja ezt a működési módot. Az egyszerűség kedvéért a számok már átlagoltak (több futás számtani átlaga). Az eredményeket egy táblázatban foglaljuk össze, amely a képességekről is tartalmaz információkat: webes felület megléte, egyszerű beállítás és kezelés, automatizálási képesség, különféle kiegészítő szolgáltatások megléte (például adatintegritás ellenőrzése) stb. A grafikonok a szerver terhelését mutatják, ahol az adatokat felhasználják (nem a biztonsági másolatok tárolására szolgáló szerveren).
Adatmentés
óta az rsync és a tar lesz referenciapont egyszerű szkriptek biztonsági másolatok készítéséhez.
rsync 4 perc 28 másodperc alatt megbirkózott a tesztadatokkal, megmutatva
olyan terhelést
A helyreállítási folyamat elérte a biztonsági mentési tárolószerver lemezalrendszerének korlátozását (sawtooth grafikonok). Tisztán láthatod egy kernel betöltését is gond nélkül (alacsony iowait és softirq – nincs probléma a lemezzel és a hálózattal). Mivel a másik két program, nevezetesen az rdiff-backup és az rsnapshot, az rsync-en alapul, és a normál rsync-et is kínálja helyreállítási eszközként, megközelítőleg azonos betöltési profillal és biztonsági mentési helyreállítási idővel rendelkeznek.
Kátrány kicsit gyorsabban sikerült
2 perc 43 másodperc:
A teljes rendszerterhelés átlagosan 20%-kal volt magasabb a megnövekedett softirq miatt - nőttek a hálózati alrendszer üzemeltetése során felmerülő rezsiköltségek.
Az archívum további tömörítése esetén a helyreállítási idő 3 perc 19 másodpercre nő.
ilyen terhelés mellett a fő szerveren (kicsomagolás a fő szerver oldalán):
A kibontási folyamat mindkét processzormagot igénybe veszi, mivel két folyamat fut. Általában ez a várt eredmény. Hasonló eredményt (3 perc és 20 másodperc) kaptunk, amikor a gzip-et a szerver oldalon, biztonsági mentésekkel futtattuk; a fő szerver terhelési profilja nagyon hasonló volt a tar futtatásához a gzip tömörítő nélkül (lásd az előző grafikont).
В rdiff-backup szinkronizálhatja az utolsó biztonsági másolatot, amelyet a normál rsync használatával készített (az eredmények hasonlóak lesznek), de a régebbi biztonsági másolatokat továbbra is vissza kell állítani az rdiff-backup programmal, amely 17 perc 17 másodperc alatt fejezte be a visszaállítást,
ez a terhelés:
Talán ennek a célja volt, legalábbis korlátozni a szerzők sebességét . Maga a biztonsági másolat visszaállításának folyamata valamivel kevesebb, mint egy mag felét vesz igénybe, arányosan összehasonlítható teljesítménnyel (azaz 2-5-ször lassabb) lemezen és hálózaton rsync segítségével.
Rsnapshot A helyreállításhoz a szokásos rsync használatát javasolja, így az eredmények hasonlóak lesznek. Általában így alakult.
Böfög A biztonsági mentés visszaállításának feladatát 7 perc és 2 másodperc alatt végeztem el
ezzel a terheléssel:
Meglehetősen gyorsan működött, és legalább sokkal kényelmesebb, mint a tiszta rsync: nem kell emlékezni egyetlen jelzőre sem, egyszerű és intuitív klipi felület, beépített támogatás több példányhoz - bár kétszer lassabb. Ha vissza kell állítania az adatokat a legutóbb készített biztonsági másolatból, néhány kikötéssel használhatja az rsync-et.
A program megközelítőleg azonos sebességet és terhelést mutatott BackupPC az rsync átviteli mód engedélyezésekor a biztonsági másolat telepítése a következőhöz
7 perc 42 másodperc:
Ám adatátviteli módban a BackupPC lassabban birkózott meg a kátránnyal: 12 perc és 15 másodperc alatt a processzorterhelés általában alacsonyabb volt.
másfélszer:
Kétszínűség titkosítás nélkül valamivel jobb eredményeket mutatott, 10 perc 58 másodperc alatt visszaállította a biztonsági másolatot. Ha a gpg használatával aktiválja a titkosítást, a helyreállítási idő 15 percre és 3 másodpercre nő. A másolatok tárolására szolgáló lerakat létrehozásakor megadhatja a bejövő adatfolyam felosztása során használt archívum méretét is. Általánosságban elmondható, hogy a hagyományos merevlemezeken, az egyszálas működési mód miatt is, nincs sok különbség. Hibrid tároló használatakor különböző blokkméretekben jelenhet meg. A fő szerver terhelése a helyreállítás során a következő volt:
nincs titkosítás
titkosítással
Másolat hasonló felépülési sebességet mutatott, 13 perc és 45 másodperc alatt fejeződött be. A visszaállított adatok helyességének ellenőrzése további körülbelül 5 percet vett igénybe (összesen körülbelül 19 perc). A terhelés az volt
elég magas:
Amikor az aes titkosítást belsőleg engedélyezték, a helyreállítási idő 21 perc 40 másodperc volt, a CPU kihasználtsága maximális volt (mindkét mag!) a helyreállítás során; Az adatok ellenőrzésekor csak egy szál volt aktív, egy processzormagot elfoglalva. Az adatok helyreállítása utáni ellenőrzése ugyanilyen 5 percig tartott (összesen majdnem 27 perc).
Eredmény
A duplicati egy kicsit gyorsabb volt a helyreállítással, amikor a külső gpg programot használtuk a titkosításhoz, de általában minimálisak a különbségek az előző módhoz képest. Az üzemidő 16 perc 30 másodperc volt, az adatok ellenőrzése 6 perc alatt történt. A terhelés az volt
a következő:
AMANDA, kátrány felhasználásával 2 perc 49 másodperc alatt teljesítette, ami elvileg nagyon közel áll a normál kátrányhoz. Elvileg terhelje meg a rendszert
ugyanaz:
A biztonsági mentés visszaállítása során a zbackup a következő eredmények születtek:
titkosítás, lzma tömörítés
Futási idő 11 perc 8 másodperc
AES titkosítás, lzma tömörítés
Munkaidő 14 perc
AES titkosítás, lzo tömörítés
Futási idő 6 perc 19 másodperc
Összességében nem rossz. Minden a backup szerveren lévő processzor sebességétől függ, ami jól látható a különböző tömörítőkkel ellátott program futási idejéből. A tartalék szerver oldalon egy rendes tar indult, így ha összehasonlítjuk vele, akkor 3-szor lassabb a helyreállítás. Érdemes lehet ellenőrizni a működést többszálú módban, kettőnél több szálnál.
BorgBackup titkosítatlan módban kicsit lassabb volt, mint a tar, 2 perc 45 másodperc alatt, azonban a tartól eltérően lehetővé vált a repository deduplikálása. A terhelésről kiderült
következő:
Ha engedélyezi a blake-alapú titkosítást, a biztonsági mentés helyreállítási sebessége valamivel lassabb. A helyreállítási idő ebben az üzemmódban 3 perc 19 másodperc, és a terhelés megszűnt
mint ez:
Az AES titkosítás valamivel lassabb, a helyreállítási idő 3 perc 23 másodperc, a terhelés különösen
nem változott:
Mivel a Borg többszálú üzemmódban is tud dolgozni, a processzor terhelése maximális, és ha további funkciókat aktiválnak, a működési idő egyszerűen megnő. Úgy tűnik, érdemes a zbackuphoz hasonló módon megvizsgálni a többszálas működést.
Resztikus kicsit lassabban birkózott meg a felépüléssel, az üzemidő 4 perc 28 másodperc volt. A teher úgy nézett ki
így:
A helyreállítási folyamat látszólag több szálon is működik, de a hatékonyság nem olyan magas, mint a BorgBackupé, de időben összemérhető a normál rsyncével.
-Val urBackup 8 perc 19 másodperc alatt lehetett visszaállítani az adatokat, a terhelés az volt
a következő:
A terhelés még mindig nem túl nagy, még a kátránynál is alacsonyabb. Egyes helyeken kitörések vannak, de legfeljebb egy mag terhelése.
Összehasonlítási szempontok kiválasztása és indoklása
Az előző cikkek egyikében leírtak szerint a biztonsági mentési rendszernek meg kell felelnie a következő kritériumoknak:
- Egyszerű használat
- sokoldalúság
- stabilitás
- gyorsaság
Érdemes minden pontot külön-külön részletesebben megvizsgálni.
Könnyű kezelhetőség
A legjobb, ha van egy gomb „Mindent jól csinálj”, de ha visszatérsz a valódi programokhoz, a legkényelmesebb valami ismerős és szokásos működési elv lesz.
A legtöbb felhasználó valószínűleg jobban jár, ha nem kell megjegyeznie egy csomó kulcsot a cli-hez, nem kell különféle, gyakran homályos opciókat konfigurálnia a weben vagy a tui-n keresztül, vagy nem kell értesítést beállítania a sikertelen működésről. Ez magában foglalja azt is, hogy a meglévő infrastruktúrába könnyen „illeszthető” egy biztonsági mentési megoldás, valamint a mentési folyamat automatizálása. Lehetőség van a telepítésre csomagkezelővel, vagy egy vagy két paranccsal, például „letöltés és kicsomagolás”. curl ссылка | sudo bash - összetett módszer, mivel ellenőrizni kell, mi érkezik a linken keresztül.
Például a vizsgált jelöltek közül egyszerű megoldás a burp, az rdiff-backup és a restic, amelyek mnemonikus billentyűkkel rendelkeznek a különböző üzemmódokhoz. Valamivel összetettebb a borg és a kettősség. A legnehezebb AMANDA volt. A többi valahol középen van a könnyű használhatóság szempontjából. Mindenesetre, ha több mint 30 másodpercre van szüksége a használati útmutató elolvasásához, vagy fel kell keresnie a Google-t vagy más keresőt, és végig kell görgetnie egy hosszú súgólapot, így vagy úgy nehéz a döntés.
A figyelembe vett jelöltek egy része képes automatikusan üzenetet küldeni e-mailjabberen keresztül, míg mások a rendszerben konfigurált riasztásokra hagyatkoznak. Sőt, az összetett megoldások leggyakrabban nem rendelkeznek teljesen nyilvánvaló riasztási beállításokkal. Mindenesetre, ha a biztonsági mentési program nullától eltérő visszatérési kódot állít elő, amelyet a rendszerszolgálat az időszakos feladatokhoz helyesen fog megérteni (üzenetet küld a rendszergazdának vagy közvetlenül a felügyeletnek) - a helyzet egyszerű. De ha a biztonsági mentési rendszert, amely nem fut tartalék szerveren, nem lehet konfigurálni, a probléma nyilvánvaló módja az, hogy a bonyolultság már túlzott. A figyelmeztetések és egyéb üzenetek csak a webes felületre vagy a naplóra történő kibocsátása mindenesetre rossz gyakorlat, mivel ezeket legtöbbször figyelmen kívül hagyják.
Ami az automatizálást illeti, egy egyszerű program képes beolvasni a működési módját beállító környezeti változókat, vagy van olyan kifejlesztett klijje, amely teljesen megismétli a viselkedést például webes felületen keresztül. Ide tartozik még a folyamatos működés lehetősége, a bővítési lehetőségek elérhetősége stb.
sokoldalúság
Részben megismételve az előző, automatizálással kapcsolatos alfejezetet, nem jelenthet különösebb problémát a mentési folyamat „illesztése” a meglévő infrastruktúrába.
Érdemes megjegyezni, hogy a nem szabványos portok használata (jó, kivéve a webes felületet) a munkához, a titkosítás nem szabványos módon történő megvalósítása, a nem szabványos protokollt használó adatcsere a nem szabványos protokollt jelzi. -univerzális megoldás. Többnyire minden jelölt rendelkezik ilyen vagy olyan módon, aminek nyilvánvaló oka van: az egyszerűség és a sokoldalúság általában nem jár együtt. Kivételként - böfög, vannak mások.
Jelként - a normál ssh használatával történő munkavégzés képessége.
Munka sebessége
A legvitatottabb és legellentmondásosabb pont. Egyrészt elindítottuk a folyamatot, a lehető leggyorsabban működött, és nem zavarta a főbb feladatokat. Másrészt a forgalom és a processzorterhelés megugrása a biztonsági mentési időszak alatt. Azt is érdemes megjegyezni, hogy a leggyorsabb másolási programok általában a legszegényebbek a felhasználók számára fontos funkciók tekintetében. Még egyszer: ha egy szerencsétlen, több tíz bájtos szöveges fájl eléréséhez jelszóval, és emiatt a teljes szolgáltatási költséggel (igen, igen, megértem, hogy itt legtöbbször nem a mentési folyamat okolható), és sorban újra kell olvasnia a tárolóban lévő összes fájlt, vagy ki kell bővítenie a teljes archívumot – a biztonsági mentési rendszer soha nem gyors. Egy másik pont, amely gyakran buktatóvá válik, az archívumból készült biztonsági másolat telepítésének sebessége. Egyértelmű előnye van itt azoknak, akik egyszerűen átmásolhatják vagy áthelyezhetik a fájlokat a kívánt helyre különösebb manipuláció nélkül (például rsync), de legtöbbször szervezeti úton, empirikusan kell megoldani a problémát: a mentés helyreállítási idejének mérésével. és erről nyíltan tájékoztatni a felhasználókat.
stabilitás
Ezt így kell érteni: egyrészt a biztonsági másolatot bármilyen módon vissza kell tudni telepíteni, másrészt ellenállónak kell lennie a különféle problémákkal szemben: hálózati megszakítás, lemezhiba, a biztonsági másolat egy részének törlése. adattár.
A biztonsági mentési eszközök összehasonlítása
Másolat létrehozásának ideje
Másolás helyreállítási ideje
Egyszerű telepítés
Könnyű beállítás
Egyszerű használat
Egyszerű automatizálás
Szüksége van egy kliens szerverre?
Az adattár integritásának ellenőrzése
Differenciális másolatok
Működés csövön keresztül
sokoldalúság
Függetlenség
Az adattár átláthatósága
Titkosítás
Tömörítés
Deduplikáció
Webes felület
Felhőbe töltés
Windows támogatás
jel
rsync
4m15s
4m28s
igen
nincs
nincs
nincs
igen
nincs
nincs
igen
nincs
igen
igen
nincs
nincs
nincs
nincs
nincs
igen
6
Kátrány
tiszta
3m12s
2m43s
igen
nincs
nincs
nincs
nincs
nincs
igen
igen
nincs
igen
nincs
nincs
nincs
nincs
nincs
nincs
igen
8,5
gzip
9m37s
3m19s
igen
Rdiff-mentés
16m26s
17m17s
igen
igen
igen
igen
igen
nincs
igen
nincs
igen
nincs
igen
nincs
igen
igen
igen
nincs
igen
11
Rsnapshot
4m19s
4m28s
igen
igen
igen
igen
nincs
nincs
igen
nincs
igen
nincs
igen
nincs
nincs
igen
igen
nincs
igen
12,5
Böfög
11m9s
7m2s
igen
nincs
igen
igen
igen
igen
igen
nincs
igen
igen
nincs
nincs
igen
nincs
igen
nincs
igen
10,5
Kétszínűség
nincs titkosítás
16m48s
10m58s
igen
igen
nincs
igen
nincs
igen
igen
nincs
nincs
igen
nincs
igen
igen
nincs
igen
nincs
igen
11
gpg
17m27s
15m3s
Másolat
nincs titkosítás
20m28s
13m45s
nincs
igen
nincs
nincs
nincs
igen
igen
nincs
nincs
igen
nincs
igen
igen
igen
igen
igen
igen
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
zbackup
nincs titkosítás
40m3s
11m8s
igen
igen
nincs
nincs
nincs
igen
igen
igen
nincs
igen
nincs
igen
igen
igen
nincs
nincs
nincs
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
nincs titkosítás
4m7s
2m45s
igen
igen
igen
igen
igen
igen
igen
igen
igen
igen
nincs
igen
igen
igen
igen
nincs
igen
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Resztikus
5m38s
4m28s
igen
igen
igen
igen
nincs
igen
igen
igen
igen
igen
nincs
igen
nincs
igen
nincs
igen
igen
15,5
urBackup
8m21s
8m19s
igen
igen
igen
nincs
igen
nincs
igen
nincs
igen
igen
nincs
igen
igen
igen
igen
nincs
igen
12
Amanda
9m3s
2m49s
igen
nincs
nincs
igen
igen
igen
igen
nincs
igen
igen
igen
igen
igen
nincs
igen
igen
igen
13
BackupPC
rsync
12m22s
7m42s
igen
nincs
igen
igen
igen
igen
igen
nincs
igen
nincs
nincs
igen
igen
nincs
igen
nincs
igen
10,5
kátrány
12m34s
12m15s
Táblázat jelmagyarázata:
- Zöld, öt percnél rövidebb üzemidő, vagy „Igen” válasz (kivéve a „Kliensszerverre van szüksége?” oszlop), 1 pont
- Sárga, üzemidő 0.5-XNUMX perc, XNUMX pont
- Piros, a munkaidő több mint tíz perc, vagy a válasz „Nem” (kivéve a „Szükséged van kliensszerverre?” oszlopot), 0 pont
A fenti táblázat szerint a legegyszerűbb, leggyorsabb és egyben kényelmes és hatékony biztonsági mentési eszköz a BorgBackup. A Restic a második helyet szerezte meg, a többi figyelembe vett jelölt megközelítőleg egyenlő helyezést ért el egy-két pont különbséggel a végén.
Köszönöm mindenkinek, aki végig olvasta a sorozatot, megkérlek benneteket, hogy beszéljétek meg a lehetőségeket és ajánljátok fel a sajátotokat, ha van. A megbeszélés előrehaladtával a táblázat bővíthető.
A sorozat eredménye az utolsó cikk lesz, amelyben egy olyan ideális, gyors és kezelhető biztonsági mentési eszköz kifejlesztésére tesznek kísérletet, amely lehetővé teszi egy másolat visszatelepítését a lehető legrövidebb időn belül, ugyanakkor kényelmes és egyszerű konfigurálásához és karbantartásához.
Közlemény
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: will.com