Резервното копиране не е модна технология, за която всеки говори на всеки ъгъл. То просто трябва да бъде част от всяка сериозна компания, и толкова. В нашата банка резервират хиляди сървъри – това е сложна и интересна работа, за която бих искал да разкажа за някои нюанси и типични заблуждения относно резервните копия.
Занимавам се с тази тематика почти 20 години, от които последните 2 години – в Промсвязьбанк. В началото започвах да правя резервни копия почти ръчно, със скриптове, които просто копираха файлове. После в Windows се появиха удобни инструменти: утилитата Robocopy за подготвяне на файлове и NT Backup за копиране. А след това дойде времето за специализираен софтуер, най-вече Veritas Backup Exec, който сега се нарича Symantec Backup Exec. Така че запознат съм с резервните копия отдавна.
Ако трябва да обясня по-просто, резервното копиране е запазването на копие на данни (на виртуални машини, приложения, бази данни и файлове) за всеки случай с определена редовност. Всеки случай обикновено се проявява като хардуерен или логически проблем, което води до загуба на данни. Задачата на системата за резервно копиране е да намали загубите от загуба на информация. Хардуерен проблем е, например, отказ на сървър или хранилище, където се съхранява базата данни. Логически – това е загуба или промяна на част от данните, включително поради човешки фактор: случайно изтриване на таблица, файл или стартиране на грешен скрипт. Съществуват и изисквания на регулаторите за съхранение на определен тип информация за дълъг период, например до няколко години.
Най-тихий начин за използване на резервни копия е възстановяването на запазено копие на бази данни за изграждане на различни тестови системи или клони за разработчиците.
Около резервното копиране съществуват няколко типични мита, които отдавна е време да се развенчаят. Ето най-известните от тях.
Мит 1. Резервното копиране отдавна е само малка функция в системите за сигурност или съхранение.
Системите за резервно копиране все още остават отделен клас решения, и изключително независими. Те са отговорни за твърде важна задача. По същество, те са последната линия на защита, когато става въпрос за запазване на данни. Така резервното копиране работи в собствен ритъм, по свое собствено разписание. Всеки ден се генерира отчет за сървърите и има събития, които служат за триггери за системата за мониторинг.
Плюс ролевия модел за достъп до системата за резервно копиране позволява делегирането на част от правомощията на администраторите на целевите системи за управление на резервните копия.
Мит 2. Когато имате RAID, резервното копиране вече не е необходимо.
Безспорно, RAID масивите и репликирането на данни са добър начин за защита на информационните системи от хардуерни повреди, а при наличие на standby сървър — бързо организиране на превключване на него в случай на повреда на основната машина.
От логически грешки, допуснати от потребителите на системата, излишността и репликацията не спасяват. Ето го standby сървъра с отложено записване – да, може да помогне, ако грешката бъде открита преди да е синхронизирана. А ако моментът е пропуснат? Тук може да помогне само направеното навреме резервно копие. Ако знаем, че данните са се променили вчера, можем да възстановим системата до състоянието от онзи ден и да извлечем нужните данни. С оглед на това, че логическите грешки са най-чести, старото добро резервно копие остава проверено и необходимо средство.
Мит 3. Резервното копие е нещо, което се прави веднъж месечно.
Честотата на резервното копиране е настраиваем параметър, който главно зависи от изискванията към системата за резервно копиране. Напълно реално е да намерим данни, които практически никога не се променят и особено не са важни, а загубата им няма да бъде критична за фирмата.
Наистина, те могат да се копират веднъж месечно и дори по-рядко. А по-критичните данни се съхраняват по-често, в зависимост от показателя RPO (Recovery Point Objective), задаващ допустимата загуба на данни. Това може да бъде веднъж седмично, веднъж дневно или дори няколко пъти на час. При нас това са журналите на транзакции от СУБД.
При въвеждане на системи в промишлена експлоатация задължително се одобрява документацията за резервно копие, в която са отразени основните моменти, регламентът за обновление, редът за възстановяване на системата, редът за съхранение на резервните копия и други.
Мит 4. Обемът на копията непрекъснато нараства и заема всяко предоставено пространство напълно.
Резервните копия имат ограничен срок на съхранение. Няма смисъл, например, да се складират през цялата година всички 365 ежедневни резервни копия. По правило е допустимо да се съхраняват ежедневни копия за 2 седмици, след което се заменят с нови, а на дългосрочно съхранение остава версията, която е направена първа в месеца. Тя също така се съхранява определено време – всяко копие има свой жизнен цикъл.
Съществува защита от загуба на данни. Действа правилото: преди резервното копие да бъде изтрито, трябва да бъде създадено следващото. Следователно данните няма да бъдат изтрити, ако резервното копие не е изпълнено, например, поради недостъпност на сървера. Спазват се не само времевите рамки, но и се контролира броят на копията в набора. Ако в системата е заложено, че трябва да има две пълни резервни копия, те винаги ще бъдат две, и старото ще бъде изтрито само когато успешно се запише ново трето. Така че растежът на обема, зает от архива на резервните копия, е свързан само с увеличаването на защитаваните данни и не зависи от времето.
Мит 5. Започна резервното копие – всичко замръзна.
По-добре е да кажем така: ако всичко е замръзнало, значи ръцете на администратора не са от там, откъдето трябва. Всъщност бързодействието на резервното копие зависи от много фактори. Например, от бързодействието на самата система за резервно копиране: колко бързи са дисковите хранилища и ленточните библиотеки. От бързодействието сървъри на системата за резервно копиране: успяват ли да обработват данни, да извършват компресия и дедупликация. А също и от скоростта на комуникационните линии между клиента и сървера.
Резервното копие може да се извършва в един или няколко потока, в зависимост от това дали резервираната система поддържа многопоточност. Например, СУБД Oracle позволява да се отдават няколко потока, в зависимост от броя на наличните процесори, докато скоростта на предаване не достигне лимита на пропускната способност на мрежата.
Ако се опитвате да правите бекъп с много нишки, има шанс да пренасите работещата система, и тя наистина ще започне да забавя. Затова се избира оптималният брой нишки, за да се осигури достатъчна производителност. Ако е критично дори най-малкото намаление на производителността, има отличен вариант, когато бекъпът се прави не от продуктивния сървър, а от неговия клон – standby в терминологията на базите данни. Този процес не натоварва основната работна система. Данните могат да се подбират чрез повече нишки, тъй като сървърът не се използва за обслужване.
В големите организации за системата за резервно копиране се създава отделна мрежа, за да не влияе бекъпът на продуктивната среда. Освен това, трафикът може да се предава не през мрежата, а през SAN.
Ние се стараем да разпределяме натоварването и по време. Бекъпите предимно се извършват в неработно време: през нощта, в уикендите. Освен това, те не се стартират всички едновременно. Бекъпите на виртуални машини са особен случай. Процесът практически не оказва влияние на производителността на самата машина, затова бекъпът може да се разпределя през дневното време, а не да се отлага всичко за нощта. Има много нюанси, но ако се вземат под внимание, резервното копиране няма да повлияе на производителността на системите.
Мит 6. Стартирах системата за резервно копиране – ето ти отказоустойчивост.
Никога не забравяйте, че системата за бекъп е последната линия на защита, а пред нея трябва да има още няколко системи, които осигуряват непрекъснатост, висока достъпност и устойчивост на бедствия на ИТ инфраструктурата и информационните системи на предприятието.
Не си струва да се надявате, че бекъпът ще възстанови всички данни и бързо ще поднови падналия сервис. Загубата на данни от момента на бекъпа до момента на повредата е гарантирана, а данните на новия сървър могат да се прехвърлят за няколко часа (или дни, каквото зависи). Затова има смисъл да се създадат пълноценни отказоустойчиви системи, без да се прехвърля всичко на бекъпа.
Мит 7. Настроил съм веднъж бекъп, проверил съм, че работи. Остава само да гледам логовете.
Това е един от най-вредните митове, чиято фейкност осъзнаваш само по време на инцидент. Логовете за успешно създаване на бекъп не гарантират, че всичко наистина е прошло както трябва. Важно е предварително да провериш запазеното копие за възстановимост. Тоест, да стартираш процеса на възстановяване в тестова среда и да видиш резултата.
И малко за работата на системния администратор
В ръчен режим никой не копира данни отдавна. Съвременните СРК могат да бекъпват практически всичко, просто трябва да се настроят правилно. Ако се добави нов сървър, трябва да се опишат политиките: да се избере съдържанието, което ще се бекъпва, да се зададат условия за съхранение и да се приложи график.
Въпреки това работата все пак не е малко, поради многото сървъри, сред които и бази данни, и имейл системи, и клъстери на виртуални машини, и файлови ресурси както на Windows, така и на Linux/Unix. Служителите, които поддържат работоспособността на системата за резервно копиране, не седят без работа.
В чест на празника искам да пожелая на всички администратори крепки нерви, точност в действията и безкрайно пространство за съхранение на бекъпове!
Източник: habr.com
