TSM Offsite Backup


Tagek: TSM,
Írta: toshy
Publikálva: 2008-09-26 06:43:09

Ez a szerény cikk arról fog szólni, hogy hogyan működik, vagyis én hogyan csinálom az offsite backup-ot. Egyébként mint már másik írásomban is megjegyeztem az a szép ebben a TSM-ben, meg hát nem csak abban, hogy úgy alakíthatod/formálhatod ahogy neked tetszik. Az offsite szintén ilyen a TSM-en belül is, de hogy miről is beszélek azt mindjárt meglátjuk.

Na lássuk, hogy miért is akarunk ilyet csinálni. Egy TSM azért van hogy biztonsági mentést csináljunk, DE milyen “biztonsági” mentés az a ha miután megcsináltam a mentésed ott figyel a szervered mellet, és ha mondjuk beázik a tető, vagy kigyullad valami, vagy bármi más külső hatás éri a szerver szobát ? Semmilyen. Ezért a mentési stratégiák általában olyanok, hogy a mentésedet egy földrajzilag másik helyen tárolod, vagy másik helyen is tárolod. A földrajzilag másik hely lehet másik épület, másik telephely, másik város….. stb. Általában azt is biztosítani kell, hogy más ne férhessen hozzá, ezért széf-be szokták tartani. Ilyen szolgáltatás lehet Bank-oknál, vagy erre szakosodott cégeknél is, szerencsére van már ilyen Magyarországon is. TSM-en belül egyébként DR-nek hívják a folyamatot, ami a “Disaster Recovery”-nek a rövidítése.

Szóval az offsite tárolási megoldásom a következő:

Van a DISK device class-os PRIMARY STGPOOL-om, és van egy LTODEV device class-os COPY STGPOOL-om. Admin schedul-ból minden nap megcsinálja a szinkronizációt a két STGPOOL között. Tehát egy másolatom már van az adatokról. Az adatbázist szintén admin schedul-ból, szintén TAPE-re menti minden nap. Ebből érdemes megtartani visszamenőleg többet is. Mivel most minden adat megvan DISK-en és TAPE-en is, ezért elvileg a TAPE-eket akár ki is lehetne szállítani. Azért az nem megy olyan egyszerűen, hogy kiszállítjuk és kész. A TSM-ben ez folyamatokra van bontva amik a következő képen néznek ki:



Ahhoz hogy teljesen vissza tudjunk állítani egy TSM szervert, az adatokon kivül szükségünk van egy adatbázisra, a device.config-ra illetve a volume history-ra. Tehát, először csinálunk egy db backup-ot, hogy meglegyen a legfrissebb adatbázis az adott pillanatban.

tsm:>backup db dev=ltodev type=full
ANR2280I Full database backup started as process 86.
ANS8003I Process number 86 started.

Ha ez megvan akkor elmentjük a volume history-t is.

tsm:>backup volhist filenames=/tmp/volhist.mentes

A device config file-t nem kell mentenünk mert a TSM szerver könyvtárában található.

Na megvannak a file-ok, megvan az adatbázis mentés, mehet a szalagok mozgatása:

tsm:>move drmedia * wherestate=mountable

Meg lehet adni neki egy tostate opciót is, ami a képen ábrázolt állapotokat veheti fel, ennek hiányában pedig mindig a következő állapotot veszi fel ami a mostani esetben a NOTMOUNTABLE . Tape library-tól függően elkezdi kirakni a szalagot az I/O slotba, vagy más néven a Bulk-ba. Azért tape libarary-tól függően, mert van aminek egy ilyen slot-ja van, van aminek több. Ha kivetted a szalagot, akkor ezt jelezned kell a TSM-nek is. Lekérdezzük a requesteket , és az ki is írja, hogy mi a teendőnk.

tsm:>query request
ANR8352I Requests outstanding:
ANR8322I 001: Remove LTO volume LTO006 from entry/exit port of library 3582; issue “REPLY” along with the request ID when ready.

Szóval ha kivettük a szalagot akkor ebben az esetben a REPLY 1 paranccsal tovább lökdössük. Ezt addig kell folytatnunk amíg csak létezik “request”. Az üres szalagokat benne hagyja. Minden kép érdemes a DB backup-ot tartalmazó szalagokat megjelölnünk, illetve esetleg azt is, hogy melyik a legfrissebb. Az elején elmentett file-okat kiríjuk CD-re, USB stick, bármilyen adathordozóra, és “csatoljuk” a szállítmányhoz.


És ennyi.

Oda lehet adni a futárnak, vagy a kollégának aki szállítja, és állíthatjuk a szalagok státuszát a következőre ami a COURIER vagyis futár. Ha a koléga vagy a futár visszaér/visszajelez akkor állíthatjuk a szalagok státuszát a következőre VAULT-ra.

Új szalagokkal fel kell tölteni a tape library-t, de ezt majd egy olyan írásban ahol a a szalagok ki/be check-olásáról lesz szó.

Érdekességként megemlítem még, hogy az OFFSITE -szalagokon is megcsinálja a TSM azokat a műveleteket amiket az ONSITE szalagokon. például a “SPACE RECLAMATION”-t úgy csinálja, hogy előveszi az adatbázisból, hogy milyen adatok van azon a két szalagon amit össze másolna, és ki írja őket egy harmadik szalagra, az előző kettőt pedig bejegyzi üresnek. A legközelebbi OFFSITE mentésnél a széfből ezeket az üres szalagokat újra fel lehet használni, és az azóta felgyűlt adatokat pedig kiszállítani. Íme egy lekérdezés amivel le lehet kérdezni , hogy melyek azok a szalagok amiket ki kell majd venni a széfből.

tsm:>SELECT volume_name FROM volumes WHERE access=”OFFSITE” AND status=”EMPTY”


Ez tökéletes végszónak, akarom mondani vég SQL-nek

Remélem valakinek ez is érdekes volt.

Szólj hozzá

Hozzászólások(1)