Miért is szükséges biztonsági másolatot készíteni? Hiszen a berendezések meglehetősen megbízhatóak, és ott vannak a „felhők”, amelyek megbízhatóságukban jobbak a fizikai szervereknél: helyes beállítás esetén a „felhős” szerver könnyen túlélheti egy fizikai infrastruktúra leállását, ráadásul a szolgáltatások felhasználói számára ez csupán egy kis, alig észlelhető késlekedés időben. Továbbá, az információk másolása gyakran extra processzorterhelést, lemezterhelést és hálózati forgalmat igényel.
Az ideális program gyorsan működik, nem szivárog ki a memóriából, nincsenek hibái és nem létezik.
—Ismeretlen
Mivel a programokat még mindig emberi fejlesztők írják, a tesztelési folyamat gyakran hiányzik, és a programok szolgáltatása is ritkán történik meg a „legjobb gyakorlatok” alkalmazásával (amelyek maguk is programok, tehát nem tökéletesek), a rendszergazdáknak többnyire olyan feladatokat kell megoldaniuk, amelyek röviden, de találóan hangzanak: „visszaállítani, ahogy volt”, „visszaállítani az adatbázist a normális működéshez”, „lassan működik - visszagordulunk”, valamint a kedvencem „nem tudom, mi az, de javítani kell”.
A fejlesztők gondatlanságából származó logikai hibák mellett, mint a véletlen egybeesések, valamint a programok felépítésének apró részleteivel való hiányos tudás vagy megértés - ideértve a kapcsolódó és rendszerszintű dolgokat, például az operációs rendszereket, illesztőprogramokat és firmware-t - más hibák is léteznek. Például a legtöbb fejlesztő a futási környezetre támaszkodik, teljesen megfeledkezve a fizikai törvényekről, amelyeket program segítségével még mindig lehetetlen megkerülni. Ez magában foglalja a lemezes alrendszer és általában bármilyen tárolási alrendszer (beleértve a RAM-ot és a processzor cache-t!) végtelen megbízhatóságát, a processzornál nulladik feldolgozási időt, a hálózati átvitelnél és a processzor feldolgozásánál hibák hiányát, valamint a 0-ás hálózati késleltetéseket. A hírhedt határidőt sem szabad figyelmen kívül hagyni, mert ha nem sikerül tartani - akkor problémák merülnek fel a hálózat és a lemez működésének apróbb részleteinél.
Mi legyen a problémákkal, amelyek szemben állnak és fenyegetik az értékes adatokat? Az élő fejlesztőket nem lehet pótolni, és nem biztos, hogy a közeljövőben lehetséges lesz. Másrészt teljes bizonyítékot eddig csak néhány projekt tudott felmutatni arra, hogy a program úgy működik, ahogy azt elképzelték, és nem feltétlenül lehet az ilyen bizonyítékokat más, hasonló projektekre átváltani. Az ilyen bizonyítékok ráadásul rengeteg időt igényelnek, és különleges készségeket és tudást követelnek, ami gyakorlatilag minimalizálja a használatuk lehetőségét a határidők figyelembevételével. Ráadásul még nem tudunk szupergyors, olcsó és végtelenül megbízható adatmegtartó, feldolgozó és továbbító technológiákról. Az ilyen technológiák, ha léteznek, akkor általában csak koncepciók formájában találhatók meg, vagy — leggyakrabban — csak a fantasztikus könyvekben és filmekben.
A jó művészek másolnak, a nagyszerű művészek lopnak.
—Pablo Picasso.
A legjobban sikerült megoldások és a meglepően egyszerű dolgok általában ott jönnek létre, ahol látszólag teljesen összeegyeztethetetlen fogalmak, technológiák, tudományágak találkoznak.
Például a madaraknak és a repülőgépeknek is vannak szárnyaik, azonban a funkcionális hasonlóság ellenére — bizonyos üzemmódokban a működési elv egybeesik, és a technikai problémák hasonló módon oldhatók meg: üreges csontok, tartós és könnyű anyagok használata stb. — az eredmények teljesen eltérőek, bár igen hasonlóak. A legjobb minták, amelyeket a technikánkban megfigyelünk, szintén nagyrészt a természettől származnak: a zárt rekeszek a hajókon és tengeralattjárókon közvetlen analógia a gyűrűsférgekkel; a raid tömbök kiépítése és az adatok integritásának ellenőrzése — a DNS-lánc duplikálása; valamint a páratlan szervek, különböző szervek független működése a központi idegrendszertől (a szív munkájának automatizálása) és a reflexek — autonóm rendszerek az Interneten. Természetesen a meglévő megoldások „vágatlan” alkalmazása problémákkal járhat, de ki tudja, lehet, hogy nincsenek más megoldások.
Jó lenne tudni, hol fogsz elesni — akkor szalmát tennék alá!
—Belorusz népi közmondás.
Tehát a biztonsági mentések létfontosságúak azok számára, akik azt kívánják:
- Lehetőséget kapni arra, hogy rendszereik működését minimális leállással, sőt, akár teljesen leállás nélkül helyreállítsák.
- Bátor cselekedni, mert hiba esetén van lehetőség a visszaállításra
- Minimalizálni a szándékos adatkárosítás következményeit
Itt egy kis elmélet
Bármilyen klasszifikáció önkényes. A természet nem klasszifikál. Mi magunk klasszifikálunk, mert számunkra így kényelmesebb, és olyan adatok alapján, amelyeket szintén önkényesen választunk ki.
—Jean Bruyère
Fizikai tárolási módtól függetlenül a logikai adatkezelést kétféle hozzáférés szerinti módra oszthatjuk: blokk és fájl alapú. Ez a felosztás az utóbbi időben eléggé elmosódott, mert tisztán blokk- vagy tisztán fájl alapú logikai tárolók nem léteznek. Az egyszerűség kedvéért azonban feltételezhetjük, hogy léteznek.
A blokk alapú adatkezelés azt jelenti, hogy van egy fizikai eszköz, ahová az adatokat meghatározott fix adagokban, blokkokban írják. A blokkokhoz egy adott cím alapján lehet hozzáférni, minden blokk saját címmel rendelkezik az eszközön belül.
A biztonsági mentés általában az adatok blokkjainak másolásával történik. Az adatok integritásának biztosítása érdekében a másolás időpontjában leállítják az új blokkok írását, valamint a meglévők módosítását. Ha a hagyományos világ analógiáját nézzük, legközelebb a kiszolgálóhoz hasonlítható, amely azonos számú rekeszekkel rendelkezik.
A fájl alapú adatkezelés logikai eszközszinten közel áll a blokk alapúhoz, és gyakran annak felszíne felett szerveződik. Fontos különbségek a tárolás hierarchiájának jelenléte és az ember által érthető nevek. Kiemelkedik az absztrakció, mint például a fájl - egy elnevezett adatmező, valamint a könyvtár - egy speciális fájl, amely leírásokat és hozzáféréseket tárol más fájlokhoz. A fájlok kiegészítő metaadatokkal is elláthatók: létrehozási idő, hozzáférési jelzők stb. Általában úgy végzik a biztonsági mentést: megkeresik a módosított fájlokat, majd azokat egy másik, szerkezetében azonos fájl tárolóba másolják. Az adatok integritását általában az írás alatt álló fájlok hiányával valósítják meg. A fájlok metaadatai hasonlóképpen mentésre kerülnek. A legközelebbi analógia egy könyvtár, amely különböző könyvekkel rendelkező szekciókat tartalmaz, és van egy könyvkatalógus érthető nevekkel.
Az utóbbi időben néha egy másik lehetőséget említenek, amely a fájlok tárolásának alapját képezte, és ugyanazokkal az archaikus vonásokkal rendelkezik: az objektum alapú tárolás.
A fájlok tárolásától az különbözteti meg, hogy nem rendelkezik több szint mélységgel (lapos séma), és bár a fájlnevek emberi olvasásra alkalmasak, mégis inkább gépi feldolgozásra vannak optimalizálva. Biztonsági mentés esetén az objektum tárolók többségét a fájlokhoz hasonlóan kezelik, de néha vannak más lehetőségek is.
— Kétféle rendszergazda létezik: aki nem készít biztonsági mentéseket, és aki MÁR készít.
— Valójában háromféle létezik: van még, aki ellenőrzi, hogy a biztonsági mentések visszaállíthatók-e.—Ismeretlen
Azt is érdemes megérteni, hogy a biztonsági adatok mentésének folyamata programok által történik, ezért minden olyan hátránya van, mint bármely más programnak. Az emberi tényezőtől való függetlenség érdekében, valamint a jellemzőktől — amelyek külön-külön nem sokat számítanak, de együtt jelentős hatást gyakorolhatnak — a 3-2-1 szabályt alkalmazzák. Sokféleképpen lehet értelmezni, de számomra a következő értelmezés tetszik a legjobban: 3 azonos adatcsomagot kell tárolni, 2 csomagot különböző formátumokban kell megőrizni, és 1 csomagot földrajzilag távoli tárolóban kell tartani.
A tárolási formát a következőképpen kell érteni:
- Ha függőség van a fizikai tárolási módoktól, akkor módosítjuk a fizikai tárolási módot.
- Ha függőség van a logikai tárolási módoktól, akkor módosítjuk a logikai tárolási módot.
A 3-2-1 szabály maximális hatásának elérése érdekében javasolt a tárolási formát mindkét módon megváltoztatni.
A biztonsági mentés készültsége szempontjából — amely a működés helyreállítását célozza — a "forró" és "hideg" biztonsági mentéseket különböztetjük meg. A forró biztonsági mentések a hideg biztonsági mentésektől mindössze abban különböznek, hogy azonnal munkára kész állapotban vannak, míg a hideg mentések helyreállítása némi további lépést igényel: dekódolást, archiválásból való kibontást stb.
Ne keverjük össze a forró és hideg másolatokat az online és offline másolatokkal, amelyek fizikai adatizolációt feltételeznek, és lényegében másfajta biztonsági másolatok osztályozásának jelei. Így egy offline másolat – amely nincs közvetlenül csatlakoztatva ahhoz a rendszerhez, ahol vissza kell állítani – lehet forró vagy hideg (a helyreállítási készség szempontjából). Az online másolat közvetlenül elérhető ott, ahol szükség van a helyreállításra, és leggyakrabban forró, de hideg is lehet.
Ezen kívül ne felejtsük el, hogy a biztonsági másolatok készítési folyamata általában nem ér véget egyetlen biztonsági másolat elkészítésével, és a másolatok száma meglehetősen nagy lehet. Ennek megfelelően különbséget kell tenni a teljes biztonsági másolatok között, azaz azok között, amelyek más biztonsági másolatoktól függetlenül helyreállíthatók, valamint a differenciált (inkrementális, differenciális, dekrementális stb.) másolatok között – amelyek önállóan nem helyreállíthatók, és előzetes helyreállítást igényelnek egy vagy több másik biztonsági másolatból.
A differenciált inkrementális másolatok a biztonsági másolatok tárolási méretének csökkentésére tett kísérlet. Így a biztonsági másolatba csak a legutóbbi másolathoz képest megváltozott adatok kerülnek.
A differenciált dekrementális másolatok ugyanazzal a céllal készülnek, de egy kicsit más módon: egy teljes biztonsági másolat készül, de valójában csak a friss másolat és az előző közötti különbséget tárolják.
Külön érdemes megvizsgálni a biztonsági másolatok készítésének folyamatát olyan tárolón, amely nem teszi lehetővé a másolatok duplikálását. Így ha teljes biztonsági másolatokat készítünk rajta, valójában csak a biztonsági másolatok közötti különbség kerül rögzítésre, azonban a biztonsági másolatok helyreállítási folyamata hasonlóan fog zajlani, mint a teljes másolat helyreállítása, és teljesen átlátható lesz.
Quis custodiet ipsos custodes?
(Ki őrzi meg az őröket? — latin.)
Nagyon kellemetlen, amikor nincsenek biztonsági másolatok, de még rosszabb, ha a biztonsági másolat valahogy elkészült, de a helyreállítás során kiderül, hogy nem állítható vissza, mert:
- Az eredeti adatok integritása sérült.
- A biztonsági másolatok tárolója sérült.
- A helyreállítás meglehetősen lassan működik, nem lehet használni azokat az adatokat, amelyek részben helyreálltak.
A megfelelően felépített biztonsági másolat készítési folyamatnak figyelembe kell vennie az ilyen megjegyzéseket, különösen az első kettőt.
Az eredeti adatok integritását többféle módon lehet garantálni. Leggyakrabban a következő módszereket alkalmazzák: a) fájlrendszer pillanatképeinek készítése blokkszinten, b) a fájlrendszer állapotának 'lefagyasztása', c) speciális blokk készülékek használata verziók tárolására, d) fájlok vagy blokkok sorrendben történő írása. Ellenőrző összegek is alkalmazhatók az adatok helyreállításának ellenőrzésére.
A tároló meghibásodásai is felfedezhetők ellenőrző összegek segítségével. Egy másik módszer a speciális eszközök, vagy olyan fájlrendszerek alkalmazása, ahol a már rögzített adatok nem módosíthatók, de új adatokat lehet hozzáfűzni.
A helyreállítás felgyorsítása érdekében a helyreállításhoz több folyamat alkalmazása szükséges — feltéve, hogy nincs 'szűk keresztmetszet' a lassú hálózat vagy a nem túl gyors lemezes rendszer miatt. A részben helyreállított adatokkal kapcsolatos helyzet megoldására a biztonsági mentés folyamatát viszonylag kicsi alfeladatokra lehet bontani, amelyeket külön-külön hajtanak végre. Így lehetőség nyílik a működőképesség fokozatos helyreállítására, az időtartam előrejelzésével. Ez a probléma leggyakrabban az üzleti szerződés (SLA) szintjén merül fel, ezért nem fogunk részletesebben foglalkozni vele.
A fűszerekhez nem az ért, aki minden ételbe beletesz, hanem az, aki soha nem tesz bele semmi feleslegeset.
—V. Szinjavszkij
A rendszeradminisztrátorok által használt szoftverek gyakorlata eltérő lehet, de az alapelvek a változásokat figyelembe véve is azonosak, különösen:
- Határozottan ajánlott kész megoldásokat alkalmazni.
- A programoknak kiszámíthatónak kell lenniük, azaz nem lehetnek dokumentálatlan sajátosságok vagy szűk keresztmetszetek.
- Minden program beállításának annyira egyszerűnek kell lennie, hogy ne kelljen minden alkalommal elolvasni a használati útmutatót vagy egy segédanyagot.
- A megoldásnak univerzálisnak kell lennie, mivel a szerverek hardveres jellemzői jelentősen eltérhetnek egymástól.
A blokkokból származó biztonsági mentésekhez a következő, elterjedt programok állnak rendelkezésre:
- dd, amelyet a rendszergazdák jól ismernek, ide tartoznak a hasonló programok (például dd_rescue).
- Néhány fájlrendszerbe beépített karbantartó programok (segédprogramok), amelyek a fájlrendszer másolatát (dump) készítik.
- Általános segédprogramok, például a partclone.
- Saját, gyakran proprietary megoldások, például NortonGhost és a későbbi verziói.
A fájlrendszerek esetében a biztonsági mentés részben megoldható a blokkeszközökre alkalmazott módszerekkel, de a feladat hatékonyabban is megoldható, például:
- Rsync, egy univerzális program és protokoll a fájlrendszerek állapotának szinkronizálására.
- Beépített archíváló eszközök (ZFS).
- Harmadik féltől származó archíváló eszközök; a legnépszerűbb képviselőjük a tar. Vannak mások is, például dar — a tar modern rendszerekre irányuló alternatívája.
Külön említést érdemelnek azok a szoftveres eszközök, amelyek biztosítják az adatok konzisztenciáját a biztonsági mentések készítésekor. Leggyakrabban a következő megoldásokat alkalmazzák:
- A fájlrendszer írásvédett (ReadOnly) módba történő csatolása, vagy a fájlrendszer fagyasztása (freeze) — ez a módszer korlátozottan alkalmazható.
- A fájlrendszerek vagy blokkeszközök állapotának másolatainak készítése (LVM, ZFS).
- Harmadik féltől származó eszközök alkalmazása másolatok létrehozására, még akkor is, ha az előző pontok bármilyen okból nem biztosíthatók (hotcopy típusú programok).
- A módosítások során történő másolás technikája (CopyOnWrite), de ez leggyakrabban a használt fájlrendszerhez kötődik (BTRFS, ZFS).
Így egy kiszolgáló esetében olyan biztonsági mentési rendszert kell biztosítani, amely megfelel a következő követelményeknek:
- Könnyen használható — nem igényel különleges lépéseket a használat során, minimális tevékenység szükséges a másolatok létrehozásához és visszaállításához.
- Univerzális — működik nagy és kis szervereken is; ez fontos a szám növekedésekor szerverek vagy a skálázáskor.
- Csomagkezelővel telepíthető, vagy egy-két parancs, például „letöltés és kicsomagolás” segítségével.
- Stabil, standard vagy már régóta bevált tárolási formát használ.
- Gyors működés.
A következő követelményeknek megfelelő jelöltek:
- rdiff-backup
- rsnapshot
- burp
- duplicati
- duplicity
- deja dup
- dar
- zbackup
- restic
- borgbackup
A tesztkörnyezet egy virtuális gép (XenServer alapú) lesz, a következő jellemzőkkel:
- 4 mag 2.5 GHz-en,
- 16 GB RAM,
- 50 GB hibrid tárolás (SSD cache a virtuális lemez méretének 20%-ával) egy külön virtuális lemezként, partíciózás nélkül,
- 200 Mbit/s internetkapcsolat.
A biztonsági mentések fogadó szerver szinte ugyanolyan gép lesz, de 500 GB-os merevlemezzel.
Operációs rendszer – Centos 7 x64: alapvető particionálás, egy további partíció adathordozóként funkcionál.
Forrásadatként egy 40 GB-os médiatartalommal rendelkező WordPress weboldalt választunk, valamint MySQL adatbázist. Mivel virtuális szervereket a jellemzők nagyon különböznek, és a reprodukálhatóság érdekében itt vannak
a sysbench-szel végzett szerver tesztelésének eredményei.sysbench —threads=4 —time=30 —cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (bundled LuaJIT 2.1.0-beta3 használatával)
A teszt futtatása a következő beállításokkal:
Szálak száma: 4
A véletlenszám-generátor inicializálása a jelenlegi időből
Prímszám határ: 20000
Munkaszálak inicializálása…
Szálak elindítva!
CPU sebesség:
másodpercenkénti események: 836.69
Átviteli sebesség:
események/s (eps): 836.6908
eltelt idő: 30.0039s
összes esemény száma: 25104
Késleltetés (ms):
min: 2.38
átlag: 4.78
max: 22.39
95-ös percentilis: 10.46
összeg: 119923.64
Szálak méltányossága:
események (átlag/szórás): 6276.0000/13.91
futási idő (átlag/szórás): 29.9809/0.01
sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=read memory run
sysbench 1.1.0-18a9f86 (bundled LuaJIT 2.1.0-beta3 használatával)
A teszt futtatása a következő beállításokkal:
Szálak száma: 4
A véletlenszám-generátor inicializálása a jelenlegi időből
Memória sebességteszt futtatása a következő beállításokkal:
blokkméret: 1KiB
összes méret: 102400MiB
művelet: olvasás
hatókör: globális
Munkaszálak inicializálása…
Szálak elindítva!
Összes műveletek: 50900446 (1696677.10 másodpercenként)
49707.47 MiB átvitt (1656.91 MiB/s)
Átviteli sebesség:
események/s (eps): 1696677.1017
eltelt idő: 30.0001s
összes esemény száma: 50900446
Késleltetés (ms):
min: 0.00
átlag: 0.00
max: 24.01
95-ös percentilis: 0.00
összeg: 39106.74
Szálak méltányossága:
események (átlag/szórás): 12725111.5000/137775.15
futási idő (átlag/szórás): 9.7767/0.10
sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=write memory run
sysbench 1.1.0-18a9f86 (bundled LuaJIT 2.1.0-beta3 használatával)
A teszt futtatása a következő beállításokkal:
Szálak száma: 4
A véletlenszám-generátor inicializálása a jelenlegi időből
Memória sebességteszt futtatása a következő beállításokkal:
blokkméret: 1KiB
összes méret: 102400MiB
művelet: írás
hatókör: globális
Munkaszálak inicializálása…
Szálak elindítva!
Összes műveletek: 35910413 (1197008.62 másodpercenként)
35068.76 MiB átvitt (1168.95 MiB/s)
Átviteli sebesség:
események/s (eps): 1197008.6179
eltelt idő: 30.0001s
összes esemény száma: 35910413
Késleltetés (ms):
min: 0.00
átlag: 0.00
max: 16.90
95-ös percentilis: 0.00
összeg: 43604.83
Szálak méltányossága:
események (átlag/szórás): 8977603.2500/233905.84
futási idő (átlag/szórás): 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 (bundled LuaJIT 2.1.0-beta3 használatával)
A teszt futtatása a következő beállításokkal:
Szálak száma: 4
A véletlenszám-generátor inicializálása a jelenlegi időből
További fájlnyitási zászlók: (nincs)
128 fájl, mind 8MiB
1GiB összes fájlméret
Blokkméret 4KiB
IO kérések száma: 0
Olvasási/Írási arány a kombinált véletlenszerű IO tesztnél: 1.50
Időszakos FSYNC engedélyezve, fsync() hívása minden 100 kérésnél.
fsync() hívása a teszt végeztével, engedélyezve.
Szinchronikus I/O mód használata
Véletlenszerű olvasási/írási teszt végzése
Munkaszálak inicializálása…
Szálak elindítva!
Átviteli sebesség:
olvasás: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
írja: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Késleltetés (ms):
min: 0.00
átlag: 0.27
max: 18.01
95. percentilis: 1.08
összeg: 238469.45
Ez a megjegyzés egy nagy
cikkciklus eleje a biztonsági mentésről
- Biztonsági mentés, 1. rész: Miért van szükség biztonsági mentésre, a módszerek és technológiák áttekintése
- 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
Forrás: habr.com
