Поздрав до нашите читатели на блогови! Делумно веќе ни се познати - моите објави на англиски јазик се појавија овде преведени од мојот драг колега . Овој пат решив директно да и се обратам на публиката што зборува руски.
За моето деби, сакав да најдам тема што ќе биде интересна за најшироката можна публика и ќе бара детално разгледување. Даниел Дефо тврдеше дека смртта и даноците го чекаат секој човек. Од моја страна, можам да кажам дека секој инженер за поддршка ќе има прашања во врска со политиките за складирање на точките за обновување (или, поедноставно, задржување). Почнав да објаснувам како функционира задржувањето пред 4 години, како помлад инженер од прво ниво, и продолжувам да објаснувам сега, веќе како водач на тим од шпански и италијански јазик. Сигурен сум дека и моите колеги од второто, па и третото ниво на поддршка, исто така редовно одговараат на истите прашања.
Во ова светло, сакав да напишам последен, што е можно подетален пост, на кој корисниците што зборуваат руски би можеле да се враќаат повторно и повторно како референтна книга. Моментот е вистинскиот - неодамна објавената десетгодишнина верзија додаде нови функции на основната функционалност што не се менуваше со години. Мојот пост е фокусиран првенствено на оваа верзија - иако повеќето од напишаното е точно за претходните верзии, едноставно нема да најдете некои од опишаните функционалности таму. Конечно, гледајќи малку во иднината, ќе кажам дека се очекуваат некои промени во следната верзија, но за ова ќе ви кажеме кога ќе дојде време. Па ајде да започнеме.
Резервни работни места
Прво, да го погледнеме делот што не е променет во верзијата 10. Политиката за задржување е одредена од неколку параметри. Ајде да го отвориме прозорецот за креирање нова задача и да одиме во табот Складирање. Овде ќе видиме параметар кој го одредува саканиот број на точки за враќање:
Сепак, ова е само дел од равенката. Вистинскиот број на поени се одредува и со резервниот режим поставен за работата. За да ја изберете оваа опција, кликнете на копчето Напредно на истиот таб. Ова ќе отвори нов прозорец со многу опции. Ајде да ги нумерираме и да ги разгледаме еден по еден:
Ако ја овозможите само опцијата 1, работата ќе работи во режимот „засекогаш напред постепено“. Нема потешкотии овде - задачата ќе го складира наведениот број точки за обновување од целосна резервна копија (датотека со наставката VBK) до последниот прираст (датотека со наставката VIB). Кога бројот на поени ќе ја надмине поставената вредност, најстариот прираст ќе се спои со целосната резервна копија. Со други зборови, ако задачата е поставена да складира 3 точки, тогаш веднаш по следната сесија ќе има 4 точки на складиштето, по што целосната резервна копија ќе се спои со најстариот прираст и вкупниот број на поени ќе се врати на 3.
Задржувањето за режимот „обратно инкрементално“ (опција 2) е исто така исклучително едноставно. Бидејќи во овој случај најновата точка ќе биде целосна резервна копија, проследена со синџир на таканаречени враќања (датотеки со наставката VRB), тогаш за да се примени задржување доволно е едноставно да се избрише најстарото враќање назад. Ситуацијата ќе биде иста: веднаш по сесијата, бројот на поени ќе ја надмине поставената вредност за 1, по што ќе се врати на саканата вредност.
Ве молиме имајте предвид дека со обратниот режим на зголемување можете да овозможите и периодични целосни резервни копии (опција 4), но тоа нема да ја промени суштината. Да, точките за целосно закрепнување ќе се појават во синџирот, но сепак едноставно ќе ги бришеме најстарите точки една по една.
Конечно, доаѓаме до интересниот дел. Ако активирате постепена резервна копија, но дополнително ги овозможите опциите 3 или 4 (или и двете истовремено), задачата ќе започне да создава периодични целосни резервни копии со помош на „активен“ или синтетички метод. Методот за создавање целосна резервна копија не е важен - тој ќе ги содржи истите податоци, а зголемениот синџир ќе биде поделен на „подсинџири“. Овој метод се нарекува напред инкрементален, и токму овој метод покренува значителен дел од прашањата од нашите клиенти.
Задржувањето овде се применува со бришење на најстариот дел од ланецот (од целосна резервна копија до зголемување). Во исто време, нема да избришеме само целосна резервна копија или само дел од зголемувањата. Целиот „подсинџир“ се отстранува целосно одеднаш. Се менува и значењето на поставувањето на бројот на поени - ако во другите методи ова е максимално дозволениот број, по што мора да се примени задржување, тогаш овде оваа поставка го одредува минималниот број. Со други зборови, по отстранувањето на најстариот „подсинџир“, бројот на поени во преостанатиот дел не треба да падне под овој минимум.
Ќе се обидам графички да го прикажам овој концепт. Да речеме дека задржувањето е поставено на 3 поени, задачата работи секој ден со целосна резервна копија во понеделник. Задржувањето во овој случај ќе се примени кога вкупниот број на поени ќе достигне 10:
Зошто има веќе 10 кога ставаат 3? Во понеделникот беше создадена целосна резервна копија. Од вторник до недела работното место создава зголемувања. Конечно, следниот понеделник повторно се креира целосна резервна копија и само кога ќе се создадат 2 зголемувања конечно може да се избрише целиот стар дел од синџирот, бидејќи преостанатиот број на поени нема да падне под множеството 3.
Ако идејата е јасна, тогаш предлагам да се обидете сами да пресметате задржување. Да ги земеме следните услови: задачата е стартувана за прв пат во четврток (нормално, ќе се направи целосна резервна копија). Задачата е поставена да создаде целосна резервна копија во среда и недела и да складира 8 точки за обновување. Кога ќе се примени задржувањето за прв пат?
За да одговорите на ова прашање, ви препорачувам да земете парче хартија, да го редите по ден во неделата и да запишете која точка се создава секој ден. Одговорот ќе стане очигледен
Одговори
Објаснување: за да одговорите, само запрашајте се „кога ќе се примени задржувањето“? Одговорот е кога можеме да ги отстраниме првите 3 поени (VBK, VIB, VIB) и остатокот од синџирот да не падне под потребните 8 поени. Станува јасно дека ова ќе можеме да го направиме кога ќе имаме вкупно 11 бодови, односно во недела од втората недела.
Некои читатели може да се спротивстават: „зошто да се прави сето ова ако има ?. Нема сомнеж дека ова е многу корисна алатка и во некои случаи би ја користел, но има и ограничувања. Како прво, не ви дозволува да ги специфицирате почетните услови, а во многу случаи прашањето е токму „имаме таков ланец, што ќе се случи ако промениме такви и такви поставки? Второ, на алатката сè уште му недостига јасност. Прикажувајќи ја страницата RPS на клиентите, не најдов никакво разбирање, но откако ја насликав како во примерот (дури и користејќи ја истата Paint), од ден на ден, сè стана јасно.
Конечно, не ја разгледавме опцијата „Трансформирајте ги претходните резервни синџири во враќање назад“ (означена со број 5). Оваа опција понекогаш ги збунува клиентите кои ја активираат „автоматски“, сакајќи едноставно да овозможат синтетичка резервна копија. Во меѓувреме, оваа опција активира многу посебен режим на резервна копија. Без да навлегувам во детали, веднаш ќе кажам дека во оваа фаза на развој на производот, „Трансформирајте ги претходните резервни синџири во враќање назад“ е застарена опција и не можам да замислам ниту едно сценарио кога треба да се користи. Неговата вредност е толку сомнителна што извесно време самиот Антон Гостев се јавуваше преку форумот, барајќи да му испрати примери за неговата корисна употреба (ако ги имате, напишете ги во коментарите, многу ме интересира). Ако ги нема (мислам дека тоа ќе биде случај), тогаш опцијата ќе биде отстранета во идните верзии.
Задачата ќе создава зголемувања (VIB) до денот кога е закажана синтетичка целосна резервна копија. На овој ден, всушност се создава VBK, но сите точки пред овој VBK се трансформираат во враќање (VRB). По ова, задачата ќе продолжи да создава зголемувања на целосната резервна копија до следната синтетичка резервна копија. Како резултат на тоа, во ланецот се создава експлозивна мешавина од датотеки VBK, VBR и VIB. Задржувањето се применува многу едноставно - со отстранување на последниот VBR:
Проблеми
Освен што всушност се разбира како функционира, повеќето од проблемите што се појавуваат при користење на постепен режим обично се поврзани со целосна резервна копија. За овој режим се неопходни редовни целосни резервни копии, инаку складиштето ќе акумулира поени додека не се полни.
На пример, целосна резервна копија може да се креира премногу ретко. Да речеме дека задачата е поставена да складира 10 точки, а целосна резервна копија се креира еднаш месечно. Јасно е дека вистинскиот број на поени овде ќе биде значително поголем од прикажаниот. Или, генерално, задачата е поставена да работи во бесконечно растечки режим и да складира 50 поени. Потоа некој случајно направи целосна резервна копија. Тоа е тоа, отсега задачата ќе чека додека целосната точка не собере 49 зголемувања, по што ќе примени задржување и ќе се врати во бескрајно полн режим.
Во други случаи, целосната резервна копија е поставена да се создава редовно, но поради некоја причина не. Овде ќе ја наведам најпопуларната причина. Некои клиенти претпочитаат да ја користат опцијата за закажување „трчање по“ и да ги конфигурираат работните места да се извршуваат во синџир. Да го земеме овој пример: има 3 работни места кои работат секој ден и создаваат целосна резервна копија во недела. Првата задача започнува во 22.30 часот, останатите се лансирани во синџир. Постојаната резервна копија трае 10 минути, и затоа до 23.00 часот сите работи завршуваат со работа. Но, целосната резервна копија трае еден час, така што во недела се случува следново: првата задача работи од 22.30 до 23.30 часот. Следно од 23.30 до 00.30 часот. Но, третата задача започнува во понеделник. Целосна резервна копија е поставена за недела, така што во овој случај тоа едноставно нема да се случи. Задачата ќе чека целосна резервна копија за да се примени задржувањето. Затоа, бидете внимателни кога ја користите опцијата „run after“ или не ја користете воопшто - само поставете ги задачите да започнуваат во исто време и оставете распоредувачот на ресурси да ја заврши својата работа.
Тешката опција „Отстрани избришани ставки“
Откако ќе ги поминете поставките на задачата Складирање – Напредно – Одржување, можете да наидете на опцијата „отстрани ги податоците за избришаните ставки потоа“, која може да се брои во денови.
Некои клиенти очекуваат ова да биде задржување. Всушност, ова е сосема посебна опција, чие недоразбирање може да доведе до неочекувани последици. Сепак, пред сè, треба да објасниме како B&R реагира на ситуации каде што само неколку машини се успешно поддржани за време на сесијата.
Ајде да го замислиме ова сценарио: бескрајно зголемена работа конфигурирана да складира 6 точки. Има 2 машини во задачата, едната секогаш се прави резервна копија успешно, другата понекогаш даваше грешки. Како резултат на тоа, до седмата точка се појави следнава ситуација:
Време е да се примени задржување, но едниот автомобил има 7 поени, а другиот само 4. Дали овде ќе се применува задржување? Одговорот е да, тоа ќе биде. Ако барем еден објект има резервна копија, B&R смета дека точката е создадена.
Слична ситуација може да се појави ако некоја машина едноставно не била вклучена во задачата за време на одредена сесија. Ова се случува, на пример, кога машините се додаваат на задача не поединечно, туку како дел од контејнери (папки, складирање) и некоја машина привремено мигрира во друг контејнер. Во овој случај, задачата ќе се смета за успешна, но во статистиката ќе најдете порака во која се бара да обрнете внимание дека таква и таква машина повеќе не се обработува со задачата.
Што ќе се случи ако не обрнете внимание на ова? Во случај на бесконечно-инкрементални или обратни инкрементални режими, бројот на точки за враќање на „проблематичната“ машина ќе се намалува со секоја сесија додека не достигне 1, складирана во VBK. Со други зборови, дури и ако машината нема да има резервна копија долго време, сепак ќе остане една точка за враќање. Ситуацијата е поинаква ако се овозможени периодични целосни резервни копии. Ако ги игнорирате сигналите од B&R, последната точка може на крајот да биде избришана заедно со стариот дел од ланецот.
Откако ги разбравте овие детали, конечно можете да ја разгледате опцијата „Отстрани ги податоците за избришаните ставки потоа“. Ќе ги избрише сите точки за одредена машина ако таа машина не е резервна копија X дена. Имајте предвид дека оваа поставка не реагира на грешки (се обидов, но не функционираше). Не треба ни да има обид за резервна копија на машината. Се чини дека опцијата е корисна и секогаш треба да биде вклучена. Ако администраторот ја отстрани машината од задачата, тогаш по некое време е логично да се исчисти ланецот од непотребни податоци. Сепак, приспособувањето бара дисциплина и грижа.
Дозволете ми да ви дадам пример од практиката: на задачата беа додадени неколку контејнери, чиј состав беше доста динамичен. Поради недостаток на RAM меморија, серверот B&R се соочуваше со проблеми кои останаа неоткриени. Задачата започна и се обиде да направи резервна копија на машините, освен една, која во тој момент ја немаше во контејнерот. Бидејќи многу машини генерираат грешки, стандардно B&R треба да направи 3 дополнителни обиди за резервна копија на „проблематичните“ машини. Поради постојаните проблеми со RAM меморијата, овие обиди траеја неколку дена. Немаше повторен обид да се направи резервна копија на VM што недостасува (отсуството на VM не е грешка). Како резултат на тоа, при еден од повторените обиди, условот „Отстрани ги избришаните ставки“ беше исполнет и сите точки на машината беа избришани.
Во врска со ова, можам да го кажам следново: ако имате поставено известувања за резултатите од задачите, а уште подобро, користете интеграција со Veeam ONE, тогаш најверојатно тоа нема да ви се случи. Ако го погледнете серверот B&R еднаш неделно за да проверите дали сè работи, тогаш подобро е да одбиете опции што потенцијално би можеле да доведат до бришење на резервните копии.
Што е додадено во ст.10
Она за што зборувавме порано постоело во B&R за многу верзии. Откако ги разбравме овие принципи на работа, ајде сега да погледнеме што е додадено на годишнината „десет“.
Дневно задржување
Погоре ја разгледавме „класичната“ политика за складирање врз основа на бројот на поени. Алтернативен пристап е да поставите „денови“ наместо „точки за враќање“ во истото мени.
Идејата е јасна од името - задржувањето ќе складира одреден број денови, но бројот на поени во секој ден не е важен. Во овој случај, треба да го запомните следново:
- Тековниот ден не се зема предвид при пресметување на задржувањето
- Се бројат и деновите кога задачата воопшто не функционирала. Ова треба да се има на ум за случајно да не се изгубат поените на оние задачи кои работат нередовно.
- Точката за наплата се брои од денот кога започна неговото создавање (т.е. ако задачата почна да работи во понеделник и заврши во вторник, тогаш ова е точка од понеделник)
Инаку, принципите за користење задржување по задачи се одредуваат и со избраниот резервен метод. Ајде да се обидеме со друга задача за пресметка користејќи го истиот поединечен метод. Да речеме дека задржувањето е поставено за 8 дена, задачата работи на секои 6 часа со целосна резервна копија во среда. Сепак, задачата не функционира во недела. Работата работи во понеделник за прв пат. Кога ќе се применува задржувањето?
Одговори
Како и секогаш, најдобро е да нацртате знак. Ќе си дозволам да ја поедноставам задачата и нема да ги цртам сите поени создадени за секој ден, бидејќи бројот на поени дневно не е важен овде. Нам ни е важно само првиот понеделник и среда првата точка да биде целосна резервна копија, но во останатите денови задачата едноставно ќе создаде 4 дополнителни поени.
Јасно појаснуваме дека задржувањето ќе се примени со бришење на целосната резервна копија од понеделник и нејзиното зголемување. Кога ќе се случи ова? Кога остатокот од синџирот содржи 8 дена. Во исто време, не го броиме тековниот ден, туку напротив, ја броиме неделата. Затоа, одговорот е четврток од втората недела.
GFS архивирање за редовни работни места
Пред верзијата 10, методот за складирање „Дедо-татко-син“ (GFS) беше достапен само за задачите за резервна копија и задачите за копирање на лента. Сега е достапен за редовна резервна копија.
Иако ова не е поврзано со актуелната тема, не можам да не кажам дека новата функционалност не значи отстапување од стратегијата 3-2-1. Присуството на архивски точки во главното складиште на никаков начин не влијае на неговата сигурност. Разбирливо е дека GFS ќе се користи во врска со складиштето за Scale-out за да се прикачат овие точки на S3 и слични складишта. Ако не го користите, тогаш подобро е да продолжите да ги чувате примарните и архивските точки во различни складишта.
Сега да ги погледнеме принципите на создавање GFS точки. Во поставките за задачи, на чекорот Складирање, се појави специјално копче кое го повикува следново мени:
Суштината на GFS може да се сведе на неколку точки (забележете дека GFS работи поинаку во други видови задачи, но повеќе за тоа подоцна):
- Задачата не создава посебна целосна резервна копија за точката GFS. Наместо тоа, ќе се користи најсоодветната достапна целосна резервна копија. Затоа, задачата мора да работи во постепен режим со периодични целосни резервни копии, или целосна резервна копија мора да се создаде рачно од корисникот.
- Ако е овозможен само еден период (на пример, една недела), тогаш на почетокот на периодот на GFS задачата едноставно ќе започне да чека целосна резервна копија и ќе го означи првиот соодветен како GFS.
Пример: работата е конфигурирана да складира неделен GFS користејќи резервна копија во среда. Задачата работи секој ден, но целосна резервна копија е закажана за петок. Во овој случај, периодот на GFS ќе започне во среда и задачата ќе започне да чека соодветна точка. Ќе се појави во петок и ќе биде означен со знамето GFS.
- Ако се вклучени неколку периоди одеднаш (на пример, неделни и месечни), тогаш B&R ќе користи метод што дозволува истата точка да се користи како GFS од неколку интервали (за да заштеди простор). Знамињата ќе бидат доделени по редослед, почнувајќи од најмладите.
Пример: неделниот GFS е поставен за среда, а месечниот GFS е поставен за последната недела од месецот. Задачата работи секој ден и создава целосни бекап во понеделник и петок.
За едноставност, да почнеме да броиме од претпоследната недела во месецот. Оваа недела ќе се создаде целосна резервна копија во понеделник, но таа ќе се игнорира бидејќи неделниот интервал GFS започнува во среда. Но, целосната резервна копија од петок е целосно погодна за точката GFS. Овој систем веќе ни е познат.
Сега да погледнеме што се случува во последната недела од месецот. Месечниот интервал на GFS ќе започне во понеделник, но VBK од понеделник нема да биде означен како GFS бидејќи работата се обидува да означи еден VBK и како месечна и како неделна GFS точка. Во овој случај, пребарувањето започнува со неделното, бидејќи по дефиниција може да стане и месечниот.
Меѓутоа, ако ги вклучите само неделните и годишните интервали, тие ќе дејствуваат независно еден од друг и може да означат 2 посебни VBK како соодветни интервали на GFS.
Задачи за резервна копија
Друг тип на задача која често бара појаснување за работата. Прво, да го погледнеме „класичниот“ метод на работа, без иновации v.10
Едноставен метод на задржување
Стандардно, таквите задачи се извршуваат во бесконечен режим на зголемување. Создавањето точки се определува со два параметри - интервалот за копирање и саканиот број на точки за обновување (овде нема задржување по ден). Интервалот за копирање е поставен на првото јазиче Job кога креирате работа:
Бројот на поени се одредува малку подалеку на табот Цел
Задачата создава 1 нова точка за секој интервал (колку поени се создадени за VM од оригиналните задачи не е важно). На крајот од интервалот, новата точка се финализира и, доколку е потребно, се применува задржување со комбинирање на VBK и најстариот прираст. Овој механизам ни е веќе познат.
Метод на задржување со помош на GFS
BCJ исто така може да складира архивски точки. Ова е конфигурирано на истиот таб Цел, веднаш под поставката за бројот на точки за враќање:
GFS точките може да се креираат на два начина - синтетички, користејќи податоци на секундарно складиште или со симулирање на целосна резервна копија и читање на сите податоци од примарното складиште (активирано со опцијата означена со 3). Задржувањето во двата случаи ќе биде многу различно, па затоа ќе ги разгледаме одделно.
Синтетички GFS
Во овој случај, точката GFS не се креира точно на назначениот ден. Наместо тоа, ќе се создаде точка GFS кога VIB од денот за кој беше планирано да се создаде точката GFS ќе се спои со целосна резервна копија. Ова понекогаш предизвикува недоразбирање, бидејќи времето поминува и сè уште нема точка GFS. И само моќен шаман од техничка поддршка може да предвиди на кој ден ќе се појави точката. Всушност, магијата не е потребна - само погледнете го поставениот број на точки и интервалот на синхронизација (колку точки се создаваат секој ден). Обидете се сами да го пресметате користејќи го овој пример: задачата е поставена да складира 7 точки, интервалот на синхронизација е 12 часа (т.е. 2 поени на ден). Во моментов во синџирот има веќе 7 точки, денеска е понеделник, а за овој ден е закажано создавање на пункт ГФС. На кој ден ќе се создаде?
Одговори
Овде е подобро да се опише како синџирот ќе се менува со текот на времето, од ден на ден:
Така, во понеделник, последниот прираст во синџирот е означен како GFS, но не се случуваат други видливи промени. Секој ден, задачата создава 2 нови точки, а задржувањето незапирливо го движи ланецот напред. Конечно, во четврток доаѓа време да се примени задржување токму на тој прираст. Оваа сесија ќе потрае подолго од вообичаеното - бидејќи задачата ќе ги „извлече“ потребните блокови од ланецот и ќе создаде нова целосна точка. Од овој момент, веќе ќе има 8 точки во синџирот - 7 во главниот синџир + GFS.
Креирање на GFS точки со опцијата „Прочитај ја целата точка“.
Погоре реков дека BCJ работи во бесконечно инкрементален режим. Сега ќе го разгледаме единствениот исклучок од ова правило. Кога е овозможена опцијата „Прочитај ја целата точка“, точката GFS ќе се креира точно на закажаниот ден. Самата задача ќе работи во постепен режим со периодични целосни резервни копии, за кои разговаравме погоре. Задржувањето ќе се примени и со отстранување на најстариот дел од ланецот. Меѓутоа, во овој случај, само зголемувањата ќе бидат избришани, а целосната резервна копија ќе остане како точка GFS. Според тоа, точките означени со знаменца GFS не се земаат предвид при пресметувањето на задржувањето.
Да речеме дека задачата е поставена да складира 7 точки и да создаде неделна GFS точка во понеделник. Во овој случај, секој понеделник задачата всушност ќе создаде целосна резервна копија и ќе ја означи како GFS. Задржувањето ќе се примени кога, по отстранувањето на зголемувањата од најстариот дел, бројот на преостанатите зголемувања не падне под 7. Вака изгледа на дијаграмот:
Така, до крајот на втората недела има вкупно 14 поени во синџирот. Во текот на втората недела, задачата создаде 7 поени. Ако ова беше едноставна задача, задржувањето веќе ќе беше применето. Но, ова е BCJ со задржување на GFS, така што не ги броиме GFS поени, што значи дека има само 6 од нив. Односно, сè уште не можеме да примениме задржување. Во третата недела создаваме уште една целосна резервна копија со знамето GFS. 15 поени, но повторно не го броиме овој. И, конечно, во вторник од третата недела, создаваме прираст. Сега, ако ги отстраниме зголемувањата на синџирот од првата недела, вкупниот број на зголемувања ќе го задоволи утврденото задржување.
Како што споменавме погоре, во овој метод е многу важно редовно да се креираат целосни резервни копии. Да речеме, ако го поставите главното задржување за 7 дена, но само 1 годишен поен, лесно е да се замисли дека зголемувањата ќе се акумулираат многу, многу повеќе од 7. Во такви случаи, подобро е да се користи синтетичкиот метод на создавање ГФС.
И повторно „Отстрани ги избришаните ставки“
Оваа опција е присутна и за BCJ:
Логиката на оваа опција овде е иста како и во редовните задачи за резервна копија - ако машината не се обработува за наведениот број денови, тогаш нејзините податоци се бришат од ланецот. Сепак, за BCJ корисноста на оваа опција е објективно поголема, и еве зошто.
Во нормален режим, BCJ работи во бесконечно растечки режим, па ако во одреден момент машината се отстрани од работата, тогаш задржувањето постепено ќе ги избрише сите точки за обновување додека не остане само една - во VBK. Сега да замислиме дека задачата сè уште е конфигурирана да создава синтетички GFS точки. Кога ќе дојде време, работата ќе треба да создаде GFS за сите машини во синџирот. Ако некоја машина воопшто нема нови точки, добро, ќе мора да ја користите таа што е. И така секој пат. Како резултат, може да се појави следнава ситуација:
Обрнете внимание на делот Датотеки: ги имаме главните VBK и 2 неделни GFS точки. И сега во делот Врати точки - всушност, овие датотеки ја содржат истата слика на машината. Нормално, нема поента во такви GFS точки, тие само зафаќаат простор.
Оваа ситуација е можна само кога се користи синтетички GFS. За да го спречите ова, користете ја опцијата „Отстрани избришани ставки“. Само не заборавајте да го поставите за соодветен број денови. Техничката поддршка забележа случаи кога опцијата беше поставена за помалку денови од интервалот за синхронизација - BCJ почна да збеснува и да ги брише точките пред да можат да се создадат.
Исто така, имајте предвид дека оваа опција не влијае на веќе создадените GFS точки. Ако сакате да ги исчистите архивите, треба да го направите ова рачно - со десен клик на машината и избирање на „Избриши од диск“ (во прозорецот што се појавува, не заборавајте да го проверите полето „Отстрани целосна резервна копија на GFS“) :
Innovation v.10 – непосредна копија
Откако се занимававме со „класичната“ функционалност, да преминеме на новата. Има една иновација, но многу важна. Ова е нов начин на работа.
Не постои такво нешто како „интервал на синхронизација“; задачата постојано ќе следи дали се појавиле нови точки и ќе ги копира сите, без разлика колку ги има. Но, во исто време, работата останува инкрементална, односно, дури и ако главната работа создаде VBK или VRB, овие точки ќе бидат копирани како VIB. Инаку, нема изненадувања во овој режим - и стандардниот и GFS задржувањето работат според правилата опишани погоре (сепак, овде е достапен само синтетички GFS).
Дисковите се вртат. Карактеристики на складишта со ротирани дискови
Постојаната закана од вируси за откупни софтвери го направи де факто безбедносен стандард да се има копија од податоци на медиум каде што вирусот не може да стигне. Една опција е да се користат складишта за ротација на дискот, каде што дисковите се користат еден по еден: додека еден диск е поврзан и може да се запише, останатите се складираат на безбедна локација.
За да го научите B&R да работи со такви складишта, треба да кликнете на копчето Advanced во поставките на складиштето, на чекорот Repository и да ја изберете соодветната опција:
По ова, 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 е најдобриот избор за таков систем за складирање резервни копии.
Резервна копија и складиште на Windows
Работите стануваат уште поинтересни со BCJ. Не само што има полноправно задржување, туку нема потреба да правите целосна резервна копија секогаш кога ќе го менувате дискот! Работи вака:
Прво, B&R започнува да создава точки на првиот диск. Да речеме дека го поставивме задржувањето на 3 поени. Задачата ќе работи во бесконечно инкрементален режим и ќе спои сè што е непотребно (ве потсетувам дека задржувањето на GFS не е поддржано во овој случај).
Потоа го поврзуваме вториот погон. Бидејќи сè уште нема синџир на него, создаваме целосна резервна копија, по што имаме втор синџир од три точки:
Конечно, време е повторно да го поврзете првиот диск. И тука започнува магијата, бидејќи задачата нема да создаде целосна резервна копија, туку едноставно ќе го продолжи инкременталниот синџир:
По ова, практично секој диск ќе има свој независен синџир. Затоа, задржувањето овде не значи број на точки на сите дискови, туку број на точки на секој диск посебно.
Резервна копија и мрежно складирање на складиштето на Linux
Уште еднаш, целата елеганција е изгубена ако складиштето не е на локален Windows диск. Оваа скрипта работи слично на онаа што беше дискутирано погоре со едноставна задача. Со секоја ротација, BCJ ќе создаде целосна резервна копија, а постоечките точки ќе бидат заборавени. За да избегнете да останете без слободен простор, треба да користите DWORD ForceDeleteBackupFiles.
Заклучок
Значи, како резултат на толку долг текст, разгледавме два вида задачи. Се разбира, има многу повеќе задачи, но нема да може да се разгледаат сите во формат на една статија. Ако по читањето сè уште имате какви било прашања, напишете ги во коментарите, со задоволство ќе одговорам лично.
Извор: www.habr.com