Rezervo ne estas unu el la laŭmodaj teknologioj, pri kiuj oni krias de ĉiu fero. Ĝi nur devas esti en iu serioza kompanio, jen ĉio. Ni rezervas plurajn milojn da serviloj en nia banko - ĉi tio estas kompleksa, interesa laboro, kies subtilecoj, same kiel tipaj miskomprenoj pri sekurkopioj, nur volas esti rakontitaj.
Mi laboras pri ĉi tiu temo dum preskaŭ 20 jaroj, el kiuj la lastaj 2 jaroj estis ĉe Promsvyazbank. Je la komenco mem de la praktiko, mi faris sekurkopiojn preskaŭ permane, kun skriptoj kiuj simple kopiis dosierojn. Tiam en Vindozo aperis oportunaj iloj: la ilo Robocopy por prepari dosierojn kaj NT Backup por kopiado. Kaj nur tiam venis la tempo por speciala programaro, ĉefe Veritas Backup Exec, kiu nun nomiĝas Symantec Backup Exec. Do mi jam delonge konas sekurkopiojn.
En simplaj terminoj, sekurkopio estas konservi kopion de datumoj (virtualaj maŝinoj, aplikoj, datumbazoj kaj dosieroj) ĉiaokaze kun certa reguleco. Ĉiu kazo kutime manifestiĝas kiel aparataro aŭ logika fiasko kaj rezultigas datumperdon. La celo de rezerva sistemo estas redukti la perdon de informoj. Hardvarmalsukceso estas, ekzemple, fiasko de la servilo aŭ stokado kie la datumbazo situas. Logika - ĉi tio estas la perdo aŭ ŝanĝo de parto de la datumoj, inkluzive pro la homa faktoro: ili hazarde forigis tabelon, dosieron, lanĉis malrektan skripton por ekzekuto. Ekzistas ankaŭ reguligaj postuloj por konservi certan tipon de informoj dum longa periodo, ekzemple, ĝis pluraj jaroj.
La plej tipa uzo de sekurkopioj estas la restarigo de konservita kopio de datumbazoj por la deplojo de diversaj testaj sistemoj, klonoj por programistoj.
Estas kelkaj tipaj mitoj pri sekurkopio, kiuj devus esti forigitaj antaŭ longe. Jen la plej famaj el ili.
Mito 1. Sekurkopio longe estis nur malgranda funkcio ene de sekureco aŭ stokadsistemoj
Rezervsistemoj daŭre restas aparta klaso de solvoj, kaj tre sendependaj. Ili havas tro da laboro por fari. Fakte, ili estas la lasta defendlinio kiam temas pri datuma integreco. Do sekurkopio funkcias laŭ sia ritmo, laŭ sia propra horaro. Ĉiutaga raporto estas generita por la serviloj, estas eventoj, kiuj funkcias kiel ellasiloj por la monitora sistemo.
Krome, la rolmodelo de aliro al la rezerva sistemo permesas vin delegi parton de la aŭtoritato al administrantoj de celsistemoj por administri sekurkopiojn.
Mito 2. Kiam estas RAID, sekurkopio ne plu bezonas.
Sendube, RAID-tabeloj kaj reproduktado de datumoj estas bona maniero protekti informsistemojn kontraŭ aparataj misfunkciadoj, kaj se vi havas standby-servilon, vi povas rapide organizi ŝanĝadon al ĝi se la ĉefa maŝino malsukcesas.
De la logikaj eraroj faritaj de la uzantoj de la sistemo, redundo kaj reproduktado ne savas. Ĉi tie estas reskriba standby servilo - jes, ĝi povas helpi se eraro estas detektita antaŭ ol ĝi estis sinkronigita. Kaj se la momento estas maltrafita? Nur ĝustatempa sekurkopio helpos ĉi tie. Se vi scias, ke la datumoj ŝanĝiĝis hieraŭ, vi povas restarigi la sistemon al antaŭhieraŭ kaj ĉerpi el ĝi la necesajn datumojn. Konsiderante la fakton, ke logikaj eraroj estas la plej oftaj, la bona malnova sekurkopio restas pruvita kaj necesa ilo.
Mito 3. Rezervo estas io, kio estas farita unufoje monate.
La rezerva ofteco estas agordebla agordo, kiu ĉefe dependas de viaj rezervaj sistemaj postuloj. Eblas trovi datumojn, kiuj preskaŭ neniam ŝanĝiĝas kaj ne estas precipe gravaj, ilia perdo ne estos kritika por la kompanio.
Ili ja povas esti sekurkopiitaj unufoje monate kaj eĉ malpli ofte. Sed pli da kritikaj datumoj estas konservitaj pli ofte, depende de la indikilo RPO (Recovery point objrective), kiu fiksas la permeseblan perdon de datumoj. Ĉi tio povas esti unufoje semajne, unufoje tage aŭ eĉ plurajn fojojn hore. Ni havas ĉi tiujn transakciajn protokolojn de la DBMS.
Kiam sistemoj estas metitaj en komercan operacion, rezerva dokumentaro devas esti aprobita, kiu reflektas la ĉefajn punktojn, la ĝisdatigan proceduron, la proceduron por restarigi la sistemon, la proceduron por stoki sekurkopiojn kaj similajn.
Mito 4. La volumo de kopioj konstante kreskas kaj plene okupas ajnan asignitan spacon.
Rezervoj havas limigitan retenperiodon. Ne havas sencon, ekzemple, stoki ĉiujn 365 ĉiutagajn sekurkopiojn dum la jaro. Kiel regulo, estas akcepteble konservi ĉiutagajn kopiojn dum 2 semajnoj, post kiuj ili estas anstataŭigitaj per freŝaj, kaj la versio, kiu estis farita unue en la monato, restas en longdaŭra konservado. Ĝi, siavice, estas ankaŭ konservita por certa tempo - ĉiu kopio havas vivdaŭron.
Estas protekto de perdo de datumoj. La regulo validas: antaŭ ol sekurkopio estas forigita, la sekva devas esti formita. Sekve, la datumoj ne estos forigitaj se la sekurkopio ne estas kompletigita, ekzemple, pro la nehavebleco de la servilo. Ne nur tempokadroj estas respektataj, sed la nombro da kopioj en la aro ankaŭ estas kontrolita. Se la sistemo estas desegnita por havi du plenajn sekurkopiojn, ĉiam estos du el ili, kaj la malnova estos forigita nur kiam nova tria estos sukcese skribita. Do la kresko de la volumo okupata de la rezerva arkivo rilatas nur al la kresko de la kvanto de protektitaj datumoj kaj ne dependas de la tempo.
Mito 5. Rezervo komenciĝis - ĉio pendis
Pli bone estas diri ĉi tion: se ĉio pendas, tiam la manoj de la administranto ne kreskas de tie. Ĝenerale, la agado de sekurkopio dependas de multaj faktoroj. Ekzemple, pri la rapideco de la rezerva sistemo mem: kiom rapide estas disko-stokado, bendbibliotekoj. De la rapideco de la serviloj de la rezerva sistemo: ĉu ili havas tempon por prilabori datumojn, plenumi kunpremadon kaj malduplikadon. Kaj ankaŭ pri la rapideco de la komunikadlinioj inter la kliento kaj la servilo.
La sekurkopio povas iri al unu aŭ pluraj fluoj, depende de ĉu la sistemo subtenata subtenas multifadenadon. Ekzemple, la Oracle DBMS permesas vin doni plurajn fadenojn, laŭ la nombro da disponeblaj procesoroj, ĝis la transiga indico trafas la retan bendolarĝan limon.
Se vi provas sekurkopii grandan nombron da fadenoj, tiam estas ŝanco troŝarĝi funkciantan sistemon, ĝi vere komencos malrapidiĝi. Tial, la optimuma nombro da fadenoj estas elektita por certigi sufiĉan agadon. Se eĉ la plej eta malkresko de rendimento estas kritika, tiam ekzistas bonega eblo kiam la sekurkopio estas farita ne de batalservilo, sed de ĝia klono - standby en datumbaza terminologio. Ĉi tiu procezo ne lanĉas la ĉefan laborsistemon. Datenoj povas esti prenitaj per pli da fluoj, ĉar la servilo ne estas uzata por prizorgado.
En grandaj organizoj, aparta reto estas kreita por la rezerva sistemo tiel ke la sekurkopio ne influas la produktadon. Krome, trafiko eble ne estas elsendita tra la reto, sed tra la SAN.
Ni provas disvastigi la ŝarĝon ankaŭ laŭlonge de la tempo. Sekurkopioj estas plejparte faritaj dum nelaboraj horoj: nokte, semajnfine. Krome, ili ne ĉiuj kuras samtempe. Rezervoj de virtualaj maŝinoj estas speciala kazo. La procezo preskaŭ ne efikas sur la agado de la maŝino mem, do la sekurkopio povas esti disvastigita dum la tago, kaj ne prokrasti ĉion nokte. Estas multaj subtilecoj, se vi konsideras ĉion, sekurkopio ne influos la agadon de sistemoj.
Mito 6. Lanĉis rezervan sistemon - tio estas faŭltoleremo por vi
Neniam forgesu, ke rezerva sistemo estas la lasta defendlinio, kio signifas, ke devus esti kvin pliaj sistemoj antaŭ ĝi, kiuj certigas la kontinuecon, altan haveblecon kaj katastrofan toleremon de la IT-infrastrukturo kaj entreprenaj informsistemoj.
Ne indas, ke la sekurkopio restarigos ĉiujn datumojn kaj rapide altigos la falitan servon. Perdo de datumoj de la momento de sekurkopio ĝis la momento de malsukceso estas garantiita, kaj datumoj povas esti alŝutitaj al nova servilo dum pluraj horoj (aŭ tagoj, ĉar vi estas bonŝanca). Sekve, havas sencon krei plenrajtajn mistolerajn sistemojn sen ŝanĝi ĉion al sekurkopio.
Mito 7. Mi starigis sekurkopion unufoje, kontrolis ke ĝi funkcias. Restas nur rigardi la ŝtipojn
Ĉi tiu estas unu el la plej malutilaj mitoj, kies falsaĵo vi rimarkas nur dum la okazaĵo. Sukcesaj rezervaj protokoloj ne estas garantio, ke ĉio vere iris kiel ĝi devus. Gravas antaŭe kontroli la konservitan kopion pri deplojebleco. Tio estas, komencu la reakivan procezon en testa medio kaj rigardu la rezulton.
Kaj iom pri la laboro de la sistemadministranto
En mana reĝimo, neniu kopiis datumojn dum longa tempo. Modernaj SRK-oj povas konservi preskaŭ ĉion, vi nur devas agordi ĝin ĝuste. Se nova servilo estis aldonita, agordu politikojn: elektu la enhavon, kiu estos konservita, specifu stokadopciojn kaj apliku la horaron.
Samtempe, estas ankoraŭ multe da laboro pro la ampleksa aro de serviloj, inkluzive de datumbazoj, poŝtaj sistemoj, virtualaj maŝingrupoj kaj dosierpartoj ambaŭ en Vindozo kaj Linukso/Unikso. Dungitoj, kiuj funkcias la rezervan sistemon, ne sidas senmovaj.
Omaĝe al la festo, mi ŝatus deziri al ĉiuj administrantoj fortajn nervojn, klarecon de movoj kaj senfinan spacon por konservi sekurkopiojn!
fonto: www.habr.com