Upload
piper
View
64
Download
0
Embed Size (px)
DESCRIPTION
Intelligens rendszerfelügyelet. Mentés, archiválás. Tóth Dániel, Szatmári Zoltán. …. 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?. - PowerPoint PPT Presentation
Citation preview
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