Adatmentési (backup) megoldások Linux alatt Szabad szoftver

Adatmentési (backup) megoldások

Linux alatt

Szabad szoftver keretrendszer

Készítette a Közigazgatási és Igazságügyi minisztériumE-közigazgatási Szabad Szoftver Kompetencia Köz-

pontja, Budapest, 2013

Kódszám: EKOP–1.2.15 – Ez a Mű a Creative Commons Nevezdmeg! Így add tovább! 3.0 Unported License feltételeinek megfele-

lően szabadon felhasználható.A dokumentum legfrissebb változata letölthető a honlapunkról:

http://szabadszoftver.kormany.hu/szabad-szoftver-keretrendszer/


EKOP-1.2.15-2011-2011-0001 „E-KÖZIGAZGATÁSI SZABAD SZOFTVER

KOMPETENCIA KÖZPONT LÉTREHOZÁSA”CÍMŰ KIEMELT PROJEKT

TartalomjegyzékA főbb mentési módszerek..............................................................3A legfontosabb teendők a mentés kialakításában............................5Szoftverek a mentés megvalósítására..............................................8

DD..............................................................................................8Tar, CP, CPIO.............................................................................9Partimage...................................................................................9Rsync........................................................................................11Rsnapshot.................................................................................14Amanda Backup.......................................................................19Bacula......................................................................................21Dirvish......................................................................................22

mysqldump.........................................................................31Mysqlhotcopy.....................................................................35Melyiket válasszam: a Dirvish pre szkript rendszerét, vagy az ütemezett mentést az SQL gépen?.................................37

Hogyan mentsünk, melyiket használjuk és mikor?.......................38Adatmegsemmisítés.................................................................40Pull vagy Push?........................................................................42

Kliensek mentése...........................................................................44

Az talán senki számára nem vitatható tény, hogyadatmentésnek, azaz biztonsági mentésnek mindenrendszer alatt lennie kell. Az is fontos, hogy a mentésautomatikusan, beavatkozásmentesen történjen, ugyan-akkor szintén fontos, hogy a mentések rendszeresen el-

2

Adatmentési (backup) megoldások Linux alatt

lenőrizve is legyenek, hiszen ha nyugodtan bízunk egymentést végző 5-6 éves héjprogramban (shell szkript),amit sosem ellenőriztünk le, akkor kellemetlen megle-petések érhetnek minket, amikor elő kell venni a régi,megbízhatónak gondolt mentést, és kiderül, hogy egyadatbázist vagy egy könyvtárat mégsem követtünk le. ALinux-alapú rendszerekre számos kiváló mentési keret-rendszer és héjprogram érhető el. Gyakorlatilag a leg-több a unixos alapokkal rendelkező cp, tar1, cpio2 prog-ramokat használja, amelyek minden Linux rendszerstandard tartozékai. Mások az rsync3-et és az SSH-tkombinálják, ezzel teszik lehetővé a biztonságos távolimenthetőséget is.

A főbb mentési módszerek

– Teljes mentés: ilyenkor a rendszer minden adatamentésre kerül, válogatás nélkül. Előnyre, hogy pél-dául egy lemezkép készíthető a szerver aktuális álla-

1 http://www.gnu.org/software/tar/2 http://www.gnu.org/software/cpio/3 http://en.wikipedia.org/wiki/Rsync

3

http://en.wikipedia.org/wiki/Rsync











http://www.gnu.org/software/cpio/












http://www.gnu.org/software/tar/













potáról, amely egyszerűen visszaállítható (gyakrancsak a rendszertöltőt (boot loader) vagy még azt semkell helyrerakni). Hátránya: sérülékeny és időigé-nyes.

– Inkrementális mentés: Használata során csak a válto-zások mentődnek, azaz leképezünk egy nullás men-tést és a megváltozott állapotokat mentjük. Ennek amentésnek 2 alfajtája van: a kumulatív és a differen-ciális mentés.

– Kumulatív mentés: alkalmazása esetén mindig azutolsó teljes mentés óta megváltozott adatok ke-rülnek mentésre. Adatváltozás esetén csak a vál-tozást menti, viszont azt minden esetben. Előnye,hogy jóval gyorsabb a teljes mentésnél, és keve-sebb a területigénye is.

– Differenciális mentés: ebben az esetben csak az utol-só inkrementális mentés óta megváltozott adato-kat mentjük. Előnye, hogy a leggyorsabb straté-gia. Hátránya, hogy az első mentés és az összeskövető mentés szükséges hozzá, azaz a leginkábbsérülékeny az adatstruktúrát illetően.

4

A főbb mentési módszerek

A mentési eljárások két irányból hajthatók végre. Aszerver végezhet adat „tolást” a mentő egység (szerver,NAS, szalag) felé, illetve a mentő egység/szerver iskezdeményezheti a mentési folyamatot, ilyenkor magafele húzza az adatokat. A két módszer között főként biz-tonsági különbség van. Ha a backup szerver húzzamaga felé az adatot, akkor azt a szervert kell úgy kiala-kítani, hogy biztonságos legyen. Ilyen esetben az élesszerverre való betörés esetén a backup szerver kevésbésérülékeny, mint fordítva.

A legfontosabb teendők a mentés

kialakításában

– Felmérés: összeírni a mentendő szoftverkörnyezetkialakítását. Eldönteni, hogy az adott mentő szoftveralkalmas-e valós időben menteni az adatbázisunk(szükséges-e ez egyáltalán), illetve pontosan mit ésmikor célszerű mentenünk. Például: érdemes-e min-den nap menteni a teljes fájlrendszert, mindenféleideiglenes állománnyal együtt, vagy elég csak aktua-

5


lizálni. Fontos gondolni a Disaster recovery-re4 (ka-tasztrófa-helyreállítás) is, amikor akár az egész gép-terem elpusztulhat. Ismert ilyen példa, amikor aWTC5 egyik épületében volt az éles alkalmazás szer-ver és a 2. toronyban pedig a backup. Természetesenez nem minden nap előforduló lehetőség, de számí-tásba kell venni a felmérés folyamatában. Fel kelltenni magunknak a kérdést, hogy az adataim hiánya,mekkora kárt okoz, illetve mekkora összegbe kerülegy RAID tömb visszaállítása az erre szakosodottszervizben.

– Tervezés: a felmérésre alapozva vázlatosan leírjuk atámasztott igényeinket. Betervezzük, milyen gyak-ran, milyen idősávban lesz lehetőség futtatni a men-tést. Szétválasztjuk a távoli, a szalagos és a helyimentéseket. Ütemezzük azokat, hogy ne fussanakegymásra. A mentési házirend figyelembe vétele, hamár van ilyen, ha nincs akkor írjunk.

4 http://en.wikipedia.org/wiki/Disaster_recovery5 http://hu.wikipedia.org/wiki/Vil%C3%A1gkereskedelmi_K

%C3%B6zpont

6

http://hu.wikipedia.org/wiki/Vil%C3%A1gkereskedelmi_K%C3%B6zpont

























http://en.wikipedia.org/wiki/Disaster_recovery













A legfontosabb teendők a mentés kialakításában

– Kiválasztás: Az 1-2 pontok alapján kiválasztjuk amegfelelő szoftvert, amely a leírása alapján alkalmaslesz a munkára.

– Megvalósítás: A kiválasztott szoftverek segítségévelfelépítjük a mentési rendszert.

– Tesztfuttatás: Leteszteljük a már elkészült mentést.Megnézzük a lehetséges eseteket és azok befolyásáta mentésünkre. Elég szalag áll-e rendelkezésre, mű-ködik-e az értesítési rendszer, amely tudatja velünk,ha elfogyott a szalag, vagy nincs elég tárterület. Egyhíres mentési baki, amikor az egyik ismert bankikártyarendszer teljes hálózata azért állt meg kará-csony előtt, mivel az automata leejtette a cserélendőszalagot és a mentés nagyobb prioritást élvezett,mint maga az éles üzem. Gyakran hiába állítjuk ösz-sze a legjobb mentő eszközt, és állítjuk be jól, haegy hibásan beállított e-mail cím, vagy egy blokkoltSMTP szolgáltatás lehetetlenné teszi, hogy az értesí-tés eljusson hozzánk, akkor hiába volt minden. Fi-gyeljünk arra, hogy a mentés lehetőleg olyankor fus-son amikor szükséges, de a mentés ne zavarja az élesüzemeltetést.

7


– Ellenőrzés: A mentés elkészültével fontos, hogy egypróba rendszeren végezzünk egy teljes visszaállítást,és nézzük meg, 100%-ban visszaállítható-e mindencsak a backupra támaszkodva.

– Ellenőrzés ütemezése: legyen a havi/negyedéves/fél-éves/éves rutin része, hogy teljes rendszer-visszaállí-tást végzünk, csakúgy mint ahogy akár na-ponta-hetente megnézzük, hogy a mentés rendbenment-e. Érdemes a mentés által készített összegzőnaplót monitorozni.

Szoftverek a mentés megvalósítására

DD6

Az egyik legrégebbi Unix eszköz például a teljes le-mezduplikációra. Felhasználási területe szélesebb amentéseknél, azonban egy egyszerű klónozás esetébenmegoldást jelenthet, fenntartásokkal.

6 http://en.wikipedia.org/wiki/Dd_(Unix)

8

http://en.wikipedia.org/wiki/Dd_(Unix)















Tar, CP, CPIO

Az operációs rendszerek alapvető kelléktára. Héj-programok segítségével használható mentésre, akár ka-zettás egység vezérlésére is. Önmagukban nagyon hasz-nosak, de egy modern rendszerben a rájuk épülő prog-ramokat használjuk inkább.

Partimage7

Egy konzol alapú lemezklónozó eszköz. A dd-heznagyon hasonló, azonban képességei alapján nemmondható egy sima dd-nek. Kezelése egyszerű, egypárbeszédablakos felületen lehet kiválasztani a menten-dő területet és azt, hogy hova mentsen. Tud titkosítaniés darabolni is, valamint hálózati mentést csinálni. Hát-ránya, hogy csak offline rendszert lehet vele menteni,célszerűen egy live CD-vel. Szerver lemezének költöz-tetése esetén, vagy hardvercsere esetében jó megoldáslehet, illetve munkaállomások klónozásra is. Rendelke-zik állapotfigyelővel, és számos lehetőséget nyújt a tö-mörítésre, darabolásra is. Ugyanakkor alap szintű lemez

7 http://www.partimage.org/Main_Page

9

http://www.partimage.org/Main_Page












duplázásra remek megoldás, azaz ha elkészítettünk egyszervert (például egy tűzfalat, amelyen jó esély van rá,hogy hosszú távon főként az iptables konfigurációs ál-lományának a változását kell lekövetni, vagy példáulegy telefonközpont – Asterisk) és mindenképpen szük-séges egy hideg backup belőle, akkor egy tökéletes esz-köz a partimage. Akár egy Ubuntu Live pendrive vagyCD-vel beindítjuk a gépet, úgy hogy a másolandó (for-rás) és a cél merevlemez is benne van a gépben, majd aPartimage párbeszédablakában kiválasztjuk, mit szeret-nénk csinálni, és készen is vagyunk. Futó (éles rend-szert) értelemszerűen így nem tudunk menteni, de akárarra is használható, ha kliens parkot kell létrehoznunk,azaz adott 200 db ugyanolyan PC, és mindegyikre felkell telepíteni ugyanazt a terjesztést. Telepítése rendkí-vül egyszerű: apt-get install partimage

10


Rsync8

Az rsync ideális eszköz gépen belüli szinkronizáció-ra, természetesen lehetőség van távoli elérésre is, akárssh-n, akár rsyncd-n keresztül. A legtöbb backup meg-oldás alapeszközként használja, mások kiegészítőként,illetve pár megoldás kifejezetten az rsyncre alapozva

8 http://rsync.samba.org/

11

http://rsync.samba.org/









igazából csak egy kezelőfelület. Paraméterezhetőségenagyon széles körű, talán pont ezért készült annyi esz-köz, amely leegyszerűsíti a vezérlését (például: grsync).Előnye a többi hozzá képest sokkal egyszerűbb (cp, tarstb.) programmal szemben, hogy a számtalan lehetőségmiatt rugalmasan kezeli például, ha a forrás nagyobbmint a cél lemez területe, akkor nem írja tele a célt stb.Általában héjprogram formájában vagy beépített esz-közként használjuk. Az rsync segítségével nem csakgyorsabban tudunk menteni, hanem a speciális delta kó-dolásnak köszönhetően csak a változásokat fogja átvin-ni egyik helyről a másikra. Ennek különösen szűk háló-zati keresztmetszetek között van nagy jelentősége, vagypedig például, ha egy 1 GB-os lemezképben csak 2 MBtartalom változik meg, akkor az rsync delta technológiasegítségével nem a teljes 1 GB-ot fogja lementeni, ha-nem egy összehasonlító vizsgálat után csak a változást– azaz jelen esetben a 2 MB-ot – fogja aktualizálni. Alegtöbb terjesztés tartalmazza alap szerver kiépítésben,de telepíthetjük azapt-get install rsync

parancs kiadásával. A legtipikusabban használt paramé-terezése a következő:

12


rsync -av /forrás/ /cél/

ahol a -a az archív készítése, a -v pedig a részletes né-zet. Ezt aztán kiegészíthetjük számtalan hasznos para-méterrel is, pl:rsync -r -t -p -o -g -v --progress --delete

-l -H /cél/ /forrás/

Az Rsync lokális használta esetén előfordulhat, hogypéldául egy igen gyors SSD lemezről másolunk egyUSB1 vagy USB2 szabványon csatlakozó akár Flashmemóriára, vagy merevlemezre. Ez persze főként ott-honi használatban fordulhat elő, de szerveren belül ismegeshet, hogy a különböző lemez alrendszerek más-más sebességgel működnek. Ilyen esetben és főként atömegesen előforduló kis állományok szinkronizálásaesetén előfordulhat, hogy feltorlódnak az I/O műveltek,és ezért emelkedni kezd a rendszerterhelés (load), fogy-ni kezd a memória, szélsőséges esetben már tárcserét(swap) kezd a rendszer. Ez pedig biztos út az összeom-lás felé. Az ilyen összeomlások elkerülésére két eszközhasználata javasolható, az egyik egy monitorozó esz-köz, amely a top programhoz hasonlóan képes megjele-níteni és rendezni azokat a futó folyamatokat, amelyek

13


az I/O terhelést okozzák. A program neve iotop,9 telepí-tése és használata is igen egyszerű: apt-get install iotop

és akár csak a top program esetén, csak indítsuk el. Amásik segédeszköz, amely hasznos lehet egy esetlege-sen rsync mentés kivitelezéséhez, az ionice10. Telepíté-se:apt-get install ionice

Az ionice és iotop programok részletes ismertetésé-vel a tuningolás fejezet foglalkozik.

Rsnapshot11

Szintén rsync és SSH alapokon nyugvó mentési esz-köz. Jóval fejlettebb lehetőségeket tartogat, mint az ed-digi eszközök. Alkalmas teljes fájlrendszer mentéséremegszorításokkal (boot loadert nem tud menteni, illetvefutási időben például adatbázist sem). Egyszerű para-méterezhetőség és könnyen átlátható konfiguráció jel-

9 http://guichaz.free.fr/iotop/10 http://manpages.ubuntu.com/manpages/precise/man1/ionice.1.h

tml11 http://www.rsnapshot.org/

14

http://www.rsnapshot.org/








http://manpages.ubuntu.com/manpages/precise/man1/ionice.1.html


















http://guichaz.free.fr/iotop/











lemzi. Rugalmas eszköz, mivel képes lokális mentéstvégezni (alapesetben a differenciális mentésttámogatja), az indulása cronból ütemezhető, vagyszkriptelhető. Létrehoz egy zároló állományt, amely jel-zi az esetlegesen ráfutó következő rsnapshotnak, hogymég az előző mentés fut, ezzel elkerülve az esetlegesfeltorlódást és ütközést. Együtt tud működni az SSH-val is, így lehetőség van arra, hogy egy távoli backupszerver (amelynek csak ez a feladata és kellően biztosí-tott) kezdeményezze a mentést SSH-val. De természe-tesen megoldható valamilyen hálózati fájlrendszerenkeresztüli mentés, illetve külső illesztésű merevlemezreis. Nagyon hasznos funkciója, hogy a konfigurációs ál-lomány az Apache-hoz hasonló szintaxis-ellenőrzésselrendelkezik, vagyis az rsnapshot configtest parancs se-gítségével tesztelhetjük az esetlegesen a szintaxissal üt-köző parancsokat, elütéseket. Így nem az éles mentéslefutása közben fog kiderülni a probléma. Külön napló-állományt készít, amelyben jól követhető a tevékenysé-ge. A mentést elkülönítetten egy erre meghatározott te-rületen kezeli, ahol a megadott intervallumtól függőenkészíti el a könyvtárstruktúrát. Az első alap mentés el-készítése jóval lassabb, a további inkrementális menté-

15


sek már gyorsabbak, melyeket linkek segítségével kötössze. Az aktuális állapotok pedig hourly, daily, weekly,monthly címkével kerülnek tárolásra. Természetesenegy konfigurációs állományban felsorolhatjuk az órán-kénti, napi, heti, havi mentések struktúráját is. Kivétel-kezelése könnyen paraméterezhető (az rsync használa-tának köszönhetően). Külön csak erre a feladatra fenn-tartott mentő szerver esetén (megfelelően védett backupszerver) jól automatizálható a mentés teljes folyamataaz SSH kulcs alapú megoldásával. Ebben az esetben abackup szerver kezdeményezi a kapcsolatot SSH-n ke-resztül. Annak érdekében, hogy mindent le tudjon men-teni, root hozzáférés szükséges (a legtöbb esetben),amely távoli elérésre normál esetben nem lenne bizton-ságos. Ezért az SSH szerver következő konfiguráció-változtatása javasolt: használjuk aPermitRootLogin=forced-commands-only

opciót a root távoli hozzáféréséhez. Majd készítsük el aroot SSH-kulcspárját jelszó nélkül, hogy a héjprogramne kérjen majd jelszót. Válasszuk megfelelően nagy(4096 bájt vagy e feletti) kulcs készítését. Az éles men-tendő szerveren a /root/.ssh/authorized_keys állomány-

16


ba másoljuk be a publikus kulcsot a következő kiegé-szítéssel: from="172.20.1.10",command="/etc/validate-

rsync"

ezt közvetlenül a legelső karakter helyére illesszük be,utána kezdődjön a kulcs. Az IP-cím helyén a backupszerver IP-címe legyen. Az /etc/validate-rsync héjprog-ramba pedig rakjuk be azokat a korlátozásokat, ame-lyek segítségével minimalizálni tudjuk a root SSHhasználatát. Pontos lista is elérhető az egész mentésimódszer részletes leírásával együtt.12 Mint látható, azrsnapshot egy komplex héjprogram-keretrendszer,amely egyszerűvé teszi a strukturált mentést. Azonbanteljes visszaállítás csak az alap operációs rendszer újra-telepítése után lehetséges egy esetleges teljes adatvesz-tés után. Ideális eszköz tehát nem HA rendszerek men-téséhez. Valamint gondoskodni kell az adatbázis különmentéséről, hiszen futási időben erre az rsnapshot kon-zisztensen nem képes.

Esetünkben az /etc/validate-rsync állomány tartalmaa következő volt:

12 http://troy.jdmz.net/rsync/#ref2

17

http://troy.jdmz.net/rsync/#ref2













#!/bin/sh case "$SSH_ORIGINAL_COMMAND" in *\&*) echo "Rejected" ;; *\(*) echo "Rejected" ;; *\{*) echo "Rejected" ;; *\;*) echo "Rejected" ;; *\<*) echo "Rejected" ;; *\`*) echo "Rejected" ;; *\|*) echo "Rejected" ;; rsync\ --server*) $SSH_ORIGINAL_COMMAND ;; *) echo "Rejected"

18


;; esac

Amanda Backup13

Kliens-szerver felépítésű mentőeszköz, képes Win-dows rendszereket is menteni. Windows esetén a Cyg-win csomag, vagy Samba megosztás vagy pedig sajátkliens segítségével végezhető el a mentés. Teljesenszerver alapú működés, előre definiálható adattárolók,amelyek lehetnek lemezről lemezre, lemezről kazettára,illetve lemezről felhő alapú tárterületre való mentésekis. Eredetileg kezdetben kazettás mentések kialakításáratervezték, ezért amikor merevlemez alapú mentést defi-niálunk, akkor virtuális szalagokkal operálva a merev-lemezen hoz létre alkönyvtárakat. A virtuális szalagokdefiniált méretét és darabszámát nem lépi át így sem.Igazi előnye, hogy nem kell statikus tervet készíteni,meg kell neki adni, hogy hány darab teljes mentést illet-ve mennyi inkrementálist fogunk készíteni. Rögzítjük afelhasználható szalagok számát. Az Amanda mentéselején kiszámolja, hogy a mentendő könyvtárak vagy

13 http://www.amanda.org/

19

http://www.amanda.org/









inkrementális mentéseihez aktuálisan mennyi helyrevan szükség és önállóan eldönti, hogy az adott mentés-be milyen könyvtár milyen szinten kerüljön bele. Harendelkezésre áll hely, akkor előre hozza a teljes menté-seket, ha pedig kifut a helyből, akkor késlelteti és anaplóba figyelmeztetéseket ír. Az Amanda telepítésénekfontos része az openbsd-inetd csomag is. Mivel titkosí-tást alapesetben nem használ a távoli gépre való mentésesetén, ezért érdemes VPN-t vagy a külön konfigurál-ható amcrypt-et14 használni a nyílt hálózatokon. Belsőgépek mentésére titkosítás nélkül is jól használható.Mivel az Amanda több TCP és UDP portot használ ésnyit, ezért érdemes a tűzfalunkat felkészíteni a fogadá-sára mind a két gépen, amennyiben a kialakításunk eztszükségessé teszi.15

14 http://wiki.zmanda.com/index.php/How_To:Set_up_data_encryption

15 http://wiki.zmanda.com/index.php/How_To:Set_Up_iptables_for_Amanda

20

http://wiki.zmanda.com/index.php/How_To:Set_Up_iptables_for_Amanda


























http://wiki.zmanda.com/index.php/How_To:Set_up_data_encryption

























Bacula16

Szintén keresztplatformos biztonsági mentést lehetmegvalósítani vele. Létezik hozzá Linux, Windows ésOS X alá kliens program, amelyeknek konzol alapú,GTK+ felületű és wxWidgets grafikus variánsai létez-nek. Legfőbb erőssége, hogy elosztott működésre ké-pes, azaz különböző részekből áll, amelyeket külön gé-pekre telepíthetünk. Fő komponensei:

– Director daemon (director): végzi a rendszer irányí-tását, kapcsolatot tart a többi démonnal, kommunikála különböző grafikus felületekkel, időzíti a mentése-ket, aktualizálja a katalógust.

– Storage daemon (sd): közvetlenül a mentő egységek-kel (szalagos meghajtó, HDD, DVD) tartja a kapcso-latot, kezeli a director olvasási/írási kéréseit, illetvefogadja az FD-től (lásd alább) érkező mentett adato-kat.

– File Daemon (FD): feladata a mentendő szerverek ésasztali gépek mentendő adatainak begyűjtése, tömö-rítése, titkosítása, majd az adatok továbbítása a kije-

16 http://www.bacula.org/en/

21

http://www.bacula.org/en/











lölt SD-nek. Valamint a visszaállításnál mindeztvisszafelé irányban is ellátja.

A Bacula egy központi katalógusban tárolja a men-tett állományokat és a fájlt tartalmazó kötet nevét, amentés időpontját, valamint egyéb adatokat is, segítveés gyorsítva ezzel az esetleges visszaállítást. Nagy elő-nye, hogy szinte mindenre kiterjedően konfigurálható,így megoldható az is, hogy a mentés indulása egy tet-szőleges egyedi héjprogram futtatásával kezdődjön,például egy adatbázismentést (MariaDB, MySQL, Post-greSQL dump) kezdeményezve. Egy igazi komplexmegoldás, amely a titkosítása és az elosztott működésemiatt a nagyvállalati felhasználásra is alkalmassá te-szi17.

Dirvish18

Szintén szerver alapú mentőeszköz, amely támasz-kodik az rsync és a Perl képességeire. Tudása nagybanhasonló az Amanda, vagy a Bacula lehetőségeihez,konfigurálása népszerűsége és a fellelhető dokumentá-

17 http://sugo.ubuntu.hu/10.10/html/serverguide/hu/bacula.html.18 http://www.dirvish.org/

22

http://www.dirvish.org/








http://sugo.ubuntu.hu/10.10/html/serverguide/hu/bacula.html.

http://sugo.ubuntu.hu/10.10/html/serverguide/hu/bacula.html


ció miatt talán könnyebb19. Ugyanúgy kezeli a legtöbbnagyvállalati szalagos eszközt és lehetőség van egyébpéldául merevlemez mentésére is. Az adatbázis menté-seket egy mentés indítását megelőző Perl vagy héjprog-rammal lehet megoldani akár Oracle, PostgreSQL,MySQL vagy egyéb adatbázis-kezelő esetén is. A kli-ens-szerver alapú mentés természetesen futhat SSHmegoldással20, így biztosítva a távoli gépek között azadatbiztonságot mentés esetén. Telepítését a megszo-kott módon az apt-get segítségével kezdjük meg:apt-get install dirvish ssh

A telepítés menete a Pull vagy Push (utolsó bekezdé-sek) alapján általunk követendőnek tekintett felépítéstelemzi, azaz a központilag védett és elkülönített backupszerver tud csatlakozni az összes klienshez, de a klien-sek nem tudnak csatlakozni közvetlenül hozzá.

Az alap konfigurációs állomány mintákat a /usr/sha-re/doc/dirvish/examples könyvtárban találjuk. Célszerű-en innen elsőnek a master.conf-ot másoljuk át a /etc/dir-vish/master.conf helyre. Akkor valami ehhez hasonlótfogunk látni:

19 http://www.googlux.com/dirvishconfig.html20 http://apt-get.dk/howto/backup/

23

http://apt-get.dk/howto/backup/












http://www.googlux.com/dirvishconfig.html












bank:/backup

exclude:/etc/mtab

/var/lib/nfs/*tab/var/cache/apt/archives/*.deb.cache/*.firefox/default/*/Cache/*/usr/src/**/*.olost+found/

Runall:eles1.szerver 21:00

eles2.szerver 23:00

expire-default: +15 daysexpire-rule:# MIN HR DOM MON DOW STRFTIME_FMT* * * * 1 +3 months# * * 1-7 * 1 +1 year# * * 1-7 1,4,7,10 1* 10-20 * * * +4 days# * * * * 2-7 +15 days

Nézzük meg pontosan, mi mire való:

24


A master.conf-ban azokat a változókat fogjuk beállí-tani, amelyek az összes mentendő gépre vonatkoznifognak, valamint itt definiáljuk azokat a gépeket is,amelyeket menteni akarunk. Értelemszerűen vagy hoz-zuk létre a /backup könyvtárat 700-as jogokkalroot:root felhasználóként, vagy írjuk át arra a könyvtár-ra, ahova menteni akarunk. A bank változóval határoz-hatjuk meg, hogy a program hol tárolja a ténylegesmentéseket.

Az exclude paraméterrel azokat a könyvtárakat hatá-rozhatjuk meg, amelyeket nem akarunk menteni, azazki akarjuk zárni őket a teljes mentésből. Mint az látha-tó, megadhatjuk abszolút és relatív módon is. Így vo-natkozhat az összes .firefox/ alatt lévő Cache könyvtár-ra is, de explicit kizárhatjuk a /lost+found/-ot is. Ezek aparaméterek központilag fognak vonatkozni az összeskésőbb definiált hostra, amelyet menteni fogunk, így ottmár nem kell külön ezeket felsorolni.

A Runall paraméterrel azt mondjuk meg a program-nak, hogy az egyes gépek mentését mikor futtassa, idetudjuk felsorolásszerűen befűzni a gépeinket, amelyeketa bank könyvtár alá létre is kell hozni. Azaz, létre kell

25


hozni a /backup/eles1.szerver és a /backup/eles2.szer-ver könyvtárakat is.

Az expire-default és expire-rule paraméterekkel azelévülési időt határozhatjuk meg, azaz az egyes menté-seket meddig tartsa meg, és mikortól kezdje felülírni.

Hogy tovább tudjunk lépni, a /backup/eles1.szerveralá létre kell hoznunk egy dirvish könyvtárat és abbanelhelyezni egy default.conf fájlt. Az elérési útja így néz-zen ki: /backup/eles1.szerver/dirvish/default.confa tartalma pedig a példa kedvéért legyen a következő:client: eles1.szerver.kft

tree: /index: gzipimage-default: %Y-%m-%dxdev: 1exclude:/var/spool/squid/

Értelemszerűen a client paraméternél megadjuk amentendő éles szerver hostnevét vagy IP-címét, ahova adirvish root felhasználóval fog csatlakozni. A tree para-méter pedig megmondja, hogy honnan indítjuk a men-tés. Jelen pillanatban az egész fájlrendszert szeretnénkmenteni, így a / került oda. Az image-default paramé-

26


terrel meghatározzuk a bank megfelelő alkönyvtárában,milyen struktúrát építsen, így az aktuális dátum lesz azIMAGE neve, azaz például 2013-10-17. Az xdev opció1-re való állításával megmondjuk az rsync-nek, hogy atávoli gépen csatolt összes lemezt mentse le.

Ha ezzel megvagyunk, akkor – mivel ez egy időzí-tett mentés – biztosítani kell, hogy a root felhasználójelszó nélkül tudjon csatlakozni. A legjobb és egybenbiztonsági szempontból is elfogadható kompromisszu-mos megoldás erre, ha a mentendő szerver root felhasz-nálója számára létrehozunk egy megfelelő SSH kulcsot,amely nem kér jelszót, a következőképpen:ssh-keygen -t rsa -b 8192 -C elesszerver

majd megadjuk neki, hogy mi legyen a kulcsállományneve:Enter file in which to save the key

(/root/.ssh/id_rsa): /root/elesszerver1

A következő kérdésre, azaz mi legyen a kulcs jelsza-va, csak egy Entert nyomunk:Enter passphrase (empty for no passphrase):

Az így elkészült kulcs használata esetén nem fog jel-szót kérni az SSH kliens, így a dirvish sem, de nézzük

27


mit kell még tennünk, annak érdekében, hogy ez mű-ködjön:a /root/.ssh/config állományt szerkesszük (a backup gé-pen), és oda vegyük fel a következő sorokat:Host *

ServerAliveInterval 60ServerAliveCountMax 10

Host eles1.szerver IdentityFile /root/elesszerver1 Port 22 Protocol 2 User root HostName 172.27.1.1 PasswordAuthentication no

Ha ezzel megvagyunk, akkor az éles szerverre felkell juttatni az elkészített SSH-kulcs publikus részét, te-hát például scp-vel másoljuk azt oda:scp /root/elesszerver1.pub

[email protected]:.ssh/authorized_keys

Teszteljük is le a backup gépről indított ssh parancssegítségével, hogy minden rendben van-e, azaz been-

28


gedtük a tűzfalon, az SSH engedi a root hozzáférést,stb.:ssh -i /root/elesszerver1

[email protected]

Ha sikerült bejutnunk, akkor már csak annyi a dol-gunk, hogy a dirvish-t is inicializáljuk:dirvish --vault eles1.szerver --init

Az elkészített konfiguráció alapján a dirvish az SSH-n keresztül lementi – a kivételek kezelése mellett – azegész gépet. Majdnem készen is vagyunk, most márcsak az olyan dolgokat kell még mentenünk, amelyeketfutási időben nem célszerű. Ilyen tipikus példa az SQLszerverek (MySQL, MariaDB, PostgreSQL stb.), ezeketnem csak nem célszerű futási időben egy egyszerű cpvagy rsync segítségével másolni vagy szinkronizálni,hanem felesleges is, mivel tipikusan egy nyitott adatbá-zisba a mentési idő alatt is írnak, azaz a tartalma válto-zik. Az aktuális állapotokat az ilyen esetben érdemes aDirvish segítségével vagy Pre, vagy Post szkriptek írá-sával21, vagy pedig előre ütemezett SQL mentés segít-ségével a saját segédeszközeikkel dumpolni, majd a

21 http://wiki.dirvish.org/ClientScriptsOnServer

29

http://wiki.dirvish.org/ClientScriptsOnServer


konzisztens és mentés értékű dump állományokat akárfájlrendszer szinten már menteni és verziókövetni. Denézzünk konkrét példákat:

Jelen esetben mivel a MySQL és a MariaDB teljesenkompatibilisek (lásd bővebben az Adatbázis-kezelők22

fejezetben) a mentési parancsok és tervezés sem fog el-térni, ezért a továbbiakban csak SQL-nek fogjuk hívni aMariaDB-t és MySQL-t. Ez a mentési megoldás feltéte-lezi, hogy az adatbázis-szerver külön szerveren szepa-rálva található, így ütemezetten a cron segítségével ésegyedi szkript írásával készítjük el az SQL mentését,nem a dirvish adottságaira támaszkodunk.

Az SQL adatbázisok mentésére több megoldás isadott. Egyrészt van a hagyományos út, amikor a mysql-dump-ot használjuk, vagy rendelkezésre áll egy hotco-py nevű kiegészítés, amelyet inkább csak a mysqldumpmellé, biztosítékként, vagy más cél mentés készítéséretaláltak ki.

22 http://szabadszoftver.kormany.hu/szabad-szoftver-keretrendszer/

30
















mysqldump23

Kifejezetten a konzisztens adatbázis-mentésre kihe-gyezett eszköz, a mysql csomag telepítésével a birtoko-sai leszünk az eszköznek. Természetesen ugyanúgy sza-bályozható az /etc/mysql/my.conf fájlban a dump általhasznált erőforrások egy része is, mint a sima MySQLcsatlakozások esetén. Lokális mentés esetében a bevettmódszer, hogy a mysqldump parancsot egy szkript ré-szeként crontab-ból hívva egy olyan időintervallumbanfuttatjuk, amikor a szerver úgynevezett idle (üresjárati,csúcsterhelésen kívüli) periódusban van. Az ilyen idő-szakok tervezésében nagy segítségünkre lehet a munin,amelyről a Naplózás, monitoring24 fejezetben olvasha-tunk bővebben. Egy egyszerű mentő szkript tehát vala-hogy így nézzen ki (az adatbázis-szerveren)a szkript neve és elérési útja:

/backup/ment.sh#! /bin/sh

/usr/bin/mysqldump --all-databases -pjelszo --events | /bin/gzip >

23 http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html24 http://szabadszoftver.kormany.hu/szabad-szoftver-

keretrendszer/

31















http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html


















/backup/SQL/mysql-ALLDATABASE-$1.tgz/usr/bin/mysqldump -p --skip-lock-tables information_schema | /bin/gzip > /backup/SQL/openmail-mysql-information_schema-$1.tgz/usr/bin/mysqldump -p --events mysql | /bin/gzip > /backup/SQL/openmail-mysql-mysql-$1.tgz/usr/bin/mysqldump -p website | /bin/gzip > /backup/SQL/openmail-mysql-website-$1.tgz

Mint az látható, az első sorban az összes adatbázistkimentjük egy nagy állományba, majd mindent mégegyszer kimentünk egyenként külön tömörített állomá-nyokba is. Miért szükséges ez? A gyakorlati tapasztalatazt mutatja, hogy ha csak mindent egy nagy állomány-ba mentenénk ki, akkor viszonylag nehezen férhetnénkhozzá, ha csak egy adott rekordot töröl le pl egy progra-mozó a weboldalunk adatbázis-állományából és csakarra van szükség, akkor elég csak azt az egy adatbázistvisszadumpolni egy teszt adatbázisba. Viszont ha példá-ul egy korrupt fájlrendszer miatt kell teljes visszaállítástvégeznünk, akkor célszerű az egész komplett mentéstegyszerre visszatölteni (--all-databases), hiszen ilyen-

32


kor minden reláció (amelyek az information_schema,vagy mysql nevű adatbázisban vannak tárolva) vissza-töltődik. Éppen ezért, ha van rá lehetőségünk (nyilván-valóan egy sok 100 GB vagy TB-os adatbázis mentésétne így végezzük) és lemezterületünk, akkor mind a kétmódszerrel mentsünk. Az első inicializáló mentést vé-gezhetjük a time parancs a mentő szkript elé helyezésé-vel, hogy legyen fogalmunk arról, az SQL motor men-tés körülbelül mennyi időt vesz igénybe:time /backup/ment.sh

Figyeljünk rá, hogy az SQL mentés néha képes hibá-kat visszaadni, így a cron kimenete legyen mindig egyolyan e-mail címre irányítva, amelyet olvasunk is.Ugyanis annál, hogy nincs mentés, csak az rosszabb, haazt hisszük, tökéletes mentést készítünk, de már évekóta a /dev/null-ba irányított hibaüzenetekkel fut a men-tés, amelynek esetlegesen az az eredménye, hogy üresvagy éppen hibás állományt mentünk. Éppen ezért cél-szerű néha kicsomagolni az SQL mentés állományaitvagy zless segítségével belenézni (persze csak ha nemsok GB nagyságúak). Illetve célszerű betervezni olyannapokat esetleg havonta vagy fél évente, amikor a teljes

33


SQL motort egy teszt környezetben újra felépítjük amentésből.

Felmerülhet a kérdés, hogy mi van akkor, ha én azösszes adatbázist is menteni szeretném egyben és kü-lön-külön az adatbázisokat, de nem érek rá lekövetni,hogy ki mikor hoz létre új adatbázist, de mégis szeret-ném, hogy azok is benne legyenek a szeparált mentés-ben?

Erre egy remek lehetőséget ad a következő szkript25,amely a mysql show és a mysqldump tudását használjafel arra, hogy ha valaki létrehozott a tudomásunkon kí-vül egy új adatbázist, akkor az is biztosan le legyenmentve:#! /bin/bash

TIMESTAMP=$(date +"%F")BACKUP_DIR="/backup/$TIMESTAMP"MYSQL_USER="backup"MYSQL=/usr/bin/mysqlMYSQL_PASSWORD="jelszo"MYSQLDUMP=/usr/bin/mysqldump

25 http://dev.mensfeld.pl/2013/04/backup-mysql-dump-all-your-mysql-databases-in-separate-files/

34

http://dev.mensfeld.pl/2013/04/backup-mysql-dump-all-your-mysql-databases-in-separate-files/





























mkdir -p "$BACKUP_DIR/mysql" databases=`$MYSQL --user=$MYSQL_USER -p$MYSQL_PASSWORD -e "SHOW DATABASES;" | grep -Ev "(Database|information_schema)"` for db in $databases; do $MYSQLDUMP --force --opt --user=$MYSQL_USER -p$MYSQL_PASSWORD --databases $db | gzip > "$BACKUP_DIR/mysql/$db.gz"done

Mysqlhotcopy26

A hotcopy egy remek megoldást kínál olyan esetek-re, amikor csak bizonyos rekordokat kell visszaállíta-nunk, vagy éppen muszáj futási időben az éles szerve-ren menteni, de sok konkurens írás/olvasás miatt amysqldump zárolásos mentési módszere nem várhatóki, vagy olyan lassulást eredményezne, amely nem vál-lalható futási időben. Azaz ezt a módszert főként nap-közbeni duplikálásra, vagy közbenső mentésre ajánljuk.

26 http://dev.mysql.com/doc/refman/5.0/en/mysqlhotcopy.html

35

http://dev.mysql.com/doc/refman/5.0/en/mysqlhotcopy.html


Használata csak az InnoDB27 típusú adatbázis eseténengedélyezett, viszont mivel általában ez az alapbeállí-tás, így általános esetben működőképes. A kézikönyveszerint online mentésnek hívják, ugyanis nem zárolja azegész adatbázist, hanem táblánként használja a lock, aflush és az unlock parancsokat, miközben kimásolja ál-lományba *.frm, *.MYD, *.MYI állományokat. Hasz-nálhatjuk ugyanúgy szkriptben és cronból meghívva:mysqlhotcopy -u root -p jelszo dbneve

/backups/SQL/HOTCOPY/ --allowold --keepold

Jellemzően a rendszergazdák az SQL mentő szkrip-teket a /backup könyvtárban tárolják, és onnan is hívjákmeg. Két fontos dolog amire érdemes figyelni: a /back-up könyvtár mindenestül csak a root számára legyen ol-vasható, írható és bejárást (+x ) is csak számára bizto-sítsunk. A második fontos tanács, hogy a backup szkrip-tet is mentsük. Egy esetleges átállás vagy adatvesztésesetén egy rendes backup szkript elkészítése is sokmunkaórát takarhat. Ezért érdemes vagy átlinkelni az/etc alá, amit mentünk, vagy eleve ott tárolni.

27 http://dev.mysql.com/doc/refman/5.0/en/innodb-storage-engine.html

36

http://dev.mysql.com/doc/refman/5.0/en/innodb-storage-engine.html

http://dev.mysql.com/doc/refman/5.0/en/innodb-storage-engine.html


Melyiket válasszam: a Dirvish pre szkriptrendszerét, vagy az ütemezett mentéstaz SQL gépen?

A válasz viszonylag egyszerű: ha nem akarunk vagynem tudunk törődni azzal, hogy kézzel ütemezzük be azSQL mentéseket, akkor célszerű post szkriptet készíte-ni, hiszen így a mentési folyamat fogja megszólítani ésutasítani az SQL gépet a mentésre, majd ha az készenvan, akkor fogja átemelni a backup gépre a biztosan el-készült mentést. Ha viszont az SQL gépen már elevekénytelenek voltunk más megfontolásból lefuttatni amentést például hajnali 2-kor, mivel csak 2-3 közöttvállalható az, hogy egy ekkora kaliberű terhelés érje agépet – azaz ez a szempont fontosabb – akkor ehhezkell igazítanunk a dirvish-t, és esetlegesen beépíteniúgynevezett jelzőket a rendszerbe. Azaz, ha valamiért(nem várt lassulás, például a terhelés megugrása miatt)az SQL mentés bár elindult hajnali 2-kor, de nem záró-dik le a megszokott 45 perc alatt, akkor a mentő szkriptelhelyezhet egy LOCK állományt a /backup/SQL alatt(echo /backup/LOCK), amelyet egy dirvish post szkriptsegítségével figyelhetünk, és kaphatunk róla értesítést,vagy felfüggeszthetjük a mentést a LOCK állomány

37


meglétéig. Felfüggesztés esetén ütemezzük úgy, hogy adirvish utolsó dolga az SQL állományok áthozatala le-gyen, hogy egy esetleges SQL szerver fennakadás ésezzel együtt a mentés megakadása miatt a többi részmentése ne akadhasson el.

Hogyan mentsünk, melyikethasználjuk és mikor?

A leggyakoribb mentőeszközöket soroltuk fel, ame-lyek segítségével össze lehet állítani egy ideális mentésta dokumentum elején felsorolt szempontok figyelembevétele mellett. Dönteni egyik vagy másik mentőrend-szer mellett a mentendő szerverek és kliensek ismeretenélkül nem célszerű. Ajánlásunk az, hogy kombinálvahasználjuk a fenti rendszereket szükség szerint. Azaz aklienseket sok esetben nem szabad kifelejteni a mentés-ből, még akkor sem ha belső szabályzat kimondja, hogya gépen tárolt dokumentumok nincsenek mentve, hi-szen az adatvesztés ilyenkor is jelentős lehet, ha egyfelhasználó megszegve az előírásokat a saját gépén tá-rolta a fontos dokumentumokat.

38

Hogyan mentsünk, melyiket használjuk és mikor?

Kisvállalati, kis irodai közegben éppen ezért a szer-verek mentésének Bacula, Dirvish használatával vagyegyéb komplex módon történő megoldása esetén is ér-demes gondolni a kliensgépekre, és ha esetleg nincs le-hetőség azok befűzésére a központi mentő megoldásokközé, akkor is megoldás lehet, ha a kliens gépre telepí-tünk (értelemszerűen asztali Linux esetén) egy rsnaps-hotot, amely például a halt parancs meghívása előtt,vagy akár ütemezetten cronból a lokális merevlemezrevégez egy mentést. Így ha a felhasználó nem is tartottabe a játékszabályokat, nem éri adatvesztés egy véletlentörlés esetén. Természetesen fizikai hiba ellen ez semvéd, hiszen ugyanazon az eszközön tároltuk a mentéstés az éles adatokat. Az ilyen esetek ellen csak a függet-len mentő szerver kialakítása védhet, ahol minden ala-posan mentve és tesztelve is van.

Szerverek esetében pedig érdemes kombinálni amentéseket. Ha van rá lehetőségünk, akkor egy teljesgép tönkremenetele esetén nagyban gyorsítja a visszaál-lítást, ha van egy teljes lemezkép, amelyet esetleg csaka napi mentéshez kell aktualizálni. Ilyenkor egy arrabetanított ügyeletes is képes lehet az alap lemezképvisszaállítására, amely órákkal vagy akár napokkal is

39


gyorsabb lehet, mint egy alaprendszer telepítése, majdarra a rendszer visszaszinkronizálása mentésből. Érde-mes felkészülni, és akár papíralapú dokumentáció for-májában a szerver mellett tartani egy boot loader doku-mentációt. Hasznos lehet, mivel tipikusan a boot loaderaz, amelyet nem használunk nap mint nap. Nagyon rit-kán, de előfordulhat, hogy az adataink nem sérülnek, dea partíciós tábla igen. Az üzemeltetők jelentős része eztsoha sem menti, hiszen sok éves tapasztalat alapjánnincs rá szükség, ugyanakkor csak egy egyszerű pa-rancs, és ha gond adódik a táblával, akkor van kiindulá-si alap. Akár így is: dd if=/dev/sda of=/mentes/gepemneve-lemezem

bs=512 count=1

Helyreállítás a mentés lemezkép alapján:dd if=/mnt/gepemneve-lemezem of=/dev/sda

bs=1 count=64 skip=446 seek=446

Adatmegsemmisítés

A mentéshez kapcsolható feladat a nem használt esz-közök biztonságos megsemmisítése, amelyre olygyakran nem fordítunk egyáltalán figyelmet. Egy márhasználaton kívüli szerver merevlemeze, vagy bármi-

40


lyen adattárolója veszélyforrást jelenthet, ha csak úgykidobjuk. Főként a szalagos egységek jelentik a men-téshez kapcsolódóan a legnagyobb veszélyt, mivel a ré-gi használaton kívüli szalagokat ritkán szokták bizton-ságosan megsemmisíteni, egyszerűen csak kidobják aszemétbe. Rendszeresen olvasni a hírekben, hogy kü-lönböző adatbiztonsággal foglalkozó cégek véletlensze-rűen vásárolnak használt komplett PC-ket, vagy csakadathordozókat, és próba visszaállításokat végeznek. Alegtöbb esetben már eleve csak gyors formázást, vagymég azt sem végeznek az emberek, így az adatok köny-nyedén visszaállíthatóak. A szerverek illetve szalagokesetében valamivel bonyolultabb a helyzet, mert komo-lyabb szaktudás szükséges a visszaállításhoz példáulegy RAID eszköz esetén. Érdemes tehát számításbavenni, hogy a kidobásra ítélt eszközök adathordozói ve-szélyforrást jelenthetnek. Egy remek eszköz a Wipe28,amely Linux alatt az adatok biztonságos felülírását vég-zi.

28 http://wipe.sourceforge.net/

41

http://wipe.sourceforge.net/









Pull vagy Push?

A felsorolt mentő eszközök jelentős része támogatjalehetőséget ad arra, hogy egy központi mentő szerverrőlindított távoli általában SSH-n keresztüli bejelentkezé-sen keresztül a mentő szerver mentsen, illetve azt is,hogy fordítva a kliensek kezdeményezzék a mentést atávoli backup szerverre. Mind a két megoldás lehet jóés rossz is egyszerre.

Ha képesek vagyunk a mentő szervert fizikailag, há-lózatilag és szoftveresen teljesen szeparálni, azaz jólmegvédeni, akkor adott esetben jó megoldás lehet, ha amentő szerver rendelkezik a távoli szerverekre rootvagy azzal egyenértékű jogokkal és így a mentő szerverfogja ütemezetten kezdeményezni a mentéseket. Ebbenaz esetben viszont mivel az összes éles szerver SSHkulcsát feltettük a mentő szerverre, a mentő szervertténylegesen extrém módon meg kell védenünk és bár-milyen hozzáférést tiltani.

Ha a másik módszert választjuk, amikor is az élesszervereink jelentkeznek be a mentő szerverre, akkornem koncentrálódik egy kézben az összes hozzáférés,viszont ebben az esetben az Achilles-sarka a mentésnek

42


az lesz, hogy az éles szerver esetleges kompromittáló-dása esetén a támadó el fog „látni” a backup szerverirányába. Ez ellen védekeznünk kell mindenképpen.Erre több jó megoldás is van. Az egyik ezek közül, ha amentő szerveren minden éles szervernek elkülönítettchrootolt (SFTP vagy scponly shell) hozzáférése van.Ekkor a támadó „csak” az éles szervert és annak menté-sét tudja megsemmisíteni. Ennek kikerülésére, ha ezt amódot választjuk, érdemes a chroot környezetből egyidőzített szkript segítségével minden mentés végeztévela backup anyagokat elmozgatni egy olyan területre,ahol a chrootolt backup felhasználó – amely az élesszerver felől jön – nem láthatja már. Sajnos számtalanesettanulmány bizonyítja internet szerte, hogy ha egy-szer ténylegesen betörtek az éles szerverünkre, akkor alegtöbb esetben – célzott támadás esetén mindenkép-pen– végigmennek az elérhető összes lehetőségen(mentett gépek továbbtámadása) is, így a backup mintegy könnyen felderíthető (cron szkripteket használó)rendszer, adja magát. Ebből a szemszögből nézve adottesetben jobb megoldás lehet az első változat, amikor abackup szerver kívülről az éles szerverek felől elérhe-tetlen, csak ő tud kezdeményezni.

43


Visszaállítási tesztek: Ahogy már említettük minden-képpen legyen egy ütemezett tervünk, mikor melyikmentést teszteljük és állítjuk belőle vissza az adatokat.Ha nincs rá külön fenntartott gépünk, akkor használ-junk virtualizációs környezetet.

Kliensek mentése

Manapság inkább az jellemző, hogy az asztali számí-tógépek mint egyfajta vékonykliens viselkednek, azaztárolunk ugyan adatokat rajta, de a munkával összefüg-gő dolgok vagy egy böngészőben, vagy egy SSH termi-nálban, vagy egy távoli SMB megosztásra történnek.Ebben az esetben az alapvető hozzáállás, hogy a klienst1-2 órán belül ugyanolyanra tudjuk varázsolni, ha tény-leg mindent a szerverre mentettünk. Ez így is van,azonban még így is célszerű menteni a kliensek /etc/alatti konfigurációs állományait és legalább a /homekörnyezetet. Ha a menteni kívánt kliensek Linux vagyBSD, vagy bármilyen Unix-klón alapúak, akkor szeren-csések vagyunk, mert a már megismert módszerekegyikét alkalmazhatjuk. Azaz ha az asztali számítógép

44

Kliensek mentése

tud SSH kapcsolatot indítani vagy fogadni, akkorugyanúgy menthetjük Rsnapshot-tal vagy akár Dirvish-sel is központilag. Ha pedig szeretnénk a felhasználórabízni (ez általában nem jó ötlet), hogy a saját kliensénmit ment és mit nem (hiszen egy központilag mentettmeghajtóra dolgozik amúgy is) akkor például a menten-dő kliensen futtathatunk Grsyncet.

Grync29

Ezt a grafikus felületet az rsync meglehetősen bo-nyolult opcióinak átláthatóbbá tételére hozták létre. Afejlesztők a leginkább használt funkciókat grafikus for-mába öntötték. Akár a teljes funkcionalitást könnyen ellehet érni a kiterjesztett nézetben, azonban az igazánhasznos funkciója az, hogy az 1-2 perc alatt egérrel ösz-szeállított beállításokat egy nézet menüben parancs for-májában is lementhetjük. Kezdő rendszergazdáknakideális a kapcsolók nem teljes ismerete esetén, ugyanisa tévedést lehet vele minimalizálni. Működtetését szer-verek között érdemes kombinálni az ssh-agent30 és az

29 http://www.opbyte.it/grsync/30 http://en.wikipedia.org/wiki/Ssh-agent

45

http://en.wikipedia.org/wiki/Ssh-agent













http://www.opbyte.it/grsync/











~/.ssh/config állományba felvett rövid gépnevek felso-rolásaival. Például:Host szervergep

IdentityFile /home/admin/identity-szerver-titkoskulcs Port 22 Protocol 2 User root HostName szerver.belsohalo.hu PasswordAuthentication no

46

Kliensek mentése

47

Documents

Adatmentési (backup) megoldások Linux alatt Szabad szoftver