1Budapesti Műszaki és Gazdaságtudományi EgyetemMéréstechnika és Információs Rendszerek Tanszék

Mentés, archiválás

Tóth Dániel, Szatmári Zoltán

Intelligens rendszerfelügyelet

2

…

Bugsy-nak annyi!Pedig csak ő tudta

Az Üzlet részleteit…

Úgy tűnik a sírba vitte magával a

tudását ;( Sob.

Nem tudjuk visszatölteni biztonsági

mentésről?

Bugsy,the database server

RIP2005-2010

A fájlok megvannak, de ez

nem elég, nem indul el.

3

Az előző részek tartalmából Szolgáltatásbiztonság az IT rendszerekben

o Alap technikáko Analízis eszközök (FMEA, hibafa…)

Fürtöko…o Replikációs módszerek

4

Tartalom Hibatűrés az adattárolásban

o Alap technikákoMi mire való

Mentés (Backup)

Archiválás

Adatmegsemmisítés

5

Hibatűrés az adattárolásban Az adat többet ér, mint az adathordozó

o Az adathordozó pótolható, az adat többnyire nem Az adathordozók nem örökéletűek

oMaguktól is elromolhatnak…o Elemi kár is elpusztíthatja

És persze exponenciálisan nőa tárolandó adatmennyiség…

HDD====

6

RAID Már láttuk mérésen… Kérdés:

o Van-e értelme RAID-nek desktop gépeken? Válasz:

o Attól függ El kell dönteni, hogy mit akarunk

o Nagy teljesítmény? • RAID-0

o Hibatűrés? • RAID-(1-6)

o Biztosan?o Mennyi ideig állhat egy desktop gép?o Mik a jellegzetes hibamódok?o Mennyi az előfordulási valószínűségük? (hasból)o Ebből mennyi ellen véd a RAID?o Még mindig RAID kell nekünk?

7

RAID Kérdés:

o Van-e értelme RAID-nek szerver gépeken? Válasz:

o Attól függ , de azért többnyire egyértelmű igen Miért?

o Elsősorban hibatűrési céllalo De itt is el kell gondolkodni a kérdéseken: Mennyi ideig állhat a szerver

gép?o Szerencsére minden IRF hallgató tudja, hogy ez egy rosszul feltett

kérdés! Helyesen: mennyi ideig eshet ki a szolgáltatás?o Mik a jellegzetes hibamódok?o Mennyi az előfordulási valószínűségük? (hasból)o Ebből mennyi ellen véd a RAID?o Kell a RAID mellé más is nekünk?

8

Hibatűrés az adattárolásbanTechnika Ez ellen véd Az ellen nem véd GaranciaRAID (1-6) Adathordozó

meghibásodásMinden más (tápegység, elemi kár, vezérlő hiba, OS hiba, emberi hiba, alkalmazás hiba)

Folyamatos üzem meghibásodás esetén is

Replikáció (pl. DRBD)

Hardver többféle hibája, hálózati hiba

Emberi hiba, OS hiba, alkalmazás hiba

Típusfüggő, akár folyamatos üzem

Mentés Mindenféle hardverhiba, akár elemi kár, emberi hiba is

Nagy emberi hiba Nincs folyamatos üzemelés, visszaállítás kell!

Archiválás ? ? ?

„Csalás!” Az archiválás NEM hibatűrési mechanizmus,

nem összekeverendő a backuppal!Az archiválás célja a már használaton kívüli, de

megőrzendő adatok biztonságos tárolása

9

Gyors áttekintés Adattár hibatűrési technikák áttekintése:

RAID FolyamatosReplikáció

Periodikus Replikáció Mentés

• Kis kiesés,• Nincs adatvesztés• Sok közös modusú hibalehetőség

• Nagy kiesés,• Legutóbbi adatmódosítás elveszhet• Kevés közös modusú hibalehetőség

Léteznek olyan Backup eszközök, amik a hagyományos periodikus backupot kombinálják

folyamatos fájl szintű replikációval. Pl. Tivoli Continous Data Protection

10

Replikáció, DRBD Replikáció (folyamatos vagy periodikus)

o Átmeneti megoldások a RAID és a backup között DRBD (Distributed Redundant Block Device)

Heartbeat

SAN (pl. iSCSI)

Írt adatok replikációja

SAN (pl. iSCSI)

Failover

Újraszinkronizálás

11

Biztonsági másolat készítése Mentés

o Rendszeresen másolatot készítünk az adatokról, lehetőleg olyan médiumra, amit kevés az elsődleges rendszerével közös modusú hiba érint

o A másolatokból visszamenőleg több eltérő időben készült példányt is őrizhetünk (ez véd akár emberi hibák ellen is!)

Jellegzetes kérdéseko Mire készítsük a mentést?o Milyen rendszeresen?o Miről készítsük a mentést?o Milyen módon? (kézzel, automatizáltan?)o Mennyi ideig őrizzük meg?

12

Biztonsági másolat készítése Milyen rendszeresen…

o Ha sűrűn mentünk• Nagy terhelés a rendszernek• Sok mentett adat keletkezik

o Ha ritkán mentünk• A mentések között túl sok védelem nélküli adat gyűlik össze

oMit tehetünk a hátrányok ellen?• Verziókezelés, csak a különbségek tárolása• Adat deduplikáció.

13

Biztonsági mentések historikus megőrzése Nem biztos, hogy az utolsó mentés helyes, vagy

tartalmazza az elveszett adatoto Célszerű több mentést tárolni visszamenőleg

Újra fontos kérdések merülnek fel:oMilyen gyakran mentsünk?oMennyi idő múlva dobhatunk el egy mentést?o Kell-e egy évre visszamenőlegesen óránkénti mentést

tárolni?A mentés paraméterei tudatos rendszertervezés során alakulnak ki és a mentendő rendszerre jellemzőek!

„Backup policy”

14

Különbségi mentés Példa: Windows Backup Service Kulcselem: „archive” attribútum bit a fájlokon

(igen, ez félrevezető elnevezés, újabb verziókban már „to be backed up” flag)

Backup típusok:o Normal – minden fájlt ment, törli az archive biteto Copy – minden fájlt ment, nem törli az archive-oto Differential – csak az archive bittel jelölt fájlokat menti,

nem törli az archive bitet róluko Incremental – csak az archive bittel jelölt fájlokat, törli

az archive bitet

15

Különbségi mentés Helyreállítási alapesetek:

• Legutóbbi normalNormal

• Legutóbbi copyCopy

• Legutóbbi normal• + legutóbbi differentialDifferential

• Legutóbbi normal• + azóta összes incrementalIncremental

N

C

N

N

16

DEMO

Különbségi mentés lehetőségek kiválasztása Volume Shadow copy service (mire jó?)

Windows Backup Service

17

Adat deduplikáció Többszörözött adatok eltávolítása

o Ez „rossz” fajta rendundancia, mert helyet foglal, de nem tudjuk hibatűrésre kihasználni

Fájlok szintjéno Azonos tartalmú fájlok keresése (hash összeg alapján)o Ismétlődő fájlok lecserélésre az első példányra hivatkozásra

Blokkos eszköz szintjéno Blokkok, vagy nagyobb allokációs egységek szintjén hash összeg

alapjáno Újabb SAN eszközökben már hardveres támogatássalo Néha kevésbé hatékony (fájlrendszer adatszerkezetek,

blokkhatárra illesztés, szemét adatok…)o Néha hatékonyabb (részleges tartalom egyezést is észrevehet)

18

Adat deduplikáció Többszörözött adatok eltávolítása

o Ez „rossz” fajta rendundancia, mert helyet foglal, de nem tudjuk hibatűrésre kihasználni

Fájlok szintjéno Azonos tartalmú fájlok keresése (hash összeg alapján)o Ismétlődő fájlok lecserélésre az első példányra hivatkozásra

Blokkos eszköz szintjéno Blokkok, vagy nagyobb allokációs egységek szintjén hash összeg

alapjáno Újabb SAN eszközökben már hardveres támogatássalo Néha kevésbé hatékony (fájlrendszer adatszerkezetek,

blokkhatárra illesztés, szemét adatok…)o Néha hatékonyabb (részleges tartalom egyezést is észrevehet)

A deduplikáció fogalmilag nem azonos az adat „tömörítéssel” (forráskódolással), bár elvileg tekinthető a tömörítés egy

formájának is. Általában kombinálható más tömörítési eljárással (pl. valamilyen Lempel-Ziv változattal) is.

19

DEMO

Egy elemi eszköz és erre épülő technológiák Deduplikáció fájlok szintjén

o Unix VFS hard link funkcióra épül (a változatlan fájlok csak hard linkek az eredeti példányra)

o A fájlrendszer megoldja a szemétszedést (akkor törlődik az adat, ha a hard link referencia számláló 0-ra fut)

Rsync / Dirvish, rSnapshot

20

Mit szeretnénk menteni? Teljes operációs rendszert

Partíciót / Fájlrendszert

Kizárólag fájlokat

Speciális szolgáltatások adatait, beállításait

21

Hogyan készítsünk mentést? Fájlrendszerről

o Egyszerű… NOT!o Lockolt fájlokkal gond lehet (főleg windows alatt)o Ráadásul az alkalmazásnak jó oka lehet rá, hogy lockot

tart a fájlono A fő kérdés: ha valamilyen átmeneti, módosítás

közbeni állapotot állítunk vissza, akkor az alkalmazás képes lesz-e abból helyreállni?

o -> Alkalmazás specifikus backup lehetőségek is kellenek

22

Hogyan készítsünk mentést? Blokkos eszközről

o Ugyanaz a probléma, mint a módosítás alatti fájloknál

Fájl vagy blokkos eszköz (= nagy byte tömb)

Alkalmazás

Backup ágensOlvasás

Másolat

Írás

!

A már átmásolt részen történő módosítás már nem kerül mentésre. Inkonzisztenssé

válik a másolt példány!Miért?

Mert (nagyon) nem atomi művelet a másolás.

23

Megoldás Pillanatkép (Snapshot) funkció

o Logikai kötetkezelők támogatjáko Néhány fájlrendszer is (pl. ZFS)

A snapshot készítés atomi műveleto Másolás csak menet közben történik (copy on write)

Fájl vagy blokkos eszköz (= nagy byte tömb)

Snapshot tárhely (csak a módosult blokkok eredetije van itt)

Írás

Olvasás

Snapshot != mentésNem készül biztonsági másolat! A

snapshot egy támogató technológia konzisztens, atomi másolat

létrehozásához.

24

Alkalmazás-specifikus mentés Példa1 MS-SQL szerver beépített backup funkciója

o BACKUP DATABASE yourdb TO DISK='C:\temp\yourdb.bak' WITH INIT

o RESTORE DATABASE yourdb FROM DISK='C:\temp\yourdb.bak'

Példa2 OpenLDAP o slapcat, ldif formátumban dumpolja a teljes adatbázis

tartalmat) Példa3 MySQL

omysqldump …

25

DEMO

#!/bin/bashfor db in `mysql -h host -u user -p pass -e 'show databases' `; domysqldump -h host -u user –p pass --add-drop-database --add-drop-table --create-options $db | gzip > $db.sql.gzdone

Adatbázis mentés bash környezetben

26

Ki kezdeményez? Push típusú mentés

o A mentendő rendszer kezdeményezi a biztonsági mentést

oMindenhova „intelligenciát” kell telepíteni Pull típusú mentés

o Központi rendszer kezdeményezo Hozzáférést kell biztosítani a mentendő rendszer

fájlaihoz Vegyes megoldás

27

Biztonsági mentés teljesítménye Mivel mérhető a biztonsági mentés teljesítménye?

o Egyszeri mentés lefutási idejeo Visszaállítás időigénye (Nem kritikus, ha ritkán van rá

szükség)o Visszaállítható időtávo Visszaállítható verziók számao Elfoglalt tárhely aránya az adatmennyiséghez képest

28

Esettanulmány Komplex, vegyes komponensekből felépülő

rendszer mentésének megtervezéseoWindows és Linux csomópontok vegyeseno Speciális szolgáltatások

29

Összefoglalás Feltételek konzisztens mentés készítéséhez egy

működő rendszerről:o A futó alkalmazás vagy fájlrendszer belül naplózó

adatszerkezetet használjon (ez erősen alapkövetelmény, nélküle egy egyszerű „kemény” leállítást sem élne túl!)

o Az adatról a másolat atomi műveletként készüljön, akár snapshot funkció segítségével.

31

Archiválás Még egyszer: nem mentési technológia

Nagy mennyiségű, ritkán szükséges adat „másik” helyen való tárolása

Mentéssel ellentétben itt egy példányban létezik az adat továbbra is

32

Adat katalogizálás Főleg az archiválás, kisebb részben a Backup

problémája Hova mentettünk mit?

o A NASA pl. az Apollo 11 eredeti rádióforgalmat rögzítő mágnesszalagjairól nem tudja, hogy hol vannak

Egyszerű megoldás: Fájlnév katalógus Bonyolultabb megoldások: metaadatok, tartalom

alapján keresés

33

Példa: Bacula backup

Célgép(az ő tartalmát mentjük)Bacula saját ágense itt

fut. Alkalmazás specifikus pluginekkel

kiegészíthető.

Bacula director vezérlő szerver

Ütemezett feladatvégrehajtás

Adatbázis szerver (mySQL, postgreSQL,

SQLite)Katalógus tárolás

Bacula storage daemon

A tényleges adatmentő eszközt

kezeli

34

Adatmegsemmisítés Egy kis disztroj Adatvédelmi előírások miatt szükséges lehet, hogy

egy adatból garantáltan ne maradjon fenn példány Fájlok törlésekor nem törlődik az adat ténylegesen

o Fájlrendszer elhagy szemeteto Biztonsági másolatok is megmaradnak

Tudni kell, hogy hol vannak backup/archív példányok belőle (katalógus)

Felül kell írni az fizikai eszközön a helyéto 0-kkal?o Elég egyszer?

35

Összefoglalás Hibatűrés az adattárolásban

o Alap technikákoMi mire való

Mentéso Konzisztencia biztosításao Deduplikációo Katalogizálás

Archiválás Adatmegsemmisítés