Резервна копија на готовс: разбивање на митовите во чест на празникот

Резервната копија не е една од модерните технологии за која сите викаат. Едноставно треба да биде во која било сериозна компанија, тоа е сè. Нашата банка прави резервна копија од неколку илјади сервери - ова е сложена, интересна работа и би сакал да зборувам за некои од сложеноста на тоа, како и за типични заблуди во врска со резервните копии.

Работам на оваа тема скоро 20 години, од кои последните 2 години беа во Promsvyazbank. На самиот почеток на мојата пракса, правев резервни копии речиси рачно, користејќи скрипти кои едноставно копираат датотеки. Потоа во Windows се појавија практични алатки: алатката Robocopy за подготовка на датотеки и NT Backup за копирање. И дури тогаш дојде време за специјализиран софтвер, првенствено Veritas Backup Exec, кој сега се нарекува Symantec Backup Exec. Така, јас сум запознаен со резервните копии долго време.

Едноставно, резервната копија е зачувување на копија од податоци (виртуелни машини, апликации, бази на податоци и датотеки) за секој случај со одредена регуларност. Секој случај обично се манифестира во форма на хардверски или логички дефект и доведува до губење на податоци. Целта на резервниот систем е да ги намали загубите од загубата на информации. Хардверски дефект е, на пример, дефект на серверот или складиштето каде што се наоѓа базата на податоци. Логично е губењето или промената на дел од податоците, вклучително и поради човечкиот фактор: табела или датотека беше случајно избришана или скрипта беше лансирана за да се изврши крива топка. Исто така, постојат регулаторни барања за складирање на одредени видови информации за долг период, на пример, до неколку години.

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

Постојат неколку вообичаени митови околу резервната копија кои одамна треба да се отфрлат. Еве ги најпознатите од нив.

Мит 1. Резервната копија одамна е само мала функција во безбедносните или системите за складирање

Резервните системи сè уште остануваат посебна класа на решенија и многу независни. Ним им е доверена премногу важна задача. Во суштина, тие се последната линија на одбрана кога станува збор за безбедноста на податоците. Значи, резервната копија работи со свое темпо, по свој распоред. На серверите се генерира дневен извештај.

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

Мит 2. Кога има RAID, резервната копија повеќе не е потребна

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

Вишокот и репликацијата не ве спасуваат од логички грешки направени од корисниците на системот. Еве сервер на подготвеност со одложено снимање - да, може да помогне ако се открие грешка пред да се синхронизира. Што ако моментот се пропушти? Само навремената резервна копија ќе помогне овде. Ако знаете дека податоците се сменија вчера, можете да го вратите системот од завчера и да ги извлечете потребните податоци од него. Имајќи предвид дека логичките грешки се најчести, старата добра резервна копија останува докажана и неопходна алатка.

Мит 3. Резервната копија е нешто што се прави еднаш месечно.

Фреквенцијата на резервната копија е параметар што може да се конфигурира кој првенствено зависи од барањата на системот за резервна копија. Сосема е можно да се најдат податоци кои речиси никогаш не се менуваат и не се особено важни, нивната загуба нема да биде критична за компанијата.
Навистина, може да се направи резервна копија еднаш месечно или уште поретко. Но, покритичните податоци се зачувуваат почесто, во зависност од индикаторот RPO (Objrective на точката за обновување), кој ја поставува прифатливата загуба на податоци. Ова може да биде еднаш неделно, еднаш дневно, па дури и неколку пати на час. За нас, ова се дневници за трансакции од DBMS.

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

Мит 4. Обемот на копии постојано расте и целосно го зафаќа секој доделен простор

Резервните копии имаат ограничен рок на траење. Нема смисла, на пример, да се складираат сите 365 дневни резервни копии во текот на годината. Како по правило, дозволено е да се чуваат дневни копии 2 недели, по што се заменуваат со свежи, а за долгорочно складирање останува верзијата што е направена прва во месецот. Тој, пак, исто така се чува одредено време - секоја копија има цел живот.

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

Мит 5. Кога ќе започне резервната копија, сè замрзнува

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

Резервната копија може да оди во една или повеќе нишки, во зависност од тоа дали системот за резервна копија поддржува повеќенишки. На пример, Oracle DBMS ви овозможува да испратите неколку нишки, според бројот на достапни процесори, додека брзината на пренос не ја достигне границата на мрежната пропусност.

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

Во големите организации, се создава посебна мрежа за резервниот систем, така што резервната копија не влијае на производството. Покрај тоа, сообраќајот може да се пренесува не преку мрежата, туку преку SAN.

Ние, исто така, се обидуваме да го дистрибуираме товарот со текот на времето. Резервните копии најчесто се прават за време на неработни часови: ноќе, за време на викендите. Исто така, не започнуваат сите во исто време. Резервните копии на виртуелната машина се посебен случај. Процесот практично нема никакво влијание врз перформансите на самата машина, така што резервната копија може да се шири во текот на денот, наместо да се одложува сè ноќе. Има многу суптилности, ако земете сè во предвид, резервната копија нема да влијае на перформансите на системот.

Мит 6. Лансираше резервен систем - тоа е толеранција на грешки за вас

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

Нема смисла да се надеваме дека резервната копија ќе ги врати сите податоци и брзо ќе ја врати паднатата услуга. Губењето на податоците од моментот на резервна копија до моментот на неуспех е загарантирано, а податоците може да се прикачат на нов сервер неколку часа (или денови, во зависност од вашата среќа). Затоа, има смисла да се создадат полноправни системи толерантни за грешки без да се префрла сè на резервна копија.

Мит 7. Еднаш поставив резервна копија и проверив дали работи. Останува само да се погледнат дневниците

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

И малку за работата на системскиот администратор

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

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

Во чест на празникот, на сите администратори би сакал да им посакам силни нерви, чисти движења и бесконечен простор за складирање резервни копии!

Извор: www.habr.com