Рэзервовае капіраванне не адносіцца да модных тэхналогій, аб якіх крычаць з кожнага праса. Яно проста павінна быць у любой сур'ёзнай кампаніі, вось і ўсё. У нас у слоіку бэкапіцца некалькі тысяч сервераў - гэта складаная, цікавая праца, аб некаторых тонкасцях якой, а таксама аб тыповых памылках адносна бэкапаў як раз і жадаецца распавесці.
Гэтай тэматыкай я займаюся ўжо амаль 20 гадоў, з іх апошнія 2 гады - у Прамсувязьбанку. У самым пачатку практыкі рабіў рэзервовае капіраванне практычна ўручную, скрыптамі, якія проста капіявалі файлы. Затым у Windows з'явіліся зручныя прылады: утыліта Robocopy для падрыхтоўкі файлаў і NT Backup для капіявання. А ўжо потым прыйшоў час спецыялізаванага ПЗ, у першую чаргу Veritas Backup Exec, які зараз называецца Symantec Backup Exec. Так што з бэкапамі знаёмы даўно.
Калі па-простаму, рэзервовае капіраванне - гэта захаванне копіі дадзеных (віртуальных машын, прыкладанняў, баз дадзеных і файлаў) на ўсялякі выпадак з пэўнай рэгулярнасцю. Усякі выпадак звычайна выяўляецца ў выглядзе апаратнага ці лагічнага збою і прыводзіць да страты дадзеных. Задача сістэмы рэзервовага капіявання - скараціць страты ад страты інфармацыі. Апаратны збой, гэта, напрыклад, адмова сервера ці сховішчы, дзе ляжыць база дадзеных. Лагічны - гэта страта або змена часткі дадзеных, у тым ліку з-за чалавечага фактару: незнарок выдалілі табліцу, файл, запусцілі на выкананне крывы скрыпт. Ёсць яшчэ і патрабаванні рэгулятара па захоўванні вызначанага тыпу інфармацыі на працягу працяглага перыяду, напрыклад, да некалькіх гадоў.
Самае ж тыповае зварот да бэкапаў - гэта аднаўленне захаванай копіі баз дадзеных для разгортвання розных тэставых сістэм, клонаў для распрацоўшчыкаў.
Вакол рэзервовага капіявання існуе некалькі тыповых міфаў, якія даўно пара развеяць. Вось самыя вядомыя з іх.
Міф 1. Бэкап даўно ўжо ўсяго толькі дробная функцыя ўсярэдзіне сістэм бяспекі ці захоўванні.
Сістэмы рэзервовага капіявання да гэтага часу застаюцца асобным класам рашэнняў, і вельмі незалежным. Занадта ўжо важная справа ім даручана. Па сутнасці, яны з'яўляюцца апошняй лініяй абароны, калі гаворка заходзіць аб захаванасці дадзеных. Так што рэзервовае капіраванне працуе ў сваім рытме, па сваім уласным раскладзе. Па серверах фармуецца штосутачная справаздача, ёсць падзеі, якія выступаюць трыгерамі для сістэмы маніторынгу.
Плюс ролевая мадэль доступу да сістэмы рэзервовага капіявання дазваляе дэлегаваць частку паўнамоцтваў адміністратарам мэтавых сістэм па кіраванні рэзервовымі копіямі.
Міф 2. Калі ёсць RAID, бэкап ужо не патрэбен
Несумненна, RAID-масівы і рэплікаванне дадзеных - гэта добры спосаб абараніць інфармацыйныя сістэмы ад апаратных збояў, а пры наяўнасці standby-сервера - хутка арганізаваць пераключэнне на яго ў выпадку выхаду са строю асноўнай машыны.
Ад лагічных памылак, якія былі дапушчаныя карыстальнікамі сістэмы, надмернасць і рэплікацыя не ратуе. Вось standby-сервер з адкладзеным запісам - так, можа выбавіць, калі памылка выяўлена да таго, як была сінхранізаваная. А калі момант упушчаны? Тут дапаможа толькі своечасова зроблены бэкап. Калі вядома, што дадзеныя змяніліся ўчора, можна аднавіць сістэму па стане на пазаўчора і выцягнуць з яе патрэбныя дадзеныя. З улікам таго, што лагічныя памылкі - самыя частыя, стары добры бэкап застаецца правераным і патрэбным сродкам.
Міф 3. Бэкап - гэта тое, што робіцца раз у месяц.
Частата рэзервовага капіявання - гэта наладжвальны параметр, у першую чаргу які залежыць ад патрабаванняў да сістэмы рэзервовага капіявання. Цалкам рэальна знайсці дадзеныя, якія практычна ніколі не мяняюцца і асабліва не важныя, іх страта не будзе крытычнай для кампаніі.
Іх, сапраўды, можна бэкапіць раз на месяц і нават радзей. А вось больш крытычныя дадзеныя захоўваюцца часцей, у залежнасці ад паказчыка RPO (Recovery point objrective), які задае дапушчальную страту дадзеных. Гэта можа быць раз на тыдзень, раз у суткі ці нават некалькі разоў на гадзіну. У нас гэта часопісы транзакцый з СКБД.
Пры ўвядзенні сістэм у прамысловую эксплуатацыю абавязкова зацвярджаецца дакументацыя па рэзервовым капіяванні, у якой адлюстраваны асноўныя моманты, рэгламент абнаўлення, парадак аднаўлення сістэмы, парадак захоўвання рэзервовых копій і да таго падобнае.
Міф 4. Аб'ём копій няспынна расце і займае любую вылучаную прастору поўнасцю
Рэзервовыя копіі маюць абмежаваны тэрмін захоўвання. Няма сэнсу, напрыклад, складаваць на працягу года ўсе 365 штодзённых бэкапаў. Як правіла дапушчальна захоўваць штодзённыя копіі 2 тыдні, пасля чаго замяшчаюцца свежымі, а на доўгачасовым захоўванні застаецца тая версія, што была зроблена першай у месяцы. Яна, у сваю чаргу, таксама захоўваецца пэўны час - у кожнай копіі ёсць час жыцця.
Існуе абарона ад страты дадзеных. Дзейнічае правіла: перш чым бэкап будзе выдалены, павінен быць сфарміраваны наступны. Таму дадзеныя не выдаляюцца, калі бэкап не выканаўся, напрыклад, з-за недаступнасці сервера. Выконваюцца не толькі часавыя рамкі, але і кантралюецца колькасць дзід у наборы. Калі ў сістэме закладзена, што павінны быць два поўныя бэкапы, іх заўсёды будзе два, і стары выдаліцца толькі тады, калі паспяхова запішацца новы трэці. Так што рост аб'ёму, які займае архівам рэзервовых копій, звязаны толькі з ростам колькасці дадзеных і не залежыць ад часу.
Міф 5. Пачаўся бэкап - усё павісла
Лепш сказаць так: калі ўсё павісла, значыць рукі ў адміністратара не адтуль растуць. Наогул, хуткадзейнасць бэкапу залежыць ад шматлікіх фактараў. Напрыклад, ад хуткадзейнасці самой сістэмы рэзервовага капіявання: наколькі хуткія тамака дыскавыя сховішчы, істужачныя бібліятэкі. Ад хуткадзейнасці сервераў сістэмы рэзервовага капіявання: ці паспяваюць яны апрацоўваць дадзеныя, ажыццяўляць сціск і дэдуплікацыю. А таксама ад хуткасці ліній сувязі паміж кліентам і сэрверам.
Бэкап можа ісці ў адзін або некалькі патокаў, у залежнасці ад таго, ці падтрымлівае ці рэзерваваная сістэма шматструменнасць. Напрыклад, СКБД Oracle дазваляе аддаваць некалькі струменяў, па колькасці даступных працэсараў, пакуль хуткасць перадачы не ўпрэцца ў абмежаванне прапускной здольнасці сеткі.
Калі спрабаваць бэкапіць вялікай колькасцю патокаў, гэта значыць шанец перагрузіць працуючую сістэму, яна сапраўды пачне тармазіць. Таму выбіраецца аптымальны лік струменяў, каб забяспечыць дастатковую хуткадзейнасць. Калі ж крытычна нават найменшае зніжэнне хуткадзейнасці, гэта значыць выдатны варыянт, калі бэкап ажыццяўляецца не з баявога сервера, а з яго клона - standby у тэрміналогіі баз дадзеных. Гэты працэс не загружае асноўную працоўную сістэму. Дадзеныя можна забіраць праз большую колькасць плыняў, бо сервер не выкарыстоўваецца для абслугоўвання.
У буйных арганізацыях для сістэмы рэзервовага капіявання ствараецца асобная сетка, каб бэкап не ўплываў на прад. Акрамя таго, трафік можа перадавацца не праз сетку, а праз SAN.
Мы стараемся размяркоўваць нагрузку яшчэ і па часе. Бэкапы пераважна ідуць у непрацоўны час: уначы, у выходныя. Акрамя таго, яны не запускаюцца ўсё адначасова. Бэкапы віртуальных машын - гэта асаблівы выпадак. Працэс практычна не ўплывае на прадукцыйнасць самой машыны, таму бэкап можна размазаць па дзённым часе, а не адкладаць усё на ноч. Тонкасцяў шмат, калі ўсё ўлічыць, рэзервовае капіраванне не адаб'ецца на прадукцыйнасці сістэм.
Міф 6. Запусціў сістэму рэзервовага капіявання - вось табе і адмоваўстойлівасць
Ніколі не забывайце, што сістэма бэкапу - гэта апошняя лінія абароны, а значыць перад ёй павінна быць яшчэ пятак сістэм, якія забяспечваюць бесперапыннасць, высокую даступнасць і катастрофаўстойлівасць ІТ-інфраструктуры і інфармацыйных сістэм прадпрыемства.
Спадзявацца, што бэкап адновіць усе дадзеныя і хутка падніме які ўпаў сэрвіс не варта. Страта дадзеных з моманту бэкапу да моманту паломкі гарантаваная, а дадзеныя на новы сервер могуць залівацца некалькі гадзін (ці дзён, як павязе). Таму мае сэнс ствараць паўнавартасныя адмоваўстойлівыя сістэмы, не перакладаючы ўсё на бэкап.
Міф 7. Наладзіў адзін раз бэкап, праверыў што працуе. Застаецца толькі логі глядзець
Гэта адзін з самых шкодных міфаў, фэйкавага якога ўсведамляеш толькі падчас інцыдэнту. Логі аб паспяховым здзяйсненні бэкапу - гэта не гарантыя, што ўсё сапраўды прайшло як трэба. Захаваную копію важна загадзя праверыць на разгортвальнасць. Гэта значыць запусціць працэс аднаўлення ў тэставым асяроддзі і паглядзець на вынік.
І крыху пра працу сісадміна
У ручным рэжыме ніхто дадзеныя ўжо даўно не капіруе. Сучасныя СРК умеюць бэкапіць практычна ўсё, варта толькі як след яго наладзіць. Калі дадаўся новы сервер - прапісаць палітыкі: выбраць кантэнт, які будзе бэкапіцца, пазначыць параметры захоўвання, і прымяніць расклад.
Пры гэтым працы ўсё роўна нямала з-за шырокага парка сервераў, сярод якіх і базы дадзеных, і паштовыя сістэмы, і кластары віртуальных машын, і файлавыя рэсурсы як на Windows, так на Linux/Unix. Супрацоўнікі, якія падтрымліваюць працаздольнасць сістэмы рэзервовага капіявання, без справы не сядзяць.
У гонар свята жадаецца пажадаць усім адмінам дужых нерваў, выразнасці рухаў і бясконцай прасторы пад захоўванне бэкапаў!
Крыніца: habr.com