1 Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Mentés, archiválás Tóth Dániel, Szatmári Zoltán Intelligens.

Az előadások a következő témára: "1 Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Mentés, archiválás Tóth Dániel, Szatmári Zoltán Intelligens."— Előadás másolata:

1 1 Budapesti Műszaki és Gazdaságtudományi Egyetem Mé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 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? A fájlok megvannak, de ez nem elég, nem indul el. 

3 3 Az előző részek tartalmából  Szolgáltatásbiztonság az IT rendszerekben o Alap technikák o Analízis eszközök (FMEA, hibafa…)  Fürtök o … o Replikációs módszerek

4 4 Tartalom  Hibatűrés az adattárolásban o Alap technikák o Mi mire való  Mentés (Backup)  Archiválás  Adatmegsemmisítés

5 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 o Maguktól is elromolhatnak… o Elemi kár is elpusztíthatja  És persze exponenciálisan nő a tárolandó adatmennyiség…

6 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 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éllal o 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 8 Hibatűrés az adattárolásban TechnikaEz ellen védAz ellen nem védGarancia RAID (1-6)Adathordozó meghibásodás Minden 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ésMindenféle hardverhiba, akár elemi kár, emberi hiba is Nagy emberi hibaNincs 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 „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 9 Gyors áttekintés  Adattár hibatűrési technikák áttekintése: RAID Folyamatos Repliká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 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 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ések o 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 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 o Mit tehetünk a hátrányok ellen? Verziókezelés, csak a különbségek tárolása Adat deduplikáció.

13 13 Biztonsági mentések historikus megőrzése  Nem biztos, hogy az utolsó mentés helyes, vagy tartalmazza az elveszett adatot o Célszerű több mentést tárolni visszamenőleg  Újra fontos kérdések merülnek fel: o Milyen gyakran mentsünk? o Mennyi 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” A mentés paraméterei tudatos rendszertervezés során alakulnak ki és a mentendő rendszerre jellemzőek! „Backup policy”

14 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 bitet o Copy – minden fájlt ment, nem törli az archive-ot o Differential – csak az archive bittel jelölt fájlokat menti, nem törli az archive bitet róluk o Incremental – csak az archive bittel jelölt fájlokat, törli az archive bitet

15 15 Különbségi mentés  Helyreállítási alapesetek: Legutóbbi normal Normal Legutóbbi copy Copy Legutóbbi normal + legutóbbi differential Differential Legutóbbi normal + azóta összes incremental Incremental N N C C N N N N

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

17 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én o 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én o Blokkok, vagy nagyobb allokációs egységek szintjén hash összeg alapján o Újabb SAN eszközökben már hardveres támogatással o 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 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én o 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én o Blokkok, vagy nagyobb allokációs egységek szintjén hash összeg alapján o Újabb SAN eszközökben már hardveres támogatással o 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 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 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 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ájlon o 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 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 ágens Olvasá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. 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 23 Megoldás  Pillanatkép (Snapshot) funkció o Logikai kötetkezelők támogatják o Néhány fájlrendszer is (pl. ZFS)  A snapshot készítés atomi művelet o 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és Nem készül biztonsági másolat! A snapshot egy támogató technológia konzisztens, atomi másolat létrehozásához. Snapshot != mentés Nem készül biztonsági másolat! A snapshot egy támogató technológia konzisztens, atomi másolat létrehozásához.

24 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 o mysqldump  …

25 25 DEMO #!/bin/bash for db in `mysql -h host -u user -p pass -e 'show databases' `; do mysqldump -h host -u user –p pass --add-drop-database --add-drop-table --create-options $db | gzip > $db.sql.gz done Adatbázis mentés bash környezetben

26 26 Ki kezdeményez?  Push típusú mentés o A mentendő rendszer kezdeményezi a biztonsági mentést o Mindenhova „intelligenciát” kell telepíteni  Pull típusú mentés o Központi rendszer kezdeményez o Hozzáférést kell biztosítani a mentendő rendszer fájlaihoz  Vegyes megoldás

27 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 ideje o Visszaállítás időigénye (Nem kritikus, ha ritkán van rá szükség) o Visszaállítható időtáv o Visszaállítható verziók száma o Elfoglalt tárhely aránya az adatmennyiséghez képest

28 28 Esettanulmány  Komplex, vegyes komponensekből felépülő rendszer mentésének megtervezése o Windows és Linux csomópontok vegyesen o Speciális szolgáltatások

29 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.

30 30 Virtualizáció  Megint megment minket a bajtól  Virtuális gépről készített teljes backuppal elkerülhető minden korábbi nehézség o Snapshot a virtuális gépről: atomi pillanatkép a teljes lemezről + memóriatartalomról, CPU állapotról stb. o A teljes snapshotolt virtuális gép kényelmesen lemásolható (akár lassan, aszinkron módon…) o Helyreállításnál a gép onnan fut tovább, ahol a backup készült -> megúsztuk az alkalmazás specifikus visszatöltést is Rosszul megírt alkalmazás is visszatölthető vele

31 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 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 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ő. 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 Bacula director vezérlő szerver Ütemezett feladatvégrehajtás Adatbázis szerver (mySQL, postgreSQL, SQLite) Katalógus tárolás Adatbázis szerver (mySQL, postgreSQL, SQLite) Katalógus tárolás Bacula storage daemon A tényleges adatmentő eszközt kezeli Bacula storage daemon A tényleges adatmentő eszközt kezeli

34 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 szemetet o 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ét o 0-kkal? o Elég egyszer?

35 35 Összefoglalás  Hibatűrés az adattárolásban o Alap technikák o Mi mire való  Mentés o Konzisztencia biztosítása o Deduplikáció o Katalogizálás  Archiválás  Adatmegsemmisítés