Miért kell biztonsági másolatot készíteni? Hiszen a berendezés nagyon-nagyon megbízható, ráadásul léteznek olyan „felhők”, amelyek megbízhatóbbak, mint a fizikai szerverek: megfelelő konfigurációval egy „felhős” szerver könnyen túléli egy infrastrukturális fizikai szerver meghibásodását, és a A szolgáltatást igénybe vevők szemszögéből kicsi, alig észrevehető ugrás következik be a szolgáltatásban. Ezenkívül az információk megkettőzése gyakran megköveteli a „extra” processzoridő, a lemezterhelés és a hálózati forgalom fizetését.
Az ideális program gyorsan fut, nem szivárog a memória, nincsenek lyukak, és nem is létezik.
-Ismeretlen
Mivel a programokat továbbra is fehérjefejlesztők írják, és gyakran nincs tesztelési folyamat, ráadásul a programokat ritkán szállítják a „best practices” (amelyek maguk is programok, ezért tökéletlenek) alapján, a rendszergazdáknak leggyakrabban olyan problémákat kell megoldaniuk, amelyek röviden hangzanak, de tömören: „vissza a régi állapotba”, „hozd normál működésre az alapot”, „lassan működik – görgess vissza”, és a kedvencem „nem tudom mi, de javítsd”.
A fejlesztők gondatlan munkájából vagy a körülmények kombinációjából adódó logikai hibákon kívül, valamint az építési programok apró jellemzőinek hiányos ismerete vagy félreértése - beleértve a csatlakozást és a rendszereket, beleértve az operációs rendszereket, illesztőprogramokat és firmware-t - egyéb hibák is vannak. Például a legtöbb fejlesztő a futási időre támaszkodik, teljesen megfeledkezve a fizikai törvényekről, amelyeket még mindig lehetetlen megkerülni programokkal. Ez magában foglalja a lemez alrendszer és általában minden adattárolási alrendszer (beleértve a RAM-ot és a processzor gyorsítótárát!) végtelen megbízhatóságát, a processzoron a nulla feldolgozási időt, valamint a hibák hiányát a hálózaton keresztüli átvitel és a feldolgozás során a feldolgozás során. processzorral, és hálózati késleltetéssel, ami 0-val egyenlő. Nem szabad elhanyagolni a hírhedt határidőt, mert ha nem tartod be időben, akkor a hálózat és a lemez működésének árnyalatainál is rosszabbak lesznek a problémák.
Mi a teendő azokkal a problémákkal, amelyek teljes erővel emelkednek, és értékes adatok felett lógnak? Az élő fejlesztőket semmi sem pótolja, és nem tény, hogy ez a közeljövőben lehetséges lesz. Másrészt csak néhány projektnek sikerült teljes mértékben igazolnia, hogy a program a tervezettnek megfelelően fog működni, és nem feltétlenül lehet majd átvenni és alkalmazni a bizonyítékokat más, hasonló projektekre. Ezenkívül az ilyen bizonyítékok sok időt vesznek igénybe, és speciális készségeket és ismereteket igényelnek, és ez gyakorlatilag minimálisra csökkenti a felhasználás lehetőségét, figyelembe véve a határidőket. Ráadásul még nem ismerjük az ultragyors, olcsó és végtelenül megbízható technológiát az információk tárolására, feldolgozására és továbbítására. Az ilyen technológiák, ha léteznek, koncepciók formájában vannak, vagy - leggyakrabban - csak tudományos-fantasztikus könyvekben és filmekben.
A jó művészek másolnak, a nagyok lopnak.
– Pablo Picasso.
A legsikeresebb megoldások és meglepően egyszerű dolgok általában ott történnek, ahol első pillantásra teljesen összeférhetetlen fogalmak, technológiák, ismeretek, tudományterületek találkoznak.
Például a madaraknak és a repülőgépeknek van szárnyuk, de a funkcionális hasonlóság ellenére - a működési elve egyes üzemmódokban ugyanaz, és a műszaki problémákat hasonló módon oldják meg: üreges csontok, erős és könnyű anyagok használata stb. - az eredmények teljesen mások, bár nagyon hasonlóak. A technológiánkban látható legjobb példák is nagyrészt a természetből származnak: a hajók és tengeralattjárók túlnyomásos rekeszei közvetlen analógiát jelentenek az annelidekkel; raid tömbök felépítése és az adatok integritásának ellenőrzése – a DNS-lánc megkettőzése; valamint a párosított szervek, a különböző szervek munkájának függetlensége a központi idegrendszertől (a szív automatizálása) és a reflexek - autonóm rendszerek az interneten. Természetesen a kész megoldások „fejjel” átvétele és alkalmazása tele van problémákkal, de ki tudja, talán nincs is más megoldás.
Ha tudtam volna, hova zuhansz, szalmát rakok!
— Fehérorosz népi közmondás
Ez azt jelenti, hogy a biztonsági másolatok létfontosságúak azok számára, akik:
- Legyen képes rendszerei működését minimális állásidővel, vagy akár anélkül is helyreállítani
- Cselekedjen bátran, mert hiba esetén mindig fennáll a visszalépés lehetősége
- Minimalizálja a szándékos adatsérülés következményeit
Íme egy kis elmélet
Bármilyen besorolás önkényes. A természet nem osztályoz. Osztályozunk, mert nekünk így kényelmesebb. És az általunk is tetszőlegesen vett adatok szerint osztályozunk.
– Jean Bruler
Függetlenül a fizikai tárolási módtól, a logikai adattárolás az adatok elérésének két módjára osztható: blokkra és fájlra. Ez a felosztás a közelmúltban nagyon elmosódott, mert nem létezik tisztán blokk, valamint tisztán fájl logikai tároló. Az egyszerűség kedvéért azonban feltételezzük, hogy léteznek.
A blokk adattárolás azt jelenti, hogy van egy fizikai eszköz, ahol az adatok bizonyos rögzített részekre, blokkokra vannak írva. A blokkokhoz egy bizonyos címen lehet hozzáférni, minden blokknak saját címe van az eszközön belül.
A biztonsági mentés általában adatblokkok másolásával történik. Az adatok integritásának biztosítása érdekében az új blokkok rögzítése, valamint a meglévők módosítása a másolás időpontjában felfüggesztésre kerül. Ha a hétköznapi világból veszünk egy hasonlatot, akkor a legközelebbi dolog egy szekrény azonos sorszámú cellákkal.
A logikai eszköz elvén alapuló fájl adattárolás közel áll a blokktároláshoz, és gyakran a tetejére szerveződik. Fontos különbségek a tárolási hierarchia és az ember által olvasható nevek jelenléte. Az absztrakciót fájl formájában osztják ki - egy elnevezett adatterületet, valamint egy könyvtárat - egy speciális fájlt, amelyben a leírások és más fájlokhoz való hozzáférés tárolódik. A fájlok további metaadatokkal is elláthatók: létrehozási idő, hozzáférési jelzők stb. A biztonsági mentések általában így készülnek: megkeresik a megváltozott fájlokat, majd átmásolják egy másik, azonos szerkezetű fájltárolóra. Az adatok integritását általában úgy valósítják meg, hogy hiányzik a fájlok írása. A fájlok metaadatairól ugyanúgy készül biztonsági mentés. A legközelebbi analógia egy könyvtár, amelyben különböző könyvek találhatók, és van egy katalógusa is, amelyben a könyvek ember által olvasható nevei szerepelnek.
Mostanában néha leírnak egy másik lehetőséget is, amelyből elvileg a fájl adattárolás kezdődött, és amely ugyanazokkal az archaikus tulajdonságokkal rendelkezik: az objektum adattárolása.
A fájltárolástól annyiban különbözik, hogy nem tartalmaz egynél több beágyazást (lapos séma), és a fájlnevek, bár ember által olvashatóak, mégis alkalmasabbak a gépi feldolgozásra. A biztonsági mentések során az objektumtárolást legtöbbször a fájltároláshoz hasonlóan kezelik, de esetenként más lehetőségek is vannak.
— Kétféle rendszergazda létezik, akik nem készítenek biztonsági másolatot, és azok, akik MÁR csinálnak.
- Igazából háromféle van: van olyan is, aki ellenőrzi, hogy a mentések visszaállíthatók-e.-Ismeretlen
Azt is érdemes megérteni, hogy magát az adatmentési folyamatot programok hajtják végre, így ugyanazok a hátrányai vannak, mint bármely más programnak. Az emberi tényezőtől való függés, valamint olyan tulajdonságok megszüntetésére (nem megszüntetésére!) - amelyek külön-külön nem fejtenek ki erős hatást, de együttesen érezhető hatást adhatnak - az ún. szabály 3-2-1. A megfejtésére sok lehetőség kínálkozik, de nekem a következő értelmezés tetszik jobban: 3 készletet kell tárolni azonos adatokból, 2 halmazt különböző formátumban, és 1 halmazt egy földrajzilag távoli tárolóban kell tárolni.
A tárolási formátumot a következőképpen kell érteni:
- Ha a fizikai tárolási módtól függ, megváltoztatjuk a fizikai módszert.
- Ha függ a logikai tárolási módszertől, akkor megváltoztatjuk a logikai módszert.
A 3-2-1 szabály maximális hatásának elérése érdekében ajánlatos a tárolási formátumot mindkét irányban megváltoztatni.
Abból a szempontból, hogy a biztonsági mentés készen áll-e a rendeltetési célra - a funkcionalitás visszaállítására - különbséget teszünk a „meleg” és a „hideg” mentések között. A melegek csak egy dologban különböznek a hidegektől: azonnal használatra készek, míg a hidegeknél további lépésekre van szükség a helyreállításhoz: dekódolás, kibontás az archívumból stb.
Ne keverje össze a hideg és meleg másolatokat az online és offline másolatokkal, amelyek az adatok fizikai elkülönítését jelentik, és valójában a biztonsági mentési módszerek osztályozásának újabb jelei. Tehát egy offline másolat - amely nem kapcsolódik közvetlenül a rendszerhez, ahol vissza kell állítani - lehet meleg vagy hideg (a helyreállítási készenlét szempontjából). Egy online példány közvetlenül elérhető ott, ahol helyre kell állítani, és legtöbbször meleg, de vannak hidegek is.
Ezenkívül ne felejtse el, hogy maga a biztonsági másolatok létrehozásának folyamata általában nem ér véget egy biztonsági másolat létrehozásával, és meglehetősen nagy számú másolat lehet. Ezért különbséget kell tenni a teljes biztonsági mentések között, pl. azok, amelyek más biztonsági mentésektől függetlenül visszaállíthatók, valamint differenciális (növekményes, differenciális, dekrementális stb.) másolatok - amelyek önállóan nem állíthatók vissza, és egy vagy több más biztonsági másolat előzetes visszaállítását igénylik.
A differenciális növekményes biztonsági mentések a mentési tárhely megtakarítására tett kísérletet. Így csak az előző biztonsági mentésből megváltozott adatok kerülnek a biztonsági másolatba.
A differenciális dekrementálisak ugyanarra a célra készülnek, de kissé eltérő módon: teljes biztonsági másolat készül, de valójában csak a friss és az előző másolat közötti különbség kerül tárolásra.
Külön érdemes megfontolni a tárolás feletti biztonsági mentés folyamatát, amely támogatja a másolatok tárolásának hiányát. Így ha teljes mentést írunk rá, akkor csak a biztonsági mentések közötti különbségek lesznek kiírva, de a mentések visszaállításának folyamata hasonló lesz a teljes másolatból történő visszaállításhoz és teljesen átlátható.
Quis gondozó ipsos custodes?
(Ki fogja magát az őröket őrizni? - lat.)
Nagyon kellemetlen, ha nincsenek biztonsági másolatok, de sokkal rosszabb, ha úgy tűnik, hogy készült biztonsági másolat, de visszaállításkor kiderül, hogy nem lehet visszaállítani, mert:
- A forrásadatok integritása veszélybe került.
- A biztonsági mentési tároló sérült.
- A helyreállítás nagyon lassan működik, nem használhatja fel a részben helyreállított adatokat.
A megfelelően felépített biztonsági mentési folyamatnak figyelembe kell vennie az ilyen megjegyzéseket, különösen az első kettőt.
A forrásadatok sértetlensége többféleképpen garantálható. A leggyakrabban használtak a következők: a) pillanatképek készítése a fájlrendszerről blokk szinten, b) a fájlrendszer állapotának „lefagyasztása”, c) speciális blokkeszköz verziótárolóval, d) fájlok szekvenciális rögzítése ill. blokkok. A rendszer ellenőrző összegeket is alkalmaz az adatok ellenőrzésének biztosítására a helyreállítás során.
A tárhely sérülése ellenőrző összegekkel is kimutatható. További módszer a speciális eszközök vagy fájlrendszerek használata, amelyekben a már rögzített adatok nem módosíthatók, de újak hozzáadhatók.
A helyreállítás felgyorsítása érdekében az adat-helyreállítást többféle helyreállítási folyamattal használják – feltéve, hogy nincs szűk keresztmetszet lassú hálózat vagy lassú lemezrendszer formájában. A részlegesen helyreállított adatokkal kapcsolatos helyzet megkerüléséhez a biztonsági mentési folyamatot viszonylag kis részfeladatokra bonthatja, amelyek mindegyike külön-külön történik. Így lehetővé válik a teljesítmény következetes visszaállítása a helyreállítási idő előrejelzése mellett. Ez a probléma leggyakrabban a szervezeti síkban (SLA) rejlik, ezért erre nem térünk ki részletesen.
A fűszerek szakértője nem az, aki minden ételhez hozzáadja, hanem az, aki soha nem tesz bele semmi pluszt.
-BAN BEN. Szinyavszkij
A rendszergazdák által használt szoftverekkel kapcsolatos gyakorlatok eltérőek lehetnek, de az általános elvek így vagy úgy továbbra is ugyanazok, különösen:
- Nyomatékosan javasolt kész megoldások használata.
- A programoknak kiszámíthatóan kell működniük, pl. Nem lehetnek dokumentálatlan funkciók vagy szűk keresztmetszetek.
- Az egyes programok beállításának olyan egyszerűnek kell lennie, hogy ne kelljen minden alkalommal elolvasnia a kézikönyvet vagy a csalólapot.
- Lehetőleg egyetemes legyen a megoldás, mert A szerverek hardverjellemzői nagyon eltérőek lehetnek.
A következő általános programok állnak rendelkezésre a blokkeszközökről készült biztonsági mentések készítésére:
- dd, a rendszeradminisztrációs veteránok számára ismerős, ebbe is beletartoznak a hasonló programok (például ugyanaz a dd_rescue).
- Egyes fájlrendszerekbe beépített segédprogramok, amelyek kiíratják a fájlrendszert.
- Mindenevő közművek; például partclone.
- Saját, gyakran tulajdonosi döntések; például a NortonGhost és újabb.
Fájlrendszerek esetén a biztonsági mentési probléma részben megoldható a blokkeszközökre alkalmazható módszerekkel, de a probléma hatékonyabban megoldható például:
- Rsync, egy általános célú program és protokoll a fájlrendszerek állapotának szinkronizálására.
- Beépített archiváló eszközök (ZFS).
- Harmadik féltől származó archiváló eszközök; legnépszerűbb képviselője a tar. Vannak mások, például a dar - a kátrány helyettesítője, amely a modern rendszerekre irányul.
Külön érdemes megemlíteni a biztonsági másolatok készítésekor az adatkonzisztenciát biztosító szoftvereszközöket. A leggyakrabban használt lehetőségek a következők:
- A fájlrendszer felcsatolása csak olvasható módban (ReadOnly), vagy a fájlrendszer lefagyasztása (freeze) - a módszer korlátozottan alkalmazható.
- Pillanatképek készítése a fájlrendszerek vagy blokkeszközök állapotáról (LVM, ZFS).
- Harmadik féltől származó eszközök használata a megjelenítések szervezésére, még olyan esetekben is, amikor az előző pontok valamilyen okból nem biztosíthatók (például hotcopy programok).
- A másolás-váltás technika (CopyOnWrite), azonban leggyakrabban a használt fájlrendszerhez (BTRFS, ZFS) kötődik.
Tehát egy kis szerverhez biztonsági mentési sémát kell biztosítania, amely megfelel a következő követelményeknek:
- Könnyen használható – a működés során nincs szükség különleges további lépésekre, minimális lépések szükségesek a másolatok létrehozásához és visszaállításához.
- Univerzális - nagy és kis szervereken is működik; ez fontos a szerverek számának növelésekor vagy a méretezéskor.
- Csomagkezelő telepíti, vagy egy vagy két paranccsal, például „letöltés és kicsomagolás” segítségével.
- Stabil - szabványos vagy régóta bevált tárolási formátumot használnak.
- Gyors a munkában.
Azok közül, akik többé-kevésbé megfelelnek a követelményeknek:
- rdiff-backup
- rsnapshot
- böfög
- másolat
- kétszínűség
- hadd dup
- dar
- zbackup
- restic
- borgbackup
A következő jellemzőkkel rendelkező virtuális gép (XenServer alapú) kerül felhasználásra tesztpadként:
- 4 mag 2.5 GHz,
- 16 GB RAM,
- 50 GB hibrid tárhely (tárolórendszer gyorsítótárazással SSD-n a virtuális lemez méretének 20%-a) külön virtuális lemez formájában particionálás nélkül,
- 200 Mbit Internet csatorna.
Szinte ugyanazt a gépet fogják használni tartalék vevőszervernek, csak 500 GB-os merevlemezzel.
Operációs rendszer - Centos 7 x64: szabványos partíció, adatforrásként további partíció kerül felhasználásra.
Kiinduló adatként vegyünk egy WordPress oldalt 40 GB médiafájllal és egy mysql adatbázissal. Mivel a virtuális szerverek jellemzői és a jobb reprodukálhatóság érdekében nagyon eltérőek, itt van
szervertesztelési eredmények sysbench használatával.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu futtatása
sysbench 1.1.0-18a9f86 (csomagolt LuaJIT 2.1.0-beta3 használatával)
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őtől
Prímszámhatár: 20000
Munkavállalói szálak inicializálása…
A szálak elkezdődtek!
CPU sebesség:
események másodpercenként: 836.69
Teljesítmény:
események/s (eps): 836.6908
eltelt idő: 30.0039s
rendezvények száma összesen: 25104
Késési idő (ms):
min: 2.38
átlag: 4.78
max: 22.39
95. percentilis: 10.46
összeg: 119923.64
Szálak igazságossága:
események (átl./stddev): 6276.0000/13.91
végrehajtási idő (átl./stddev): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=memória olvasása
sysbench 1.1.0-18a9f86 (csomagolt LuaJIT 2.1.0-beta3 használatával)
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őtől
Memóriasebesség-teszt futtatása a következő lehetőségekkel:
blokk mérete: 1KiB
teljes méret: 102400MiB
művelet: olvassa el
hatálya: globális
Munkavállalói szálak inicializálása…
A szálak elkezdődtek!
Összes művelet: 50900446 (1696677.10 másodpercenként)
49707.47 MiB átvitt (1656.91 MiB/sec)
Teljesítmény:
események/s (eps): 1696677.1017
eltelt idő: 30.0001s
rendezvények száma összesen: 50900446
Késési idő (ms):
min: 0.00
átlag: 0.00
max: 24.01
95. percentilis: 0.00
összeg: 39106.74
Szálak igazságossága:
események (átl./stddev): 12725111.5000/137775.15
végrehajtási idő (átl./stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=írási memória futtatása
sysbench 1.1.0-18a9f86 (csomagolt LuaJIT 2.1.0-beta3 használatával)
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őtől
Memóriasebesség-teszt futtatása a következő lehetőségekkel:
blokk mérete: 1KiB
teljes méret: 102400MiB
művelet: írás
hatálya: globális
Munkavállalói szálak inicializálása…
A szálak elkezdődtek!
Összes művelet: 35910413 (1197008.62 másodpercenként)
35068.76 MiB átvitt (1168.95 MiB/sec)
Teljesítmény:
események/s (eps): 1197008.6179
eltelt idő: 30.0001s
rendezvények száma összesen: 35910413
Késési idő (ms):
min: 0.00
átlag: 0.00
max: 16.90
95. percentilis: 0.00
összeg: 43604.83
Szálak igazságossága:
események (átl./stddev): 8977603.2500/233905.84
végrehajtási idő (átl./stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (csomagolt LuaJIT 2.1.0-beta3 használatával)
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őtől
Extra fájlmegnyitási jelzők: (nincs)
128 fájl, egyenként 8 MB
1 GiB teljes fájlméret
A blokk mérete 4 KiB
IO kérések száma: 0
Olvasási/írási arány kombinált véletlenszerű IO-teszthez: 1.50
Az időszakos FSYNC engedélyezve van, minden 100 kérés után meghívja az fsync() függvényt.
Az fsync() meghívása a teszt végén, Enabled.
Szinkron I/O mód használata
Véletlenszerű R/W teszt elvégzése
Munkavállalói szálak inicializálása…
A szálak elkezdődtek!
Teljesítmény:
olvasott: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
írás: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Késési idő (ms):
min: 0.00
átlag: 0.27
max: 18.01
95. percentilis: 1.08
összeg: 238469.45
Ez a jegyzet nagyot kezd
cikksorozat a biztonsági mentésről
- Biztonsági mentés, 1. rész: Miért van szükség biztonsági mentésre, módszerek, technológiák áttekintése
- Biztonsági mentés 2. rész: Az rsync alapú biztonsági mentési eszközök áttekintése és tesztelése
- Biztonsági mentés 3. rész: A kettősség, a duplikáció, a 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 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
Forrás: will.com