Здравейте читатели на нашия блог! Отчасти вече сме запознати - моите англоезични публикации се появиха тук в превода на моя скъп колега . Този път реших да се обърна директно към рускоезичната публика.
За моя дебют исках да намеря тема, която да бъде интересна за възможно най-широка публика и да изисква подробно разглеждане. Даниел Дефо твърди, че смъртта и данъците очакват всеки човек. От своя страна мога да кажа, че всеки инженер по поддръжката очаква въпроси относно правилата за съхраняване на точки за възстановяване (или, по-просто казано, задържане). Започнах да обяснявам как работи задържането преди 4 години като младши инженер от ниво XNUMX и продължавам да обяснявам сега като ръководител на испански и италианоговорящ екип. Сигурен съм, че моите колеги от второ и дори трето ниво на поддръжка също редовно отговарят на същите въпроси.
В тази светлина исках да напиша последна, възможно най-подробна публикация, към която рускоезичните потребители да могат да се връщат отново и отново като справка. Моментът е подходящ - наскоро пуснатата десета юбилейна версия добави нови функции към основната функционалност, която не се е променяла от години. Постът ми е насочен предимно към тази версия - въпреки че повечето от написаното е вярно за предишни версии, там просто няма да намерите някои от описаните функции. И накрая, гледайки малко в бъдещето, ще кажа, че се очакват някои промени в следващата версия, но ще ви разкажем за това, когато му дойде времето. Така че да започваме.
Резервни задачи
Първо, нека да разгледаме частта, която не е променена във версия 10. Политиката за задържане се определя от няколко параметъра. Нека отворим прозореца за създаване на нова задача и отидем в раздела Storage. Тук ще видим параметър, който определя желания брой точки за възстановяване:
Това обаче е само част от уравнението. Реалният брой точки също се определя от резервния режим, зададен за заданието. За да изберете тази опция, щракнете върху бутона Разширени в същия раздел. Това ще отвори нов прозорец с много опции. Нека ги номерираме и разгледаме един по един:
Ако е активирана само опция 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 страницата на клиентите, не намерих разбиране, но след като я рисувах както в примера (дори използвайки същата боя), ден след ден, всичко стана ясно.
И накрая, не сме разгледали опцията „Трансформиране на предишни вериги за архивиране в връщане назад“ (маркирана с номер 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 до XNUMX часа. Но третата задача стартира в понеделник. Пълно архивиране е конфигурирано за неделя, така че в този случай просто няма да бъде. Задачата ще изчака пълно архивиране, за да приложи задържането. Така че бъдете внимателни, когато използвате опцията „изпълни след“ или не я използвайте изобщо - просто настройте задачите да стартират по едно и също време и оставете програмата за планиране на ресурси да си свърши работата.
Трудната опция „Премахване на изтрити елементи“
Преминавайки през настройките на задачата Съхранение - Разширено - Поддръжка, можете да се натъкнете на опцията „премахване на данни за изтрити елементи след“, изчислена в дни.
Някои клиенти очакват това да бъде задържане. Всъщност това е напълно отделен вариант, чието неразбиране може да доведе до неочаквани последици. Въпреки това, преди всичко трябва да обясня как B&R реагира на ситуации, при които само няколко машини са успешно архивирани по време на сесията.
Представете си този сценарий: безкрайно нарастваща задача, конфигурирана да съхранява 6 точки. Има 2 машини в задачата, едната винаги архивира успешно, другата понякога дава грешки. В резултат на това до седма точка се разви следната ситуация:
Време е да се приложи задържането, но едната машина има 7 точки, а другата само 4. Ще се приложи ли задържането тук? Отговорът е да, ще стане. Ако поне един обект е архивиран, B&R счита, че точката е създадена.
Подобна ситуация може да възникне, ако някоя машина просто не е била включена в задачата по време на определена сесия. Това се случва например, когато машини се добавят към задачата не поотделно, а като част от контейнери (папки, хранилища) и някои машини временно мигрират към друг контейнер. След това заданието ще се счита за успешно, но ще намерите съобщение в статистиката, което ви казва да обърнете внимание на факта, че такава и такава машина вече не се обработва от заданието.
Какво ще се случи, ако не му обърнете внимание? В случай на безкрайно-инкрементален или обратно-инкрементален режим, броят на точките за възстановяване на "проблемната" машина ще намалява с всяка сесия, докато достигне 1, запазена във VBK. С други думи, дори ако машината не е архивирана дълго време, една точка за възстановяване ще остане. Това не е така, ако периодичните пълни архиви са активирани. Ако сигналите от B&R се игнорират, последната точка може в крайна сметка да бъде изтрита заедно със старата част от веригата.
След като разберем тези подробности, най-накрая можем да разгледаме опцията „Премахване на данните за изтритите елементи след“. Той ще изтрие всички точки за определена машина, ако тази машина не бъде архивирана за X дни. Моля, обърнете внимание, че тази настройка не отговаря на грешки (пробвано - не работи). Не трябва дори да има опит за архивиране на машината. Изглежда, че опцията е полезна и винаги трябва да бъде активирана. Ако администраторът е премахнал машината от задачата, тогава е логично да изчистите веригата от ненужни данни след известно време. Настройката обаче изисква дисциплина и внимание.
Нека ви дам пример от практиката: към задачата бяха добавени няколко контейнера, чийто състав беше доста динамичен. Поради липсата на RAM, сървърът на B&R имаше проблеми, които останаха незабелязани. Задачата стартира и се опита да направи резервно копие на машините, с изключение на една, която по това време не присъстваше в контейнера. Тъй като много машини са генерирали грешки, по подразбиране B&R трябва да направи 3 допълнителни опита за архивиране на "проблемни" машини. Поради постоянни проблеми с RAM паметта, тези опити се проточиха няколко дни. Нямаше втори опит за архивиране на липсващата виртуална машина (липса на виртуална машина не е грешка). В резултат на това при един от повторните опити условието „Премахване на изтрити елементи“ беше изпълнено и всички точки на машината бяха изтрити.
По този повод мога да кажа следното: ако имате известия за резултатите от зададени задачи и още по-добре, използва се интеграция с Veeam ONE, тогава най-вероятно това няма да ви се случи. Ако гледате B&R сървъра веднъж седмично, за да проверите дали всичко работи, тогава е по-добре да откажете опции, които потенциално биха могли да доведат до изтриване на резервни копия.
Какво е новото във v.10
Това, за което говорихме преди, съществува в B&R за много версии. След като разбрахме тези принципи на работа, нека сега видим какво беше добавено в юбилейната "десетка".
Ежедневно задържане
По-горе разгледахме "класическата" политика за съхранение въз основа на броя на точките. Алтернативен подход е да зададете „дни“ вместо „точки за възстановяване“ в същото меню.
Идеята е ясна от името - задържането ще съхранява зададения брой дни, броят точки за всеки ден няма значение. При това помнете следното:
- Текущият ден не се взема предвид при изчисляване на задържането
- Отчитат се и дните, в които задачата изобщо не е работила. Това трябва да се има предвид, за да не загубите случайно точките на онези задачи, които работят нередовно.
- Точката на възстановяване се брои от деня, в който е създадена (т.е. ако задачата е започнала в понеделник и е завършила във вторник, това е точка от понеделник)
В противен случай принципите за прилагане на задържане по задачи също се определят от избрания резервен метод. Нека опитаме друга задача за изчисление, използвайки същия инкрементален метод. Да кажем, че задържането е зададено на 8 дни, задачата се изпълнява на всеки 6 часа с пълно архивиране в сряда. В този случай задачата не работи в неделя. Работата се изпълнява в понеделник за първи път. Кога ще бъде приложено задържането?
Отговарям
Както обикновено, най-добре е да нарисувате знак. Ще си позволя да опростя задачата и няма да рисувам всички точки, създадени за всеки ден, тъй като броят точки на ден тук няма значение. За нас е важно само в първия понеделник и в сряда първата точка да бъде пълно резервно копие, в останалите дни задачата просто ще създаде 4 допълнителни точки.
Разбираме за себе си, че задържането ще бъде приложено чрез изтриване на пълното архивиране в понеделник и неговото увеличение. Кога ще стане? Когато останалата част от веригата ще съдържа 8 дни. В същото време не броим текущия ден, а неделя, напротив, броим. Така че отговорът е четвъртък на втората седмица.
GFS архивиране за редовни работни места
Преди v.10 методът за съхранение на дядо-баща-син (GFS) беше достъпен само за задания за архивиране и копиране на лента. Сега е наличен и за редовно архивиране.
Въпреки че това не е свързано с настоящата тема, не мога да кажа, че новата функционалност не означава отклонение от стратегията 3-2-1. Наличието на архивни точки в основното хранилище не влияе по никакъв начин на неговата надеждност. Разбираемо е, че GFS ще се използва във връзка с мащабно хранилище за изпращане на тези точки до 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 може също да съхранява архивирани точки. Това е конфигурирано в същия раздел Target, точно под настройките за броя точки за възстановяване:
GFS точките могат да бъдат създадени по два начина - синтетично, като се използват данните от вторичното хранилище или чрез симулиране на пълно архивиране и четене на всички данни от основното хранилище (активира се от опцията, маркирана с номер 3). Задържането и в двата случая ще бъде много различно, така че ще ги разгледаме поотделно.
Синтетичен GFS
В този случай GFS точката не е създадена точно в определения ден. Вместо това ще бъде създадена GFS точка, когато VIB на деня, в който GFS точката е планирано да бъде създадена, се обедини с пълното архивиране. Това понякога предизвиква недоразумения, защото времето минава, но все още няма GFS точка. И само мощен шаман от техническата поддръжка може да предвиди в кой ден точката все още ще се появи. Всъщност магия не е необходима - просто погледнете зададения брой точки и интервала на синхронизация (колко точки се създават всеки ден). Опитайте се да го изчислите сами, като използвате този пример: задачата е настроена да съхранява 7 точки, интервалът на синхронизация е 12 часа (т.е. 2 точки на ден). В момента във веригата вече има 7 точки, днес е понеделник и за този ден е планирано създаването на GFS точка. Кой ден ще бъде създаден?
Отговарям
Тук е по-добре да опишете как веригата ще се променя в динамика, през деня:
И така, в понеделник последното увеличение във веригата е маркирано като 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. В такива случаи е по-добре да използвате синтетичния метод за създаване GFS.
И отново „Премахване на изтрити елементи“
Тази опция е налице и за BCJ:
Логиката на тази опция тук е същата като при обикновените задачи за архивиране - ако машината не се обработва за посочения брой дни, тогава нейните данни се изтриват от веригата. За BCJ обаче тази опция е обективно по-полезна и ето защо.
В нормален режим BCJ работи в безкрайно инкрементален режим, така че ако в даден момент машината бъде премахната от задачата, тогава задържането постепенно ще изтрие всички точки за възстановяване, докато остане само една - във VBK. Сега нека си представим, че заданието също е конфигурирано за създаване на синтетични GFS точки. Когато дойде времето, задачата ще трябва да създаде GFS за всички машини във веригата. Ако някоя машина изобщо няма нови точки - добре, трябва да използвате тази, която е. И така всеки път. В резултат на това може да възникне следната ситуация:
Обърнете внимание на секцията Файлове: имаме основните VBK и 2 седмични GFS точки. А сега към раздела Точки за възстановяване - всъщност тези файлове съдържат едно и също изображение на машината. Естествено, няма смисъл от такива GFS точки, те само заемат място.
Тази ситуация е възможна само при използване на синтетичен GFS. За да предотвратите това, използвайте опцията „Премахване на изтрити елементи“. Само не забравяйте да го зададете за подходящ брой дни. Техническата поддръжка е виждала случаи, в които опцията е била зададена на по-малко от броя на дните от интервала на синхронизиране - BCJ започна да буйства и да изтрива точки, преди да има време да ги създаде.
Имайте предвид също, че тази опция не засяга съществуващите GFS точки. Ако искате да почистите архивите, трябва да го направите ръчно - като щракнете с десния бутон върху машината и изберете "Изтриване от диска" (в прозореца, който се показва, не забравяйте да поставите отметка в квадратчето "Премахване на пълно архивиране на GFS") :
Innovation v.10 - незабавно копие (незабавно копие)
След като се справихме с "класическата" функционалност, нека да преминем към новата. Иновацията е една, но много важна. Това е нов режим на работа.
Няма такова нещо като „интервал на синхронизиране“, задачата постоянно ще следи дали са се появили нови точки и ще ги копира всички, независимо колко са. Заданието обаче остава инкрементално, което означава, че дори ако основното задание създаде VBK или VRB, тези точки ще бъдат копирани като VIB. В противен случай няма изненади в този режим - както стандартното, така и GFS задържането работи според правилата, описани по-горе (въпреки че тук е наличен само синтетичен GFS).
Дисковете се въртят. Характеристики на Rotated Drives Repositories
Постоянната заплаха от ransomware вируси превърна в де факто стандарт за сигурност копието на данните на носител, до който вирусът не може да достигне. Единият вариант е да се използват хранилища с въртящ се диск, където дисковете се използват на свой ред: докато един диск е свързан и може да се записва, останалите се съхраняват на сигурно място.
За да научите B&R да работи с такива хранилища, в настройките на хранилището, в стъпката Репозиторий, щракнете върху бутона Разширени и изберете подходящата опция:
След това 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