Ez a megjegyzés folytatódik
a biztonsági mentések ciklusában
- Biztonsági mentés, 2. rész: Az rsync-alapú biztonsági mentő eszközök áttekintése és tesztelése
- Biztonsági mentés, 3. rész: A duplicity, duplicaty, 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
Ahogyan azt már az első cikkben írtuk, számos rsync alapú biztonsági mentőprogram létezik.
A legjobban a követelményeknek megfelelő programok közül hármat fogok megvizsgálni: rdiff-backup, rsnapshot és burp.
Tesztfájl készletek
A teszteléshez használt fájlhalmazok az összes jelölt számára azonosak lesznek, beleértve a jövőbeli cikkeket is.
Első készlet: 10 GB médiafájl, és körülbelül 50 MB — a php webhely forráskódja, a fájlok mérete néhány kilobyte-tól, a médiafájloké pedig tucatnyi megabájtig terjed. Cél — statikus webhely szimulálása.
Második készlet: az elsőből származik a médiafájlokat tartalmazó alkönyvtár átnevezésével, 5 GB méretben. Cél — a biztonsági mentési rendszer viselkedésének tanulmányozása az alkönyvtár átnevezésekor.
Harmadik készlet: az elsőből származik, 3 GB médiafájl törlésével és újabb 3 GB médiafájl hozzáadásával. Cél — a biztonsági mentési rendszer viselkedésének tanulmányozása a weboldal frissítésekor.
Eredmények megszerzése
Bármely biztonsági mentést minimum 3 alkalommal hajtanak végre, és a fájlrendszer gyorsítótárazásának törlését kísérik a következő parancsokkal: sync és echo 3 > /proc/sys/vm/drop_caches mind a tesztszerveren, mind a biztonsági másolatok tároló szerverén.
A biztonsági mentési forrást biztosító szerveren monitoring szoftver van telepítve — netdata, amellyel a szerver terhelését fogják értékelni a másolás során, ez szükséges a biztonsági mentés során fellépő terhelés becsléséhez.
Azt is tartom, hogy a biztonsági másolatok tároló szerverének processzora lassabb, mint a főszerveré, de nagyobb kapacitású diszkjei vannak, viszonylag alacsony véletlenszerű írási sebességgel — ez a leggyakoribb helyzet a biztonsági mentés során, és mivel a biztonsági másolatot készítő szervernek valójában nem kell más feladatokat végeznie, csak biztonsági mentéseket, a terhelését netdata segítségével nem fogom nyomon követni.
A szervereim is megváltoztak, amelyekkel különböző biztonsági mentési rendszereket fogok ellenőrizni.
Jelenleg a következő jellemzőkkel rendelkeznekProcesszor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu futtatás
sysbench 1.0.17 (system LuaJIT 2.0.4 előfizetéssel)
A teszt futtatása a következő lehetőségekkel:
Szálak száma: 2
A véletlenszám-generátor inicializálása az aktuális időből
Prímtényezők határértéke: 20000
A munkafolyamatok inicializálása...
Szálak elindultak!
CPU sebessége:
események másodpercenként: 1081.62
Általános statisztikák:
összes idő: 30.0013s
események összes száma: 32453
Késleltetés (ms):
min: 1.48
avg: 1.85
max: 9.84
95. percentilis: 2.07
összeg: 59973.40
Szálak igazságossága:
események (avg/stddev): 16226.5000/57.50
végrehajtási idő (avg/stddev): 29.9867/0.00
RAM, olvasás…
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory futtatás
sysbench 1.0.17 (system LuaJIT 2.0.4 előfizetéssel)
A teszt futtatása a következő lehetőségekkel:
Szálak száma: 4
A véletlenszám-generátor inicializálása az aktuális időből
Memóriaspeed teszt futtatása a következő lehetőségekkel:
blokk mérete: 1KiB
összes méret: 102400MiB
működés: olvasás
hatókör: globális
A munkafolyamatok inicializálása...
Szálak elindultak!
Összes műveletek: 104857600 (5837637.63 másodpercenként)
102400.00 MiB átvitel (5700.82 MiB/sec)
Általános statisztikák:
összes idő: 17.9540s
események összes száma: 104857600
Késleltetés (ms):
min: 0.00
avg: 0.00
max: 66.08
95. percentilis: 0.00
összeg: 18544.64
Szálak igazságossága:
események (avg/stddev): 26214400.0000/0.00
végrehajtási idő (avg/stddev): 4.6362/0.12
… és írás
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory futtatás
sysbench 1.0.17 (system LuaJIT 2.0.4 előfizetéssel)
A teszt futtatása a következő lehetőségekkel:
Szálak száma: 4
A véletlenszám-generátor inicializálása az aktuális időből
Memóriaspeed teszt futtatása a következő lehetőségekkel:
blokk mérete: 1KiB
összes méret: 102400MiB
működés: írás
hatókör: globális
A munkafolyamatok inicializálása...
Szálak elindultak!
Összes műveletek: 91414596 (3046752.56 másodpercenként)
89272.07 MiB átvitel (2975.34 MiB/sec)
Általános statisztikák:
összes idő: 30.0019s
események összes száma: 91414596
Késleltetés (ms):
min: 0.00
avg: 0.00
max: 1022.90
95. percentilis: 0.00
összeg: 66430.91
Szálak igazságossága:
események (avg/stddev): 22853649.0000/945488.53
végrehajtási idő (avg/stddev): 16.6077/1.76
Adatok forrás szerver
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
A teszt futtatása a következő opciókkal:
Szálak száma: 4
A véletlenszám-generátor inicializálása a jelenlegi időből
További fájlok megnyitási zászlói: (nincs)
128 fájl, egyenként 8MiB
1GiB összes fájlméret
Blokk méret 4KiB
IO kérelmek száma: 0
Olvasási/írási arány a kombinált véletlenszerű IO teszt számára: 1.50
Időszakos FSYNC engedélyezve, a fsync() hívása 100 kérésenként.
A teszt végén a fsync() hívása, Engedélyezve.
Szinkron I/O mód használata
Véletlenszerű r/w teszt végrehajtása
A munkaszálak inicializálása...
Szálak elindítva!
Fájlműveletek:
olvasás/s: 4587.95
írás/s: 3058.66
fsyncs/s: 9795.73
Átviteli sebesség:
olvasás, MiB/s: 17.92
írt, MiB/s: 11.95
Általános statisztikák:
összes idő: 60.0241s
események összes száma: 1046492
Késleltetés (ms):
min: 0.00
avg: 0.23
max: 14.45
95. percentilis: 0.94
összeg: 238629.34
Szálak igazságossága:
események (átlag/szórás): 261623.0000/1849.14
végrehajtási idő (átlag/szórás): 59.6573/0.00
A biztonsági mentések tárolására szolgáló szerver lemeze
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
A teszt futtatása a következő opciókkal:
Szálak száma: 4
A véletlenszám-generátor inicializálása a jelenlegi időből
További fájlok megnyitási zászlói: (nincs)
128 fájl, egyenként 8MiB
1GiB összes fájlméret
Blokk méret 4KiB
IO kérelmek száma: 0
Olvasási/írási arány a kombinált véletlenszerű IO teszt számára: 1.50
Időszakos FSYNC engedélyezve, a fsync() hívása 100 kérésenként.
A teszt végén a fsync() hívása, Engedélyezve.
Szinkron I/O mód használata
Véletlenszerű r/w teszt végrehajtása
A munkaszálak inicializálása...
Szálak elindítva!
Fájlműveletek:
olvasás/s: 11.37
írás/s: 7.58
fsyncs/s: 29.99
Átviteli sebesség:
olvasás, MiB/s: 0.04
írt, MiB/s: 0.03
Általános statisztikák:
összes idő: 73.8868s
események összes száma: 3104
Késleltetés (ms):
min: 0.00
avg: 78.57
max: 3840.90
95. percentilis: 297.92
összeg: 243886.02
Szálak igazságossága:
események (átlag/szórás): 776.0000/133.26
végrehajtási idő (átlag/szórás): 60.9715/1.59
A hálózati sebesség a szerverek között
iperf3 -c backup
Csatlakozás a backup hoszthoz, 5201-es porton
[ 4] helyi x.x.x.x 59402-es port csatlakozva y.y.y.y 5201-es porthoz
[ ID] Időtartam Átvitel Sávszélesség Retr Cwnd
[ 4] 0.00-1.00 sec 419 MByte 3.52 Gbit/s 810 182 KByte
[ 4] 1.00-2.00 sec 393 MByte 3.30 Gbit/s 810 228 KByte
[ 4] 2.00-3.00 sec 378 MByte 3.17 Gbit/s 810 197 KByte
[ 4] 3.00-4.00 sec 380 MByte 3.19 Gbit/s 855 198 KByte
[ 4] 4.00-5.00 sec 375 MByte 3.15 Gbit/s 810 182 KByte
[ 4] 5.00-6.00 sec 379 MByte 3.17 Gbit/s 765 228 KByte
[ 4] 6.00-7.00 sec 376 MByte 3.15 Gbit/s 810 180 KByte
[ 4] 7.00-8.00 sec 379 MByte 3.18 Gbit/s 765 253 KByte
[ 4] 8.00-9.00 sec 380 MByte 3.19 Gbit/s 810 239 KByte
[ 4] 9.00-10.00 sec 411 MByte 3.44 Gbit/s 855 184 KByte
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Időtartam Átvitel Sávszélesség Retr
[ 4] 0.00-10.00 sec 3.78 GByte 3.25 Gbit/s 8100 küldő
[ 4] 0.00-10.00 sec 3.78 GByte 3.25 Gbit/s fogadó
A teszt módszertana
- A tesztszerveren a fájlrendszer előkészítése az első tesztsorozathoz zajlik, a biztonsági mentés tárolásáért felelős szerveren szükség esetén inicializálódik a tároló.
Megkezdődik a biztonsági mentési folyamat, és mérik az időt. - A tesztszerveren a fájlok migrációja történik a második tesztsorozatra. Megkezdődik a biztonsági mentési folyamat, és mérik az időt.
- A tesztszerveren a migráció a harmadik tesztsorozatra történik. Megkezdődik a biztonsági mentési folyamat, és mérik az időt.
- A kapott harmadik tesztsorozat új elsőként kerül elfogadásra; az 1-3. pontot még 2 alkalommal megismétlik.
- Az adatok összegző táblázatba kerülnek, grafikonok kerülnek hozzáadásra a netdata-val.
- Jelentés készül az egyes biztonsági mentési módszerről.
Várt eredmények
Mivel mind a 3 jelölt ugyanazon a technológián (rsync) alapul, várható, hogy az eredmények közel állnak a megszokott rsync eredményekhez, beleértve annak minden előnyét, nevezetesen:
- A tárolóban lévő fájlok "ahogy vannak" tárolódnak.
- A tároló mérete csak a biztonsági mentések közötti eltéréseket tartalmazza.
- Viszonylag nagy terhelés lesz a hálózaton az adatok átadása során, valamint kis mértékű terhelés a processzornál.
A szokásos rsync próba a referenciaértékeként fog szolgálni, eredményei
ilyenek
A szűk keresztmetszet a biztonsági mentési adatok tárolására szolgáló HDD-bázisú lemezen volt, amit a grafikákon fűrészfogszerűen világosan látható.
Az adatok másolása 4 perc 15 másodpercet vett igénybe.
rdiff-backup tesztelése
Az első jelölt a rdiff-backup, egy Python alapú skript, amely egy könyvtár biztonsági másolatának készítésére szolgál egy másikban. A jelenlegi biztonsági másolat 'felcímkézve' tárolódik, míg a korábbi biztonsági másolatok egy speciális almappába incrementálisan kerülnek, így helyet takarítunk meg.
Ellenőrizzük a tipikus működési módot, azaz a biztonsági mentési folyamat elindítása a kliens által történik, míg a szerveren egy olyan folyamat indul el a biztonsági mentéshez, amely az adatokat fogadja.
Nézzük meg, mire képes a mi körülményeink között..
Minden tesztindítás futási ideje:
Első indítás
Második indítás
Harmadik indítás
Első készlet
16p32m
16p26mp
16p19m
Második készlet
2ó5p
2ó10p
2ó8p
Harmadik készlet
2ó9p
2ó10p
2ó10p
A rdiff-backup nagyon érzékenyen reagál bármilyen nagyobb adatváltozásra, és nem használja ki teljesen a hálózatot.
A rsnapshot tesztelése
A második jelölt a rsnapshot, egy Perl alapú skript, amelynek fő követelménye a hatékony működéshez a kemény hivatkozások támogatása. Így a lemezen helyet takarítunk meg. Azok a fájlok, amelyek nem változtak meg az előző biztonsági másolat óta, a kemény hivatkozások segítségével az eredeti fájlra mutatnak.
A biztonsági mentési folyamat logikája is meg lett fordítva: a szerver aktívan 'jár' a klienseknél, és begyűjti az adatokat.
Tesztelési eredmények
az alábbiak születtek
Első indítás
Második indítás
Harmadik indítás
Első készlet
4p22m
4p19mp
4p16m
Második készlet
2p6m
2p10m
2p6m
Harmadik készlet
1p18m
1p10m
1p10m
Nagyon gyorsan teljesített, sokkal gyorsabban, mint a rdiff-backup, és nagyon közel a tiszta rsync-hez.
A burp tesztelése
Egy másik lehetőség a C nyelvű, a librsync fölötti megvalósítás — a burp, amely ügyfél-szerver architektúrával rendelkezik, beleértve az ügyfelek hitelesítését, valamint webes felületet tartalmaz (nem része az alapcsomagnak). Egy másik érdekes jellemző — a biztonsági másolatok készítése a kliensek helyreállítási jogainak nélkül.
Nézzük megteljesítmény.
Első indítás
Második indítás
Harmadik indítás
Első készlet
11p21m
11p10m
10p56m
Második készlet
5p37m
5m40s
5m35s
Harmadik készlet
3p33m
3p24m
3p40m
Kétszer olyan lassan működött, mint a rsnapshot, de még mindig elég gyors, és biztosan gyorsabb, mint a rdiff-backup. A grafikonok kissé hullámosak — a teljesítmény ismét a biztonsági mentések tárolására szolgáló lemezkörnyezettől függ, bár ez nem annyira kifejezett, mint a rsnapshot esetében.
Eredmények
A jelöltek tárolóinak mérete körülbelül azonos volt, vagyis először 10 GB-ra, majd 15 GB-ra, végül 18 GB-ra nőtt, ami a rsync működésével kapcsolatos. Érdemes megjegyezni, hogy minden jelölt egyszálú feldolgozást használt (a CPU kihasználtság körülbelül 50% egy kétmagos gépen). Mindhárom jelölt lehetőséget biztosított az utolsó biztonsági mentés visszaállítására "olyan formában", ami azt jelenti, hogy fájlokat lehetett visszaállítani bármilyen külső program alkalmazása nélkül, beleértve azokat is, amelyeket a tárolók létrehozásához használtak. Ez is a rsync "öröksége".
Következtetések
Minél bonyolultabb egy biztonsági mentési rendszer, és minél több funkcióval rendelkezik – annál lassabban fog működni, de a nem túl igényes projektek számára bármelyik megfelel, kivéve talán az rdiff-backup-ot.
Bejelentés
Ez a jegyzet folytatja a biztonsági mentéssel foglalkozó ciklust
Biztonsági mentés, 2. rész: A rsync-alapú biztonsági mentési eszközök áttekintése és tesztelése
Biztonsági mentés, 3. rész: A duplicity, duplicaty, 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 Demkovich
Forrás: habr.com
