Вітаю чытачоў нашага блога! Збольшага мы ўжо знаёмыя - мае англамоўныя пасты з'яўляліся тут у перакладзе маёй дарагі калегі. . На гэты раз я вырашыў звярнуцца да рускамоўнай аўдыторыі напрамую.
Для свайго дэбюту мне хацелася знайсці тэму, цікавую для максімальна шырокай аўдыторыі і якая патрабуе дэталёвага разгляду. Даніэль Дэфо сцвярджаў, што любога чалавека чакаюць смерць і падаткі. Са свайго боку магу сказаць, што любога інжынера падтрымкі чакаюць пытанні па палітыках захоўвання кропак аднаўлення (ці калі прасцей - ретеншену). Як працуе рэтэншэн, я пачаў тлумачыць 4 гады таму, быўшы малодшым інжынерам першага ўзроўню, працягваю тлумачыць і цяпер, ужо з'яўляючыся тым лідэрам іспана-і італамоўнай каманды. Упэўнены, што мае калегі з другога і нават трэцяга ўзроўню падтрымкі таксама рэгулярна адказваюць на тыя ж пытанні.
У гэтым свеце мне захацелася напісаць канчатковы, максімальна падрабязны пост, да якога рускамоўныя карыстачы маглі б вяртацца зноў і зноў як да даведніка. Момант прыдатны - нядаўна выпушчаная юбілейная дзесятая версія дадала новыя магчымасці да базавага функцыяналу, які не мяняўся гадамі. Мой пост арыентаваны перш за ўсё на гэтую версію - хоць большая частка напісанага дакладная і для папярэдніх версій, сёе-тое з апісанага функцыяналу вы там папросту не знойдзеце. Нарэшце, зазіраючы крыху ў будучыню, скажу што ў наступнай версіі чакаюцца некаторыя змены, але пра гэта мы раскажам калі прыйдзе час. Такім чынам, прыступім.
Заданні рэзервовага капіявання (Backup job)
Для пачатку разбяром тую частку, якая не зведала змен у версіі 10. Палітыка рэтэншэна вызначаецца некалькімі параметрамі. Адкрыем акно стварэння новага задання і пяройдзем на ўкладку Storage. Тут мы ўбачым параметр, які вызначае жаданую колькасць кропак аднаўлення:
Аднак, гэта толькі частка раўнання. Рэальная колькасць кропак вызначаецца таксама рэжымам бэкапу, усталяваным для задання. Для выбару гэтага параметра трэба клікнуць па кнопцы Advanced на той жа ўкладцы. Гэта адкрые новае акно са мноствам опцый. Пранумаруем іх і разгледзім па чарзе:
Калі ўключыць толькі опцыю 1, то заданне будзе працаваць у "бясконца інкрыментальным" рэжыме (forever forward incremental). Тут ніякіх складанасцяў не ўзнікае - заданне будзе захоўваць усталяваную колькасць кропак аднаўлення ад поўнага бэкапу (файл з пашырэннем VBK) да апошняга інкремента (файл з пашырэннем VIB). Калі колькасць кропак перавысіць усталяванае значэнне, самы стары інкрымент будзе аб'яднаны з поўным бэкапам. Іншымі словамі, калі заданне ўсталявана захоўваць 3 кропкі, то адразу пасля чарговай сесіі на рэпазітары будзе 4 кропкі, пасля чаго поўны бэкап будзе аб'яднаны са самым старым інкрэмэнтам і агульная колькасць кропак вернецца да 3.
Таксама лімітава просты рэтэншэн для «зваротна-інрэментальнага» (reverse incremental) рэжыму (опцыя 2). Паколькі ў гэтым выпадку самая новая кропка будзе поўным бэкапам, за якім будзе цягнуцца ланцужок так званых ролбэкаў (файлы з пашырэннем VRB), то для ўжывання рэтэншэна досыць проста выдаліць самы стары ролбэк. Сітуацыя будзе такой жа: адразу пасля сесіі колькасць кропак перавысіць устаноўленую на 1, пасля чаго вернецца да патрэбнага значэння.
Улічыце, што з зваротна-інкрыментальным рэжымам можна таксама ўключыць перыядычны поўны бэкап (опцыя 4), але сутнасці гэта не памяняе. Так, у ланцужку з'явяцца поўныя кропкі аднаўлення, але мы ўсё гэтак жа будзем проста выдаляць самыя старыя кропкі па адной.
Нарэшце, мы падыходзім да цікавай часткі. Калі актываваць інкрыментальны бэкап, але ў дадатак уключыць опцыі 3 ці 4 (а можна і абедзве адначасова), заданне пачне ствараць перыядычныя поўныя бэкапы «актыўным» або сінтэтычным метадам. Метад стварэння поўнага бэкапу не важны - ён будзе змяшчаць тыя ж дадзеныя, а інкрыментальны ланцужок будзе падзелена на «подцепочки». Такі метад называецца forward incremental, і менавіта ён выклікае значную частку пытанняў у нашых кліентаў.
Ретеншен тут ужываецца выдаленнем самай старой часткі ланцужка (ад поўнага бэкапу да інкремента). Пры гэтым мы не будзем выдаляць толькі полы бэкап ці толькі частку інкрэмэнтаў. Увесь «подцепочка» выдаляецца цалкам за раз. Змяняецца і сэнс налады колькасці кропак – калі ў іншых метадах гэта максімальна дапушчальная колькасць, пасля якога трэба ўжываць рэтэншэн, то тут гэтая настройка вызначае мінімальную колькасць. Іншымі словамі, пасля выдалення самай старой «подцепочки», колькасць кропак у пакінутай частцы не павінна зваліцца ніжэй за гэты мінімум.
Паспрабую адлюстраваць гэтую канцэпцыю графічна. Дапушчальны, рэтэншэн выстаўлены на 3 кропкі, заданне працуе кожны дзень з поўным бэкапам у панядзелак. Ретеншен у такім выпадку будзе ўжыты, калі агульная колькасць кропак дасягне 10:
Чаму ажно 10, калі выставілі 3? У панядзелак быў створаны поўны бэкап. З аўторка па нядзелю заданне стварала інкрэменты. Нарэшце, у наступны панядзелак ізноў ствараецца поўны бэкап і толькі калі будуць створаныя 2 інкрэмэнты нарэшце ўся старая частка ланцужка можа быць выдаленая, таму што пакінутая колькасць кропак не ўпадзе ніжэй усталяваных 3.
Калі ідэя зразумелая, то прапаную вам паспрабаваць палічыць рэтэншэн самастойна. Возьмем такія ўмовы: заданне запускаецца першы раз у чацвер (натуральна, будзе зроблены поўны бэкап). Заданне выстаўлена ствараць поўны бэкап па серадах і нядзелях і захоўваць 8 кропак аднаўлення. Калі рэтэншэн будзе ўжыты ў першы раз?
Для адказу на гэтае пытанне я рэкамендую вам узяць ліст паперы, разчарціць яго па днях тыдня і напісаць, якая кропка ствараецца кожны дзень. Адказ стане відавочным
Адказ
Тлумачэнне: для адказу дастаткова спытаць сябе «калі будзе ўжыты рэтэншэн»? Адказ – калі мы зможам выдаліць 3 першыя кропкі (VBK, VIB, VIB) і астатні ланцужок не ўпадзе ніжэй за належныя 8 кропак. Становіцца зразумела, што мы зможам гэта зрабіць, калі ў нас будзе 11 кропак у суме, т. е. у нядзелю другога тыдня.
Некаторыя чытачы могуць запярэчыць: «навошта ўсё гэта, калі ёсць ?». Без сумневу, гэта вельмі карысная прылада, і ў некаторых выпадках я бы ўжываў менавіта яго, але ёсць у яго і абмежаванні. Першым чынам, ён не дазваляе паказаць пачатковыя ўмовы, а ў шматлікіх выпадках выпадкаў пытанне гучыць менавіта "у нас ёсць такі ланцужок, што будзе, калі змяніць вось такія налады?". Па-другое, прыладзе ўсёткі некалькі бракуе навочнасці. Паказваючы старонку RPS кліентам, я не знаходзіў разуменні, а вось распісаўшы яе як у прыкладзе (нават выкарыстоўваючы той жа Paint), дзень за днём, усё рабілася ясна.
Нарэшце, мы не разгледзелі опцыю "Transform previous backup chains into rollbacks" (адзначана лічбай 5). Гэтая опцыя часам бянтэжыць кліентаў, якія актывуюць яе "на аўтамаце", жадаючы ўключыць проста сінтэтычны бэкап. Між тым, гэтая опцыя актывуе зусім асаблівы рэжым бэкапу. Не ўдаючыся ў падрабязнасці, адразу скажу, што на дадзеным этапе развіцця прадукта "Transform previous backup chains into rollbacks" - опцыя састарэлая, і я не магу прыдумаць ніводнага сцэнара, калі б яе трэба было выкарыстоўваць. Яе каштоўнасць настолькі сумнеўная, што некаторы час сам Антон Госцеў кінуў кліч праз форум, просячы даслаць яму прыклады яе карыснага выкарыстання (калі ў вас яны ёсць, напішыце ў каментарах, мне вельмі цікава). Калі такіх не знойдзецца (я думаю, так і будзе), то опцыю выдаляць у наступных версіях.
Заданне будзе ствараць інкрэменты (VIB) да дня, калі прызначаны сінтэтычны поўны бэкап. У гэты дзень сапраўды ствараецца VBK, але вось усе кропкі да гэтага VBK трансфармуюцца ў ролбэкі (VRB). Пасля гэтага заданне працягне ствараць інкрэменты да поўнага бэкапу да наступнага сінтэтычнага бэкапу. У выніку ў ланцужку ствараецца грымучая сумесь з VBK, VBR і VIB файлаў. Ретеншен жа ўжываецца вельмі проста выдаленнем апошняга VBR:
Праблемы
Апроч уласна разумення як гэта працуе, большасць праблем, якія ўзнікаюць пры выкарыстанні інкрыментальнага рэжыму, звычайна злучаны з поўным бэкапам. Рэгулярны поўны бэкап неабходны гэтаму рэжыму, інакш рэпазітар будзе збіраць кропкі, пакуль не перапоўніцца.
Напрыклад, поўны бэкап можа стварацца занадта рэдка. Скажам, заданне выстаўлена захоўваць 10 кропак, а поўны бэкап ствараецца раз у месяц. Зразумела, што фактычная колькасць кропак тут будзе значна большая за выстаўленую. Або заданне наогул выстаўлена працаваць у бясконца-інкрыментальным рэжыме і захоўваць 50 кропак. Затым нехта выпадкова стварыў поўны бэкап. Усё, з гэтага часу заданне будзе чакаць, пакуль поўная кропка назапасіць 49 інкрементаў, пасля чаго прыменіць рэтэншэн і вернецца ў бясконца-поўны рэжым.
У іншых выпадках поўны бэкап выстаўлены стварацца рэгулярна, але з нейкай прычыны гэтага не робіць. Распішу тут самы папулярны чыннік. Некаторыя кліенты аддаюць перавагу выкарыстоўваць опцыю раскладу "run after" і наладжваць заданні працаваць у ланцужку. Возьмем такі прыклад: ёсць 3 заданні, якія працуюць кожны дзень і ствараюць поўны бэкап у нядзелю. Першае заданне запускаецца ў 22.30, астатнія запускаюцца па ланцужку. Інкрыментальны бэкап займае 10 хвілін, і таму да 23.00 усе заданні заканчваюць працу. А вось поўны бэкап займае гадзіну, таму ў нядзелю адбываецца наступнае: першае заданне працуе з 22.30 да 23.30. Наступнае з 23.30 да 00.30. А вось трэцяе заданне запускаецца ўжо ў панядзелак. Поўны бэкап настроены на нядзелю, таму ў такім выпадку яго проста не будзе. Заданне ж будзе чакаць поўны бэкап, каб прымяніць рэтэншэн. Таму будзьце ўважлівыя пры выкарыстанні опцыі "run after" ці не выкарыстоўвайце яе наогул - проста выстаўце заданні стартаваць у адзін час і дазвольце планавальніку рэсурсаў зрабіць сваю працу.
Няпростая опцыя "Remove deleted items"
Прайшоўшы па наладах задання Storage - Advanced - Maintenance, можна натыкнуцца на опцыю "remove deleted items data after", якая вылічаецца днямі.
Некаторыя кліенты чакаюць, што гэта і ёсць рэтэншэн. Насамрэч, гэта зусім асобная опцыя, неразуменне якой можа прывесці да нечаканых наступстваў. Аднак, першым чынам трэба растлумачыць, як B&R рэагуе на сітуацыі, калі за час сесіі паспяхова бэкапяцца толькі некалькі машын.
Прадстаўляльны такі сцэнар: бясконца-інкрыментальнае заданне, наладжанае захоўваць 6 кропак. У заданні 2 машыны, адна заўсёды бэкапілася паспяхова, іншая часам давала памылкі. У выніку да сёмай кропкі склалася такая сітуацыя:
Час ужываць рэтэншэн, але ў адной машыны 7 кропак, а ў другой толькі 4. Ці будзе тут ужыты рэтэншэн? Адказ - так, будзе. Калі хоць адзін аб'ект быў забэкаплены, B&R лічыць, што кропка створана.
Аналагічная сітуацыя можа скласціся, калі нейкая машына проста не была ўключана ў заданне падчас пэўнай сесіі. Такое бывае, напрыклад, калі машыны дададзены ў заданне не індывідуальна, а ў складзе кантэйнераў (тэчкі, сховішчы) і нейкая машына часова мігруе ў іншы кантэйнер. Заданне ў такім выпадку будзе лічыцца паспяховым, але ў статыстыцы вы знойдзеце паведамленне, якое заклікае звярнуць увагу, што вось такая машына больш не апрацоўваецца заданнем.
Што ж будзе, калі не зважаць на гэта? У выпадку з бясконца-інкрыментальным або зваротна-інкрыментальным рэжымамі колькасць кропак аднаўлення праблемнай машыны будзе меншаць з кожнай сесіяй, пакуль не дасягне 1, захаванай у VBK. Іншымі словамі, нават калі машына не будзе бэкапіцца доўгі час, адна кропка аднаўлення ўсё ж застанецца. Справа ідзе іншым чынам, калі ўключаны перыядычныя поўныя бэкапы. Калі ігнараваць сігналы ад B&R, у выніку апошняя кропка можа быць выдаленая разам са старой часткай ланцужкі.
Уразумеўшы гэтыя дэталі, нарэшце можна разгледзець опцыю "Remove deleted items data after". Яна выдаліць усе кропкі для вызначанай машыны, калі гэтая машына не бэкпіцца на працягу X дзён. Звярніце ўвагу, што на памылкі (паспрабавалі - не атрымалася) гэтая настройка не рэагуе. Не павінна быць нават спробы бэкапу машыны. Здавалася б, опцыя карысная і яе заўсёды трэба трымаць уключанай. Калі адміністратар выдаліў машыну з задання, то лагічна праз некаторы час ачысціць ад непатрэбных дадзеных і ланцужок. Аднак, настройка патрабуе дысцыпліны і ўважлівасці.
Прывяду прыклад з практыкі: у заданне былі дададзены некалькі кантэйнераў, склад якіх быў даволі дынамічным. З-за адсутнасці АЗП B&R сервер адчуваў праблемы, якія заставаліся незаўважанымі. Заданне запусцілася і паспрабавала зрабіць бэкап машын, акрамя адной, якая на той момант не прысутнічала ў кантэйнеры. Паколькі шматлікія машыны выдалі памылкі, па змаўчанні B&R павінен выканаць 3 дадатковыя спробы зрабіць бэкап праблемных машын. З-за пастаянных праблем з АЗП, гэтыя спробы расцягнуліся на некалькі дзён. Паўторнай спробы зрабіць бэкап адсутнай ВМ не было (адсутнасць ВМ - гэта не памылка). У выніку, падчас адной з паўторных спроб было выканана ўмова "Remove deleted items" і ўсе кропкі машыны былі выдаленыя.
З гэтай нагоды магу сказаць наступнае: калі ў вас настроены абвесткі аб выніках заданняў, а яшчэ лепш - выкарыстоўваецца інтэграцыя з Veeam ONE, то хутчэй за ўсё такога з вамі не адбудзецца. Калі ж вы зазіраеце на B&R сервер раз у тыдзень, праверыць, што ўсё працуе, то ад опцый, якія патэнцыйна могуць прывесці да выдалення бэкапаў, лепш адмовіцца.
Што дадалося ў v.10
Тое, пра што мы казалі да гэтага, існавала ў B&R на працягу шматлікіх версій. Уразумеўшы гэтыя прынцыпы працы, давайце зараз паглядзім, што дадалося ў юбілейнай «дзясятачцы».
Daily retention
Вышэй мы разглядалі "класічную" палітыку захоўвання, заснаваную на колькасці кропак. Альтэрнатыўны падыход - выставіць у тым жа меню "days" замест "restore points".
Ідэя ясная з назвы – рэтэншэн будзе захоўваць устаноўленую колькасць дзён, колькасць жа кропак у кожным дні не мае значэння. Пры гэтым трэба памятаць наступнае:
- Бягучы дзень не ўлічваецца пры разліку рэтэншэна
- Дні, калі заданне не працавала зусім, таксама лічацца. Гэта трэба мець на ўвазе, каб выпадкова не страціць кропкі тых заданняў, якія працуюць нерэгулярна.
- Кропка аднаўлення лічыцца ад таго дня, калі пачалося яе стварэнне (г.зн. калі заданне пачало працаваць у панядзелак, а скончыла ў аўторак, то гэта кропка ад панядзелка)
У астатнім прынцыпы ўжывання ретеншена заданнямі ўсё таксама вызначаюцца абраным метадам бэкапу. Давайце паспрабуем яшчэ адно заданне на разлік, выкарыстоўваючы ўсё той жа інкрыментальны метад. Скажам, рэтэншэн выстаўлены на 8 дзён, заданне працуе кожныя 6 гадзін з поўным бэкапам у сераду. Пры гэтым заданне не працуе ў нядзелю. Заданне запускаецца ў панядзелак першы раз. Калі будзе ўжыты рэтэншэн?
Адказ
Як звычайна, лепш за ўсё намаляваць таблічку. Я дазволю сабе спрасціць задачу і не буду маляваць усе кропкі, створаныя за кожны дзень, бо колькасць кропак у дзень тут не гуляе значэння. Нам важна толькі, што ў першы панядзелак і па серадах першая кропка будзе поўным бэкапам, у астатнія ж дні заданне проста будзе ствараць 4 інкрыментальныя кропкі.
Уясняем сабе, што ретеншен будзе ўжыты выдаленнем панядзелкавага поўнага бэкапу і яго інкрэмента. Калі гэта адбудзецца? Калі астатняя частка ланцужка будзе змяшчаць 8 дзён. Пры гэтым мы не лічым бягучы дзень, а вось нядзелю, наадварот, лічым. Таму адказ - у чацвер другога тыдня.
Архіваванне метадам GFS для звычайных заданняў
Да v.10 метад захоўвання Grandfather-Father-Son (GFS) быў даступны толькі для заданняў стварэння архіўных дзід (Backup copy) і заданняў капіявання на магнітную стужку. Цяпер жа ён даступны і для звычайнага бэкапу.
Хоць гэта не адносіцца да бягучай тэмы, не магу не сказаць, што новы функцыянал не азначае адыходу ад стратэгіі 3-2-1. Прысутнасць архіўных кропак у асноўным рэпазітары ніяк не ўплывае на яго надзейнасць. Мяркуецца, што GFS будзе выкарыстаны разам з які пашыраецца (Scale-out) рэпазітаром, для адгрузкі гэтых кропак у S3 і ім падобныя сховішчы. Калі вы ім не карыстаецеся, то лепш працягваць захоўваць першасныя і архіўныя кропкі на розных рэпазітарах.
Цяпер разгледзім прынцыпы стварэння GFS кропак. У наладах задання, на кроку Storage, з'явілася спецыяльная кнопка, якая выклікае наступнае меню:
Сутнасць GFS можна звесці да некалькіх пунктаў (звярніце ўвагу, GFS у іншых відах заданняў працуе па-іншаму, але пра гэта крыху пазней):
- Заданне не стварае асобны поўны бэкап пад GFS кропку. Замест гэтага будзе выкарыстаны найбольш прыдатны поўны бэкап з наяўных. Таму заданне павінна працаваць у інкрыментальным рэжыме з перыядычным поўным бэкапам, ці ж поўны бэкап павінен стварацца карыстачом уручную.
- Калі ўключаны толькі адзін перыяд (напрыклад, тыднёвы), то ў пачатку GFS перыяду заданне проста пачне чакаць поўны бэкап і адзначыць першы прыдатны як GFS.
Прыклад: заданне настроена захоўваць тыднёвы GFS, выкарыстоўваючы бэкап у сераду. Заданне працуе кожны дзень, але поўны бэкап прызначаны на пятніцу. У гэтым выпадку ў сераду пачнецца GFS перыяд і заданне пачне чакаць прыдатную кропку. Яна з'явіцца ў пятніцу і будзе адзначана флагам GFS.
- Калі ўключаны адразу некалькі перыядаў (напрыклад, тыднёвы і месячны), то B&R будзе ўжываць метад, які дазваляе выкарыстоўваць адну і тую ж кропку як GFS некалькіх інтэрвалаў (для эканоміі месца). Флагі будуць назначаны па чарзе, пачынаючы з малодшага.
Прыклад: тыднёвы GFS выстаўлены на сераду, а месячны - на апошні тыдзень месяца. Заданне працуе кожны дзень і стварае поўныя бэкапы па панядзелках і пятніцах.
Для прастаты пачнем адлік з перадапошняга тыдня месяца. У гэты тыдзень будзе створаны поўны бэкап у панядзелак, але ён будзе праігнараваны, таму што тыднёвы GFS інтэрвал пачынаецца ў сераду. Затое пятнічны поўны бэкап цалкам падыходзіць для GFS кропкі. Гэтая сістэма нам ужо знаёмая.
Цяпер разгледзім, што адбудзецца ў апошні тыдзень месяца. Месячны GFS інтэрвал пачнецца ў панядзелак, але панядзелкавы VBK не будзе пазначаны як GFS, таму што заданне імкнецца пазначыць адзін VBK і як месячную, і як тыднёвую GFS кропку. Пры гэтым пачынаецца пошук менавіта з тыднёвай, таму яна ж па азначэнні зможа стаць і месячнай.
Пры гэтым калі ўключыць толькі тыднёвы і гадавы інтэрвалы, то яны будуць дзейнічаць незалежна сябар ад сябра і могуць адзначыць 2 асобных VBK як адпаведныя GFS інтэрвалы.
Заданні стварэння архіўнай копіі (Backup copy)
Яшчэ адзін тып заданняў, часта які патрабуе тлумачэнняў па працы. Для пачатку разбяром «класічны» метад працы, без новаўвядзенняў v.10
Просты метад рэтэншэна
Па змаўчанні такія заданні працуюць у бясконца-інкрыментальным рэжыме. Стварэнне кропак вызначаецца двума параметрамі - інтэрвалам капіявання і жаданай колькасцю кропак аднаўлення (рэтэншэна па днях тут няма). Інтэрвал капіявання выстаўляецца на першай жа ўкладцы Job пры стварэнні задання:
Колькасць кропак жа вызначаецца крыху далей на ўкладцы Target
Заданне стварае 1 новую кропку за кожны інтэрвал (колькі кропак было створана для ВМ зыходнымі заданнямі, значэння не мае). Пад канец інтэрвалу новая кропка фіналізуецца і, калі гэта неабходна, ужываецца ретеншен шляхам аб'яднання VBK і самага старога інкрэмента. Гэты механізм нам ужо знаёмы.
Метад рэтэншэна з выкарыстаннем GFS
BCJ таксама ўмее захоўваць архіўныя кропкі. Наладжваецца гэта на той жа ўкладцы Target, крыху ніжэй налады колькасці кропак аднаўлення:
GFS кропкі могуць стварацца двума спосабамі – сінтэтычна, выкарыстоўваючы дадзеныя на другасным рэпазітары, ці ж імітуючы поўны бэкап і счытваючы ўсе дадзеныя з першаснага рэпазітара (актывуецца опцыяй, адзначанай лічбай 3). Ретеншен у абодвух выпадках будзе моцна адрознівацца, таму разгледзім іх асобна.
Сінтэтычны GFS
У гэтым выпадку GFS кропка не ствараецца сапраўды ў прызначаны дзень. Замест гэтага, GFS кропка будзе створана, калі VIB таго дня, на які было прызначанае стварэнне GFS кропкі, будзе аб'яднаны з поўным бэкапам. Гэта часам выклікае недастатковае разуменне, бо час ідзе, а GFS кропкі ўсё няма. І толькі магутны шаман з тэхпадтрымкі можа прадказаць, у які дзень кропка ўсё ж такі з'явіцца. На самай справе магія не патрэбна - дастаткова паглядзець на выстаўленыя колькасць кропак і інтэрвал сінхранізацыі (колькі кропак ствараецца кожны дзень). Паспрабуйце падлічыць самі на такім прыкладзе: заданне выстаўлена захоўваць 7 кропак, інтэрвал сінхранізацыі - 12 гадзін (т. е. 2 кропкі ў дзень). На дадзены момант у ланцужку ўжо 7 кропак, сёння панядзелак, і на гэты дзень прызначанае стварэнне GFS кропкі. У які дзень яна будзе створана?
Адказ
Тут лепш распісаць, як ланцужок будзе мяняцца ў дынаміцы, па днях:
Такім чынам, у панядзелак апошні інкрымент у ланцужку пазначаецца як GFS, але ніякіх іншых бачных змен не адбываецца. Кожны дзень заданне стварае 2 новыя кропкі, і рэтэншэн няўмольна рухае ланцужок наперад. Нарэшце, у чацвер прыходзіць час прымяняць рэтэншэн да таго самага інкрыменту. Гэтая сесія зойме больш часу, чым звычайна - таму што заданне "вымае" патрэбныя блокі з ланцужка і створыць новую поўную кропку. З гэтага моманту ў ланцужку будзе ўжо 8 кропак - 7 у асноўны ланцужку + GFS.
Стварэнне GFS кропак з опцыяй "Read entire point"
Вышэй я сказаў, што BCJ працуе ў бясконца-інкрыментальным рэжыме. Цяпер мы разбяром адзінае выключэнне з гэтага правіла. Пры ўключэнні опцыі "Read entire point" GFS кропка будзе створана роўна ў запланаваны дзень. Само ж заданне будзе працаваць у інкрыментальным рэжыме з перыядычнымі поўнымі бэкапамі, які мы разбіралі вышэй. Ретеншен таксама будзе прымяняцца выдаленнем самай старой часткі ланцужка. Аднак у дадзеным выпадку будуць выдаленыя толькі інкрэменты, а поўны бэкап будзе пакінуты як GFS кропка. Адпаведна, пры разліку рэтэншэна не ўлічваюцца кропкі, адзначаныя GFS сцягамі.
Дапушчальны, заданне выстаўлена захоўваць 7 кропак і ствараць тыднёвую GFS кропку ў панядзелак. У гэтым выпадку кожны панядзелак заданне сапраўды будзе ствараць поўны бэкап і пазначаць яго як GFS. Ретеншен будзе ўжыты, калі пасля выдалення інкрэмэнтаў з самай старой часткі, колькасць пакінутых інкрымэнтаў не зваліцца ніжэй 7. Вось як гэта выглядае на схеме:
Такім чынам, да канца другога тыдня ў ланцужку ў суме 14 кропак. На працягу другога тыдня заданне стварыла 7 кропак. Будзь гэта простае заданне, ретеншен быў бы ўжо ўжыты. Але гэта BCJ з GFS рэтэншэнам, таму GFS кропкі мы не лічым, а, значыць, іх толькі 6. Гэта значыць ретеншен мы яшчэ ўжыць не можам. На трэцім тыдні мы ствараем яшчэ адзін поўны бэкап з GFS сцягам. 15 кропак, але гэтую мы зноў не лічым. І, нарэшце, у аўторак трэцяга тыдня мы ствараем інкрымент. Цяпер, калі мы выдалім інкрэменты ланцужка першага тыдня, агульная колькасць інкраментаў задаволіць усталяванаму рэтэншэну.
Як ужо гаварылася вышэй, у дадзеным метадзе вельмі важна, каб поўныя бэкапы ствараліся рэгулярна. Скажам, калі выставіць асноўны рэтэншэн на 7 дзён, але толькі 1 гадавую кропку, нескладана ўявіць, што інкрэмэнтаў назапасіцца моцна, моцна больш, чым 7. У такіх выпадках лепш выкарыстоўваць сінтэтычны метад стварэння GFS.
І зноў “Remove deleted items”
Гэтая опцыя таксама прысутнічае і для BCJ:
Логіка гэтай опцыі тут такая ж, як і ў звычайных заданні бэкапу - калі машына не апрацоўваецца паказанае колькасць дзён, то яе дадзеныя выдаляюцца з ланцужка. Аднак, для BCJ карыснасць гэтай опцыі аб'ектыўна вышэйшая, і вось чаму.
У звычайным рэжыме BCJ працуе ў бясконца-інкрыментальным рэжыме, таму калі ў нейкі момант машына выдаляецца з задання, то ретеншен паступова выдаліць усе кропкі аднаўлення, пакуль не застанецца адна-адзіная у VBK. Цяпер уявім, што заданне яшчэ наладжана ствараць сінтэтычныя GFS кропкі. Калі прыйдзе час, заданне павінна будзе стварыць GFS для ўсіх машын у ланцужку. Калі ў нейкай машыны зусім няма новых кропак ну што ж, прыйдзецца выкарыстаць тую, што ёсць. І так кожны раз. У выніку можа скласціся такая сітуацыя:
Звярніце ўвагу на секцыю Files: у нас ёсць асноўны VBK і 2 тыднёвыя GFS кропкі. А зараз на секцыю Restore points па факце ў гэтых файлах ляжыць адна і тая ж выява машыны. Натуральна, ніякага сэнсу ў такіх GFS кропках няма, яны толькі займаюць месца.
Такая сітуацыя магчыма толькі пры выкарыстанні сінтэтычнага GFS. Каб гэтага не дапусціць, выкарыстоўвайце опцыю "Remove deleted items". Толькі не забудзьцеся выставіць яе на адэкватную колькасць дзён. Тэхпадтрымка бачыла выпадкі, калі опцыю выстаўлялі на меншую колькасць дзён, чым інтэрвал сінхранізацыі - BCJ пачынала бушаваць і выдаляць кропкі, не паспеўшы іх стварыць.
Улічыце таксама, што гэтая опцыя не чапае ўжо створаныя GFS кропкі. Калі вы жадаеце пачысціць архівы, зрабіць гэта трэба ўручную - клікнуўшы правай кнопкай па машыне і абраўшы "Delete from disk" (у якое з'явілася акне не забудзьцеся выставіць галачку "Remove GFS full backup"):
Новаўвядзенне v.10 - неадкладная копія (immediate copy)
Разабраўшыся з "класічным" функцыяналам, пяройдзем да новага. Новаўвядзенне адно, але вельмі важнае. Гэта - новы рэжым працы.
Тут няма такога паняцця, як "інтэрвал сінхранізацыі", заданне будзе пастаянна сачыць, ці не з'явіліся новыя кропкі, і капіяваць іх усіх, колькі б іх ні было. Але пры гэтым заданне застаецца інкрыментальным, гэта значыць нават калі асноўнае заданне стварае VBK ці VRB, гэтыя кропкі будуць скапіяваныя як VIB. У астатнім у гэтым рэжыме няма ніякіх сюрпрызаў - як стандартны, так і GFS рэтэншэн працуюць па правілах, апісаным вышэй (праўда, тут даступны толькі сінтэтычны GFS).
Круцяцца дыскі. Асаблівасці рэпазітараў з ратацыяй дыскаў (rotated drives)
Пастаянная пагроза вірусаў-шыфравальшчыкаў зрабіла дэ-факта стандартам бяспекі наяўнасць копіі даных на носьбіце, куды вірус дабрацца не можа. Адзін з варыянтаў - гэта выкарыстанне рэпазітараў з ратацыяй дыскаў, калі дыскі выкарыстоўваюцца па чарзе: у той час як адзін дыск падлучаны і даступны для запісу, астатнія захоўваюцца ў бяспечным месцы.
Каб навучыць B&R працаваць з такімі рэпазітарамі, неабходна ў наладах рэпазітара, на кроку Repository, клінуць па кнопцы Advanced і абраць адпаведную опцыю:
Пасля гэтага VBR будзе чакаць, што перыядычна існуючы ланцужок будзе знікаць з рэпазітара, што азначае ратацыю дыска. У залежнасці ад тыпу рэпазітара і выгляду задання, B&R будзе паводзіць сябе па-рознаму. Уявіць гэта можна вось такой табліцай:
Разгледзім кожны варыянт.
Звычайнае заданне і Windows рэпазітар
Такім чынам, у нас ёсць заданне, якое захоўвае ланцужкі на першы дыск. Пры ратацыі створаны ланцужок фактычна знікае, і заданню трэба неяк перажыць гэтую страту. Суцяшэнне яно знаходзіць у стварэнні поўнага бекапа. Такім чынам, кожная ратацыя азначае поўны бэкап. Але што адбываецца з кропкамі на адключанай кружэлцы? Яны запамінаюцца і ўлічваюцца пры праліку рэтэншэна. Такім чынам, выстаўленая колькасць кропак у заданні - гэта тое, колькі кропак неабходна трымаць на ўсіх дысках. Прывядзем прыклад:
Заданне працуе ў бясконца-інкрыментальным рэжыме і настроена захоўваць 3 кропкі аднаўлення. Але ў нас ёсць яшчэ другі дыск, і мы раз на тыдзень праводзім ратацыю (дыскаў можа быць і больш, гэта сутнасці не мяняе).
У першы тыдзень заданне будзе ствараць кропкі на першай кружэлцы і аб'ядноўваць лішнія. Такім чынам, агульная колькасць кропак будзе роўна тром:
Затым мы падлучаем другую кружэлку. Пры запуску B&R заўважыць, што дыск змяніўся. Ланцужок на першай кружэлцы знікне з інтэрфейсу, але інфармацыя пра яе застанецца ў базе. Цяпер заданне будзе трымаць 3 кропкі на другім дыску. Агульная ж сітуацыя будзе такая:
Нарэшце, мы зноў падключаем першы дыск. Перад ствараем новай кропкі заданне праверыць, што там з рэтэншэнам. А рэтэншэн, нагадваю, выстаўлены захоўваць 3 кропкі. Тым часам у нас ёсць 3 кропкі на дыску 2 (але ён адключаны і захоўваецца ў надзейным месцы, куды B&R дабрацца не можа) і 3 кропкі на дыску 1 (а вось гэты падлучаны). Значыць, можна смела выдаліць 3 кропкі з дыска 1, паколькі яны перавышаюць рэтэншэн. Пасля чаго заданне зноў стварае поўны бэкап, і наш ланцужок пачынае выглядаць так:
Калі рэтэншэн настроены захоўваць дні замест колькасці кропак, то логіка не мяняецца. Акрамя таго, GFS рэтэншэн не падтрымліваецца зусім пры выкарыстанні рэпазітароў з ратацыяй дыскаў.
Звычайнае заданне і Linux рэпазітар сеткавае сховішча
Такі варыянт таксама магчымы, але ў цэлым менш рэкамендаваны з-за накладзеных абмежаванняў. На ратацыю дыска і знікненне ланцужка заданне будзе рэагаваць гэтак жа - стварэннем поўнага бэкапу. Абмежаванне ж звязана з абрэзаным механізмам рэтэншэна.
Тут пры ратацыі ўвесь ланцужок на адключанай кружэлцы проста выдаляецца з базы дадзеных B&R. Звярніце ўвагу - з базы дадзеных, самі файлы пры гэтым застаюцца на дыску. Іх можна імпартаваць і выкарыстоўваць для аднаўлення, але няцяжка здагадацца, што рана ці позна такія забытыя ланцужкі запоўняць увесь рэпазітар.
Рашэнне - у даданні DWORD ForceDeleteBackupFiles як гэта паказана на гэтай старонцы: . Пасля гэтага заданне пачне проста выдаляць усё змесціва тэчкі задання ці тэчкі рэпазітара (у залежнасці ад значэння) пры кожнай ратацыі.
Аднак гэта не элегантны рэтэншэн, а менавіта чыстка ўсяго змесціва. Нажаль, тэхпадтрымцы сустракаліся выпадкі, калі ў якасці рэпазітара быў паказаны проста каранёвы каталог кружэлкі, дзе апроч бэкапаў ляжалі і іншыя дадзеныя. Усё гэта было знішчана пры ратацыі.
Акрамя таго, пры ўключэнні ForceDeleteBackupFiles працуе для ўсіх тыпаў рэпазітараў, гэта значыць нават рэпазітары на Windows перастануць ужываць ретеншен і пачнуць выдаляць змесціва. Іншымі словамі, лакальная кружэлка на Windows – лепшы выбар для такой сістэмы захоўвання бэкапаў.
Backup copy і Windows рэпазітар
З BCJ усё становіцца яшчэ цікавей. Мала таго, што тут ёсць паўнавартасны рэтэншн, але тут не патрабуецца рабіць поўны бэкап пры кожнай змене дыска! Працуе гэта так:
Спачатку B&R пачынае ствараць кропкі на першым дыску. Скажам, мы выставілі рэтэншэн на 3 кропкі. Заданне будзе працаваць у бясконца-інкрыментальным рэжыме і аб'ядноўваць усё лішняе (нагадаю, GFS рэтэншэн у гэтым выпадку не падтрымліваецца).
Затым мы падлучаем другую кружэлку. Паколькі на ім яшчэ няма ланцужка, то мы ствараем поўны бэкап, пасля чаго ў нас з'яўляецца другі ланцужок з трох кропак:
Нарэшце, прыходзіць час зноў падключыць першы дыск. І вось тут пачынаецца магія, паколькі заданне не створыць поўны бэкап, а замест гэтага проста працягне інкрыментальны ланцужок:
Пасля гэтага фактычна на кожным дыску будзе існаваць свой незалежны ланцужок. Таму ретеншен тут азначае не колькасць кропак на ўсіх кружэлках, а колькасць кропак на кожным дыску ў асобнасці.
Backup copy і Linux рэпазітарсеткавае сховішча
І зноў, уся элегантнасць знікае, калі рэпазітар не на лакальнай кружэлцы Windows. Гэты сцэнар працуе аналагічна разгледжанаму вышэй з простым заданнем. Пры кожнай ратацыі BCJ будзе ствараць поўны бэкап, а існуючыя кропкі будуць забытыя. Каб не застацца без вольнага месца, трэба выкарыстоўваць DWORD ForceDeleteBackupFiles.
Заключэнне
Такім чынам, у выніку такога доўгага тэксту мы разгледзелі два тыпы задання. Вядома, заданняў нашмат больш, але разгледзець іх усіх не атрымаецца ў фармаце аднаго артыкула. Калі пасля прачытання ў вас засталіся нейкія пытанні, то пішыце іх у каментары, я буду рады адказаць асабіста.
Крыніца: habr.com