Создавање и управување со задачи за резервна копија

Создавање и менување на задача за резервна копија

Процесот на создавање на задача за резервна копија започнува со кликање на Create копчето во Jobs табот, како што е прикажано на следната слика. Управувањето на задачите е преку идентичниот процес како и создавањето на задачите, но се иницира преку Edit опцијата во Job менито кое е достапно при одбирање на постоечка задача.

Првиот прозорец од процесот е Job Settings каде се внесуваат општи информации за задачата како:

• Име на задачата за резервна копија
• Опис на задачата за резервна копија
• Полиса за чување на резервни копии

Кај полисите за чување на резервни копии потребно е да се дефинира бројот на точки или денови за чување на основните, инкрементални резервни копии. Опционално, доколку корисникот има потреба од чување на архивски резервни копии, може да се одбере опцијата Keep certain full backups longer for archival purposes.

Доколку се одбере опцијата за чување на архивски резервни копии, може да се дефинира времето на чување на:

• Неделни резервни копии и од кој ден во неделата да се земат неделните резервни копии
• Месечни резервни копии и од која недела да се земат месечните резервни копии
• Годишни резервни копии и од кој месец да се земат годишните резервни копии

Додавање на објекти во задача

Следниот прозорец од процесот на создавање на задача е додавањето на објектите на кои ќе се прави резервна копија. Објекти кои може да се вклучат за резервна копија се целата организација, виртуелни дата центри, виртуелни апликации или виртуелни машини. Со одбирање на објект се вклучуваат сите објекти надолу во хиерархијата, по следниот распоред: организација, виртуелен дата центар, виртуелна апликација, виртуелна машина. Пример, доколку се одбере виртуелен дата центар во задачата ќе се вклучат сите виртуелни апликации и нивните виртуелни машини. Покрај самите виртуелни машини како крајна инстанца од хиерархијата, при креирање на резервна копија на vApp се зачувуваат и параметрите од самиот vApp (мрежи, привилегии, редослед на стартување/гаснење итн.). Во примерот со виртуелниот дата центар, при креирање на нови виртуелни апликации со виртуелни машини во нив, истите автоматски ќе бидат вклучени во задачата.

Доколку се менува постоечка задача, тука ќе се прикажат постоечките објекти и можност за отстранување на објекти од задачата, менување на редоследот на извршување. Исто така постои можноста за exclusions на објекти, со цел исклучување на виртуелна апликација или виртуелна машина на која нема потреба да се креира резервна копија.

Со кликање на **+ Add ** од претходната слика се отвора нов прозорец каде корисникот може да ги види сите виртуелни дата центри, виртуелни апликации и виртуелни машини на корисникот, односно организацијата. Секој објект во хиерархијата под vCloud Organization може да биде одбран во задачата.

Напредна интеграција со апликации (опционален чекор)

Доколку корисникот нема потреба од Application-Aware Processing (AAP) или Guest File System Indexing, може да го прескокне овој чекор од процесот на конфигурација на задачата.

Application-Aware Processing овозможува интеграција на апликативно ниво во виртуелните машини, преку обработување на поддржаните апликации: Microsoft Active Directory, Microsoft Exchange, Microsoft SQL Server, Microsoft SharePoint и Oracle Database. За детални информации за поддржани апликации и нивните верзии, може да се прегледа официјалната документација од решението. Guest File System Indexing овозможува индексирање на сите податоци во оперативниот систем, а самата интеграција е неопходна за користење на опцијата за враќање на поединечни датотеки и директориуми од резервна копија.

За интеграцијата на апликативно ниво и индексирање на податоците, потребно е софтверот за резервна копија да има пристап во оперативниот систем и апликацијата која се штити. Преку интерфејсот за Backup VDC постои можност за додавање на параметри за најава во оперативниот систем и апликацијата во самите задачи, со што се одбегнува потребата од давање на пристап во системите на корисниците на администраторите на neoCloud. Параметрите за пристап се чуваат во криптирана база на податоци од софтверот каде немаат пристап администраторите на neoCloud, со што се гарантира изолација на корисничките системи од самиот давател на услугата.

Пристапот во оперативниот систем и апликации се дава преку дефинирање на параметри за пристап во Credentials делот од прозорецот.

Доколку се одбере опцијата за интеграција на апликативно ниво, потребно е да се постават параметри кои го дефинираат процесирањето на апликациите за секоја виртуелна апликација или виртуелна машина од задачата за резервна копија. Пред сѐ, потребно е да се додадат виртуелните апликации или машини кои ќе се процесираат на апликативно ниво со кликање на Add VM... и потоа да се дефинираат специфични параметри за процесирање на апликациите со одбирање на објектот и кликање на Edit копчето, како што е прикажано на следната слика.

Во прозорецот кој се отвора има четири табови:

• General - општи параметри за начинот на процесирање на апликациите
• SQL - параметри за процесирање на трансакциски логови кај SQL бази на податоци
• Oracle - параметри за процесирање на архивски логови кај Oracle бази на податоци
• File Exclusions - параметри за исклучување на датотеки и директориуми

Доколку во виртуелните машини има Microsoft Active Directory и Microsoft Exchange, нема потреба од дефинирање на параметри кај SQL и Oracle табовите. Кај SQL или Oracle апликациите, покај General табот, неопходна е конфигурација во соодветниот таб од прозорецот.

Во General табот се дефинираат следните параметри:

• Дали ќе се процесираат апликациите и дали во случај на грешки ќе се дозволи игнорирање на грешките или задачата ќе биде успешна само при успешно процесирање на апликацијата (предефинирана опција)
• Дали ќе се процесираат трансакциските логови од апликациите (предефинирана опција) или истите ќе бида процесирани од страна на друга апликација (пример SQL Maintenance Plan или Oracle RMAN)

Во SQL табот може да се одбере една од следните опции:

• Truncate logs - опција која ги обработува логовите од SQL базите на податоци, за истите да не растат. За оваа опција да се користи, потребно е базите да се во Full Recovery Model.
• Do not truncate logs - опција во која не се обработуваат логовите од SQL базите на податоци, каде е неопходно базите да се во Simple Recovery Model.
• Backup logs periodically - опција која овозможува редовен бекап на самиот трансакциски лог, независно од задачата за резервна копија на виртуелната машина. На овој начин се овозможува минимално влијание на SQL базите на податоци во случај на испад. Минималното време за бекап на трансакцискиот лог е 5 минути, се до максимални 480 минути (8 часа). Покрај времето на креирање на бекап, потребно е да се дефинира времето за чување на бекап од трансакцискиот лог. Една опција е чување додека е активен ланецот од резервните копии (кое во случајот на конфигурацијата со synthetic full на неделно ниво би значело чување 7 дена). Друга опција е дефинирање на стриктно време за чување на бекап од трансакцискиот лог, но не се препорачува интервалот да е повеќе од 7 дена.

Напомена: за успешно процесирање на SQL Server, потребно е параметрите за пристап во оперативниот систем да имаат и пристап во самиот SQL Server (SQL Login со неопходните привилегии како на пример backup operator). Доделувањето на привилегии во SQL е надвор од опсегот во оваа документација.

Во Oracle табот можа да се одбере една од следните опции:

• Do not delete archived log - опција каде се дефинира да не се брише архивскиот лог од Oracle базите на податоци
• Delete logs older than - опција за бришење на архивскиот лог од Oracle базите на податоци постари од одреден број на часови
• Delete logs larger than - опција за бришење на архивскиот лог од Oracle базите на податоци поголеми од одредена големина во GB.
• Backup logs every - опција која овозможува редовен бекап на самиот архивски лог, независно од задачата за резервна копија на виртуелната машина. На овој начин се овозможува минимално влијание на Oracle базите на податоци во случај на испад. Минималното време за бекап на архивскиот лог е 5 минути, се до максимални 480 минути (8 часа). Покрај времето на креирање на бекап, потребно е да се дефинира времето за чување на бекап од архивскиот лог. Една опција е чување додека е активен ланецот од резервните копии (кое во случајот на конфигурацијата со synthetic full на неделно ниво би значело чување 7 дена). Друга опција е дефинирање на стриктно време за чување на бекап од архивскиот лог, но не се препорачува интервалот да е повеќе од 7 дена.

Напомена: за успешно процесирање на Oracle, потребно е да се одберат соодветни параметрите за пристап, кои можат да бидат истите како во оперативниот систем доколку се доделени привилегии на тој кориснички налог или посебни параметри за пристап кои се дефинирани во само во Oracle. Доделувањето на привилегии во Oracle е надвор од опсегот во оваа документација.

Последниот таб од прозорецот овозможува исклучување на одредени датотеки и директориуми од резервна копија. Во полето за исклучување може да се внесат една од следните опции:

• Целосна патека до директориум, пример C:\Documents\
• Целосна патека до датотеки, пример C:\Documents\MyReport.docx
• Environmental variables, како на пример %TEMP%, %windir%
• Користење на следните маски за датотеки:
  • (*) - заменува еден или повеќе карактери во име или патека на датотека, пример *.pdf
  • (?) - заменува еден карактер во име или патека на датотека, пример repor?.pdf
  • (;) - сепаратор на маски кој може да се користи за низа на маски, како на пример report.*;reports.*.

Напомена: опцијата за исклучување на датотеки и директориуми од резервна копија е поддржана на Microsoft Windows NTFS систем на датотеки и се препорачува за исклучување на големи датотеки и директориуми (како на пример слики, видеа и слични содржини).

Доколку се одбере опцијата за индексирање на податоците во оперативниот систем, потребно е да се постават параметри со кои се дефинира кои податоци ќе се индексираат за секоја виртуелна апликација или виртуелна машина од задачата за резервна копија. Пред сѐ, потребно е да се додадат виртуелните апликации или машини кои ќе се индексираат со кликање на Add VM... и потоа да се дефинираат специфични параметри за индексирање преку одбирање на објектот и кликање на Edit копчето, како што е прикажано на следната слика.

Во прозорецот кој се отвора, може да се дефинираат специфични параметри за Windows и Linux оперативни системи каде треба да се индексираат податоците. Кај двата типови на оперативни системи, опциите се исти:

• Disable indexing за исклучување на индексирање кај одреден тип на оперативен систем, опција која се користи доколку во задачата има Windows и Linux оперативни системи а индексирањето треба да се изврши само кај еден тип на оперативен систем
• Index everything за индексирање на сите податоци во оперативниот систем
• Index everything except folders за индексирање на сите податоци освен оние директориуми каде не е потребно. Оваа опција се препорачува, особено бидејќи во листата се предефинирани директориуми и системски патеки каде навистина не е потребно да се индексираат податоците. На овој начин се забрзува извршувањето на задачата

Во полето Guest OS Credentials од Guest Processing чекорот од креирање/уредување на задачата потребно е да се одберат параметрите за пристап во оперативниот систем и апликациите кои ќе се процесираат од страна на задачата.

Со кликање на + Add копчето се прикажуваат две опции: Standard Account и Linux Account. Првата опција овозможува внесување на корисничко име и лозинка и се користи за внесување на креденцијали за Windows базирани системи. Втората опција се користи за Linux базирани оперативни системи, каде покрај можноста за внесување на корисничко име и лозинка може да се искористи опцијата за внесување на приватниот клуч за SSH сесија, како и опцијата за зголемување на привилегиите на корисничкиот профил на root ниво при извршување на задачата доколку внесените параметри не се на root ниво.

Со кликање на Edit копчето се овозможува менување на одбраните параметри за пристап.

Со одбирање на Customize Credentials, се отвора нов прозорец каде може да се додадат или тргнат виртуелни апликации или виртуелни машини на кои треба да им се аплицираат параметри за пристап, но важно е во оваа листа да бидат дефинирани сите објекти на кои ќе се врши апликативно процесирање или индексирање на податоците.

Копчето Set User... овозможува дефинирање на параметри за пристап за секоја виртуелна апликација или виртуелна машина од задачата, доколку параметрите се различни, како и одбирање на различни параметри за пристап кај Windows и Linux базирани оперативни системи.

Распоред на извршување

Следниот чекор од креирање на задачата е дефинирање на распоредот на извршување, односно пред се дали задачата ќе се извршува автоматски или само доколку се стартува рачно од страна на корисникот. Доколку се одбере опцијата за автоматско извршување, може да се одбере една од следните опции:

• Daily at this time - за извршување на задачата во одредено време од денот, со можност за одбирање за извршување секој ден, работни денови или одбирање на специфични денови
• Monthly at - за извршување на месечно ниво, преку дефинирање на времето и специфичниот ден од месецот, како и кои месеци ќе се извршува задачата
• Periodically every - за повремено извршување на задачата во текот на денот, со можност за бирање на колку минути или часови ќе се извршува задачата или одбирање на continuous опцијата која овозможува непрекинато извршување на задачата (штом заврши едно извршување, веднаш започнува ново)
• After this job - за извршување на задачата по завршување на некоја претходно дефинирана задача

Во поголемиот дел од случаи за дефинирање на распоредот за извршување, препораката е да се користи првата опција за дневно извршување а времето на извршување да се дефинира по полноќ или во вечерните часови.

Во случај на појава на грешки при извршување на задачата, постои можност дефинирање на повторен обид за извршување. Параметрите од 3 обиди за повторно извршување и време на чекање пред повторното извршување од 10 минути се предефинирани вредности.

На кај, доколку се одберат опциите за периодично и непрекинато извршување или извршувањето треба да се прекине заради критичен временски интервал од денот за виртуелната апликација или машина, може да се дефинира Backup window кога е дозволено и забрането извршување.

Известувања преку електронска пошта

Последниот чекор од процесот на создавање на задачата е овозможување на опцијата за известување за статусот на задачата преку електронска пошта. Ако се овозможи оваа опција, потребно е да се внесе e-mail адреса или низа на адреси и да се одберат условите за известување. Препорака е известувањето да се врши при појава на предупредување или грешка во извршувањето на задачата, како што е прикажано на следната слика. Насловот на пораката е предефиниран и нема потреба да се менува, освен колку корисникот сака да ја промени содржината на насловот од пораката.

Со кликање на Finish копчето за завршува создавањето или менување на задачата за резервна копија.

Преглед на статус и известување

При автоматско или рачно извршување на задачата, се менува статусот на задачата во Working.

Како што е прикажано во темата Најава и навигација на порталот, ова поле може да се кликне за да се прикаже деталниот статус за тековното извршување на задачата и сите објекти кој се наоѓаат во истата.

Доколку е одбрана опцијата за известување по електронска пошта, корисникот ќе добие известување како што е прикажано на следната слика. Во пораката ги има сите неопходни информации како преглед на успешни и неуспешни објекти, време на извршување, големина на податоци, но и детални дијагностички информации доколку има предупредување или грешка кои можат да помогнат во надминување на проблемот.

Пример, кај demo1 виртуелната машина, која е Linux базирана, може да се забележи дека индексирањето не е успешно бидејќи недостасува mlocate пакетот во оперативниот систем. Со инсталација на истиот, следното извршување на задачата е успешно.