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