Ang backup ay hindi isa sa mga naka-istilong teknolohiya na isinisigaw ng lahat. Dapat lang sa anumang seryosong kumpanya, iyon lang. Ang aming bangko ay nagba-back up ng ilang libong mga server - ito ay kumplikado, kawili-wiling gawain, at gusto kong pag-usapan ang ilan sa mga pagkasalimuot nito, pati na rin ang mga tipikal na maling kuru-kuro tungkol sa mga backup.
Halos 20 taon na akong nagtatrabaho sa paksang ito, kung saan ang huling 2 taon ay nasa Promsvyazbank. Sa simula pa lang ng aking pagsasanay, halos manu-mano akong gumawa ng mga backup, gamit ang mga script na kinokopya lang ang mga file. Pagkatapos ay lumitaw ang mga maginhawang tool sa Windows: ang Robocopy utility para sa paghahanda ng mga file at NT Backup para sa pagkopya. At pagkatapos lamang dumating ang oras para sa espesyal na software, lalo na ang Veritas Backup Exec, na ngayon ay tinatawag na Symantec Backup Exec. Kaya matagal na akong pamilyar sa mga backup.
Sa madaling salita, ang pag-backup ay nagse-save ng kopya ng data (mga virtual machine, application, database at file) kung sakali na may isang tiyak na regularidad. Ang bawat kaso ay karaniwang nagpapakita ng sarili sa anyo ng isang hardware o lohikal na pagkabigo at humahantong sa pagkawala ng data. Ang layunin ng isang backup system ay upang mabawasan ang mga pagkalugi mula sa pagkawala ng impormasyon. Ang isang pagkabigo ng hardware ay, halimbawa, isang pagkabigo ng server o imbakan kung saan matatagpuan ang database. Ang lohikal ay ang pagkawala o pagbabago ng bahagi ng data, kabilang ang dahil sa kadahilanan ng tao: ang isang talahanayan o file ay aksidenteng natanggal, o ang isang script ay inilunsad upang magsagawa ng isang curveball. Mayroon ding mga kinakailangan sa regulasyon para sa pag-iimbak ng ilang uri ng impormasyon sa mahabang panahon, halimbawa, hanggang sa ilang taon.
Ang pinakakaraniwang paggamit ng mga backup ay ang pagpapanumbalik ng naka-save na kopya ng mga database para sa pag-deploy ng iba't ibang mga sistema ng pagsubok at mga clone para sa mga developer.
Mayroong ilang mga karaniwang alamat tungkol sa pag-backup na matagal nang dapat i-dispelling. Narito ang pinakasikat sa kanila.
Pabula 1. Ang pag-backup ay matagal nang maliit na function lamang sa loob ng mga sistema ng seguridad o storage
Ang mga backup system ay nananatili pa ring isang hiwalay na klase ng mga solusyon, at napaka-independiyente. Pinagkatiwalaan sila ng napakaimportanteng gawain. Sa totoo lang, sila ang huling linya ng depensa pagdating sa seguridad ng data. Kaya gumagana ang backup sa sarili nitong bilis, sa sarili nitong iskedyul. Ang isang pang-araw-araw na ulat ay nabuo sa mga server; may mga kaganapan na nagsisilbing mga trigger para sa sistema ng pagsubaybay.
Dagdag pa, ang modelo ng pag-access sa backup system ay nagbibigay-daan sa iyo na italaga ang ilan sa mga kapangyarihan sa mga administrator ng mga target na system upang pamahalaan ang mga backup.
Pabula 2. Kapag may RAID, hindi na kailangan ang backup
Walang alinlangan, ang mga array ng RAID at pagtitiklop ng data ay isang magandang paraan upang maprotektahan ang mga sistema ng impormasyon mula sa mga pagkabigo ng hardware, at kung mayroon kang standby server, mabilis na ayusin ang paglipat dito kung sakaling mabigo ang pangunahing makina.
Ang kalabisan at pagtitiklop ay hindi nagliligtas sa iyo mula sa mga lohikal na error na ginawa ng mga gumagamit ng system. Narito ang isang standby server na may naantalang pag-record - oo, makakatulong ito kung may natukoy na error bago ito i-synchronize. Paano kung makaligtaan ang sandali? Isang napapanahong backup lamang ang makakatulong dito. Kung alam mong nagbago ang data kahapon, maaari mong ibalik ang system noong nakaraang araw at kunin ang kinakailangang data mula rito. Isinasaalang-alang na ang mga lohikal na error ay ang pinaka-karaniwan, ang magandang lumang backup ay nananatiling isang napatunayan at kinakailangang tool.
Pabula 3. Ang pag-backup ay isang bagay na ginagawa minsan sa isang buwan.
Ang dalas ng pag-backup ay isang na-configure na parameter na pangunahing nakadepende sa mga kinakailangan ng backup system. Posibleng makahanap ng data na halos hindi nagbabago at hindi partikular na mahalaga; ang pagkawala nito ay hindi magiging kritikal para sa kumpanya.
Sa katunayan, maaari silang i-back up nang isang beses sa isang buwan o mas madalas. Ngunit mas madalas na nai-save ang mas kritikal na data, depende sa indicator ng RPO (Recovery point objrective), na nagtatakda ng katanggap-tanggap na pagkawala ng data. Ito ay maaaring isang beses sa isang linggo, isang beses sa isang araw, o kahit na ilang beses sa isang oras. Para sa amin, ito ay mga log ng transaksyon mula sa DBMS.
Kapag naglalagay ng mga system sa komersyal na operasyon, ang backup na dokumentasyon ay dapat maaprubahan, na sumasalamin sa mga pangunahing punto, mga regulasyon sa pag-update, mga pamamaraan sa pagbawi ng system, mga pamamaraan ng backup na imbakan, at mga katulad nito.
Pabula 4. Ang dami ng mga kopya ay patuloy na lumalaki at ganap na kumukuha ng anumang nakalaan na espasyo
Ang mga backup ay may limitadong buhay ng istante. Walang saysay, halimbawa, na iimbak ang lahat ng 365 araw-araw na pag-backup sa buong taon. Bilang isang patakaran, pinahihintulutan na mag-imbak ng pang-araw-araw na mga kopya sa loob ng 2 linggo, pagkatapos nito ay papalitan ng mga bago, at para sa pangmatagalang imbakan ang bersyon na unang ginawa sa buwan ay nananatili. Ito, sa turn, ay naka-imbak din para sa isang tiyak na oras - bawat kopya ay may panghabambuhay.
May proteksyon laban sa pagkawala ng data. Nalalapat ang panuntunan: bago matanggal ang isang backup, dapat gawin ang susunod. Samakatuwid, hindi matatanggal ang data kung nabigo ang backup, halimbawa, dahil sa hindi available na server. Hindi lamang iginagalang ang mga limitasyon sa oras, ngunit ang bilang ng mga kopya sa isang set ay kinokontrol din. Kung kinakailangan ng system na mayroong dalawang buong backup, palaging magkakaroon ng dalawa sa mga ito, at ang luma ay tatanggalin lamang kapag matagumpay na naisulat ang isang bagong pangatlo. Kaya't ang pagtaas sa dami na inookupahan ng backup na archive ay nauugnay lamang sa pagtaas ng dami ng protektadong data at hindi nakasalalay sa oras.
Pabula 5. Kapag nagsimula ang isang backup, lahat ay nag-freeze
Mas mainam na sabihin ito: kung ang lahat ay nakabitin, nangangahulugan ito na ang mga kamay ng administrator ay hindi lumalaki mula doon. Sa pangkalahatan, ang pagganap ng backup ay nakasalalay sa maraming mga kadahilanan. Halimbawa, sa bilis ng backup system mismo: kung gaano kabilis ang disk storage at tape library. Mula sa pagganap ng mga backup na server ng system: kung mayroon silang oras upang iproseso ang data, magsagawa ng compression at deduplication. At din sa bilis ng mga linya ng komunikasyon sa pagitan ng kliyente at server.
Maaaring pumunta ang backup sa isa o higit pang mga thread, depende sa kung sinusuportahan ng backup system ang multithreading. Halimbawa, pinapayagan ka ng Oracle DBMS na magpadala ng ilang mga thread, ayon sa bilang ng mga available na processor, hanggang sa maabot ng bilis ng paglipat ang limitasyon ng bandwidth ng network.
Kung susubukan mong i-backup ang isang malaking bilang ng mga thread, pagkatapos ay mayroong isang pagkakataon na mag-overload ang tumatakbong sistema, ito ay talagang magsisimulang bumagal. Samakatuwid, ang pinakamainam na bilang ng mga thread ay pinili upang matiyak ang sapat na pagganap. Kung kahit na ang kaunting pagbaba sa pagganap ay kritikal, kung gayon mayroong isang mahusay na pagpipilian kapag ang backup ay isinasagawa hindi mula sa server ng produksyon, ngunit mula sa clone nito - standby sa terminolohiya ng database. Ang prosesong ito ay hindi naglo-load sa pangunahing sistema ng pagtatrabaho. Maaaring makuha ang data sa pamamagitan ng higit pang mga thread dahil hindi ginagamit ang server para sa pagpapanatili.
Sa malalaking organisasyon, ang isang hiwalay na network ay nilikha para sa backup system upang ang backup ay hindi makaapekto sa produksyon. Bilang karagdagan, ang trapiko ay maaaring maipadala hindi sa pamamagitan ng network, ngunit sa pamamagitan ng SAN.
Sinusubukan din naming ipamahagi ang load sa paglipas ng panahon. Ang mga pag-backup ay kadalasang isinasagawa sa mga oras na walang pasok: sa gabi, sa katapusan ng linggo. Gayundin, hindi sila lahat ay nagsisimula sa parehong oras. Ang pag-backup ng virtual machine ay isang espesyal na kaso. Ang proseso ay halos walang epekto sa pagganap ng makina mismo, kaya ang backup ay maaaring ikalat sa buong araw, sa halip na ipagpaliban ang lahat sa gabi. Mayroong maraming mga subtleties, kung isasaalang-alang mo ang lahat, ang backup ay hindi makakaapekto sa pagganap ng system.
Pabula 6. Naglunsad ng backup system - iyon ang pagpapahintulot sa iyo ng kasalanan
Huwag kalimutan na ang backup system ay ang huling linya ng depensa, na nangangahulugan na dapat mayroong limang higit pang mga sistema sa harap nito na nagsisiguro ng pagpapatuloy, mataas na kakayahang magamit at paglaban sa sakuna ng imprastraktura ng IT at mga sistema ng impormasyon ng enterprise.
Walang punto sa pag-asa na ang isang backup ay ibabalik ang lahat ng data at mabilis na maibabalik ang nahulog na serbisyo. Ang pagkawala ng data mula sa sandali ng pag-backup hanggang sa sandali ng pagkabigo ay ginagarantiyahan, at ang data ay maaaring i-upload sa isang bagong server sa loob ng ilang oras (o mga araw, depende sa iyong kapalaran). Samakatuwid, makatuwirang gumawa ng mga ganap na fault-tolerant system nang hindi inililipat ang lahat sa backup.
Pabula 7. Isang beses akong nag-set up ng backup at tiningnan kung gumagana ito. Ang natitira na lang ay tingnan ang mga tala
Ito ay isa sa mga pinaka-nakakapinsalang alamat, ang pekeng kung saan mo lamang napagtanto sa panahon ng insidente. Ang mga log tungkol sa isang matagumpay na pag-backup ay hindi isang garantiya na ang lahat ay talagang napunta gaya ng inaasahan. Mahalagang suriin ang naka-save na kopya nang maaga para sa pag-deploy. Iyon ay, patakbuhin ang proseso ng pagbawi sa isang kapaligiran ng pagsubok at tingnan ang resulta.
At kaunti tungkol sa gawain ng isang system administrator
Walang sinuman ang manu-manong kumopya ng data sa mahabang panahon. Maaaring i-backup ng mga modernong SRC ang halos lahat, kailangan mo lang itong i-configure nang maayos. Kung may naidagdag na bagong server, mag-set up ng mga patakaran: piliin ang content na iba-back up, tukuyin ang mga parameter ng storage, at maglapat ng iskedyul.
Kasabay nito, marami pa ring trabaho dahil sa malawak na fleet ng mga server, kabilang ang mga database, mail system, cluster ng mga virtual machine, at mga mapagkukunan ng file sa parehong Windows at Linux/Unix. Ang mga empleyado na nagpapanatili ng backup system ay hindi nakaupo nang walang ginagawa.
Bilang karangalan sa holiday, nais kong hilingin sa lahat ng mga admin ang malakas na nerbiyos, malinaw na paggalaw at walang katapusang espasyo para sa pag-iimbak ng mga backup!
Pinagmulan: www.habr.com