Готово резервно копие: разбиване на митове в чест на празника

Архивирането не е от модерните технологии, за които се крещи от всяка ютия. Просто трябва да е във всяка сериозна компания, това е всичко. Ние архивираме няколко хиляди сървъра в нашата банка - това е сложна, интересна работа, някои от тънкостите на която, както и типичните погрешни схващания за архивирането, просто искаме да бъдат разказани.

Работя по тази тема почти 20 години, от които последните 2 години бяха в Promsvyazbank. В самото начало на практиката правех резервни копия почти ръчно, със скриптове, които просто копираха файлове. След това в Windows се появиха удобни инструменти: помощната програма Robocopy за подготовка на файлове и NT Backup за копиране. И едва тогава дойде времето за специализиран софтуер, предимно Veritas Backup Exec, който сега се нарича Symantec Backup Exec. Така че съм запознат с архивирането от дълго време.

С прости думи, архивирането е запазване на копие на данни (виртуални машини, приложения, бази данни и файлове) за всеки случай с определена редовност. Всеки случай обикновено се проявява като хардуерен или логически срив и води до загуба на данни. Целта на резервната система е да намали загубата на информация. Хардуерна повреда е например повреда на сървъра или хранилището, където се намира базата данни. Логично - това е загубата или промяната на част от данните, включително поради човешкия фактор: те случайно изтриха таблица, файл, стартираха крив скрипт за изпълнение. Има и регулаторни изисквания за съхраняване на определен тип информация за дълъг период от време, например до няколко години.

Най-типичното използване на резервни копия е възстановяването на запазено копие на бази данни за внедряване на различни тестови системи, клонинги за разработчици.

Има няколко типични мита около архивирането, които отдавна трябва да бъдат разсеяни. Ето най-известните от тях.

Мит 1. Архивирането отдавна е само малка функция в системите за сигурност или съхранение

Системите за архивиране все още остават отделен клас решения и много независими. Имат твърде много работа. Всъщност те са последната линия на защита, когато става въпрос за целостта на данните. Така архивирането работи със собствено темпо, по собствен график. Ежедневно се генерира отчет за сървърите, има събития, които действат като тригери за системата за мониторинг.

Освен това моделът за подражание на достъп до системата за архивиране ви позволява да делегирате част от правомощията на администраторите на целевите системи за управление на архиви.

Мит 2. Когато има RAID, вече не е необходимо архивиране.

Несъмнено RAID масивите и репликацията на данни са добър начин за защита на информационните системи от хардуерни повреди, а ако имате резервен сървър, можете бързо да организирате превключване към него в случай на повреда на основната машина.

От логическите грешки, направени от потребителите на системата, излишъкът и репликацията не спестяват. Ето резервен сървър за обратно записване - да, може да помогне, ако бъде открита грешка, преди да бъде синхронизиран. А ако моментът е пропуснат? Само навременно архивиране ще помогне тук. Ако знаете, че данните са се променили вчера, можете да възстановите системата до предишния ден и да извлечете необходимите данни от нея. Предвид факта, че логическите грешки са най-често срещаните, добрият стар бекъп си остава доказано и необходимо средство.

Мит 3. Архивирането е нещо, което се прави веднъж месечно.

Честотата на архивиране е конфигурируема настройка, която зависи основно от вашите системни изисквания за архивиране. Напълно възможно е да намерите данни, които почти никога не се променят и не са особено важни, загубата им няма да бъде критична за компанията.
Те наистина могат да бъдат архивирани веднъж месечно и дори по-рядко. Но по-критичните данни се записват по-често в зависимост от индикатора RPO (Recovery point jrective), който задава допустимата загуба на данни. Това може да бъде веднъж седмично, веднъж на ден или дори няколко пъти на час. Имаме тези журнали на транзакции от СУБД.

Когато системите бъдат пуснати в търговска експлоатация, трябва да бъде одобрена документацията за архивиране, която отразява основните моменти, процедурата за актуализиране, процедурата за възстановяване на системата, процедурата за съхраняване на резервни копия и други подобни.

Мит 4. Обемът на копията непрекъснато нараства и заема изцяло отделеното място.

Резервните копия имат ограничен период на съхранение. Няма смисъл, например, да съхранявате всичките 365 ежедневни архива през годината. Като правило е приемливо да се съхраняват ежедневни копия в продължение на 2 седмици, след което те се заменят с нови, а версията, която е направена първа през месеца, остава в дългосрочно съхранение. То от своя страна също се съхранява за определено време – всяко копие има цял живот.

Има защита срещу загуба на данни. Важи правилото: преди да се изтрие резервно копие, трябва да се създаде следващото. Следователно данните няма да бъдат изтрити, ако архивирането не е завършено, например поради недостъпност на сървъра. Спазват се не само времеви рамки, но и се контролира броят на копията в комплекта. Ако системата е проектирана да има два пълни архива, винаги ще има два, а старият ще бъде изтрит само при успешно записване на нов трети. Така нарастването на обема, зает от резервния архив, е свързано само с нарастването на количеството защитени данни и не зависи от времето.

Мит 5. Архивирането започна - всичко увисна

По-добре е да кажете това: ако всичко виси, тогава ръцете на администратора не растат оттам. Като цяло ефективността на архивирането зависи от много фактори. Например за скоростта на самата система за архивиране: колко бързи са дисковите хранилища, лентовите библиотеки. От скоростта на сървърите на системата за архивиране: дали имат време да обработват данни, да извършват компресия и дедупликация. А също и върху скоростта на комуникационните линии между клиента и сървъра.

Архивирането може да отиде в един или повече потоци, в зависимост от това дали системата, която се архивира, поддържа многопоточност. Например СУБД на Oracle ви позволява да зададете множество нишки, според броя на наличните процесори, докато скоростта на трансфер достигне лимита на честотната лента на мрежата.

Ако се опитате да архивирате голям брой нишки, тогава има шанс да претоварите работеща система, тя наистина ще започне да се забавя. Следователно оптималният брой нишки е избран, за да се осигури достатъчна производителност. Ако дори най-малкото намаляване на производителността е критично, тогава има отлична опция, когато архивирането се извършва не от боен сървър, а от неговия клонинг - режим на готовност в терминологията на базата данни. Този процес не зарежда основната работна система. Данните могат да бъдат извлечени чрез повече потоци, тъй като сървърът не се използва за поддръжка.

В големите организации се създава отделна мрежа за системата за архивиране, така че архивирането да не влияе на производството. Освен това трафикът може да не се предава през мрежата, а през SAN.

Опитваме се да разпределим товара и във времето. Архивирането се извършва предимно в извънработно време: през нощта, през почивните дни. Освен това не всички те работят по едно и също време. Архивирането на виртуални машини е специален случай. Процесът практически няма ефект върху производителността на самата машина, така че архивирането може да се разпредели през деня и да не се отлага всичко през нощта. Има много тънкости, ако вземете всичко предвид, архивирането няма да повлияе на производителността на системите.

Мит 6. Пуснахте резервна система - това е толерантност към грешки за вас

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

Надявайки се, че резервното копие ще възстанови всички данни и бързо ще повдигне падналата услуга, не си струва. Загубата на данни от момента на архивиране до момента на повреда е гарантирана и данните могат да бъдат качени на нов сървър за няколко часа (или дни, ако имате късмет). Следователно има смисъл да се създават пълноценни системи, устойчиви на грешки, без да се прехвърля всичко към резервно копие.

Мит 7. Настроих резервно копие веднъж, проверих дали работи. Остава само да погледнете дневниците

Това е един от най-вредните митове, чиято фалшивост разбирате едва по време на инцидента. Успешните резервни регистрационни файлове не са гаранция, че всичко наистина е минало както трябва. Важно е предварително да проверите запазеното копие за разгръщане. Тоест стартирайте процеса на възстановяване в тестова среда и вижте резултата.

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

В ръчен режим никой не копира данни от дълго време. Съвременните SRK могат да архивират почти всичко, просто трябва да го настроите правилно. Ако е добавен нов сървър, задайте правила: изберете съдържанието, което ще бъде архивирано, задайте опции за съхранение и приложете графика.

В същото време все още има много работа поради обширния набор от сървъри, включително бази данни, пощенски системи, клъстери на виртуални машини и споделени файлове както на Windows, така и на Linux / Unix. Служителите, които поддържат работата на резервната система, не стоят без работа.

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

Източник: www.habr.com