Типові помилки бекапа і як їх уникнути

Про роботу з резервними копіями написано багато статей. Здавалося б, основні принципи бекапа не змінюються вже багато років, але вся справа в деталях цього процесу. На практиці навіть у досвідчених адмінів зустрічаються помилки, які вони вважають «не батогом, а фичей» і продовжують повторювати.


У айтишном фольклорі є хороша приказка: «Адміни діляться на тих, хто не робить бекапи, і тих, хто вже робить». Однак сьогодні компанія будь-якого профілю активно використовує десятки програм і онлайнових служб, тому просто створювати резервні копії вже недостатньо. Тривала недоступність загальної бази, звичних засобів зв'язку і клієнтських сервісів може призвести до порушення роботи всієї системи корпоративних комунікацій і великих збитків.
У цій статті ми розглянемо типові помилки при створенні резервних копій і способи звести ймовірність їх появи до мінімуму.

1. Створення бекапів вручну
Цей метод широко використовувався в дев'яностих і відповідав завданням свого часу. Суть його проста: адмін робить бекап коли зможе, намагаючись по можливості дотримуватися наміченого графіка. Всі або майже всі завдання резервного копіювання при цьому виробляються вручну. Спочатку підключається сховище бекапів або перевіряється його доступність мережі. Потім запускається програма для створення резервних копій. У ній задаються потрібні каталоги на джерелі і параметри операції. Просунуті адміни використовують часткову автоматизацію (шаблони, скрипти, пакетні файли), але навіть з ними багато потрібно виконувати і контролювати вручну.

Сьогодні практика ручного створення бекапів призводить до низької надійності системи резервного копіювання. Один з її ключових показників – RPO (Recovery Point Objective), стає неприпустимо високим. Він відображає період, за який може статися невідновна втрата даних. З часу останнього бекапа до виникнення збою виявляються втрачені найновіші та найактуальніші для поточної роботи файли. Єдиний спосіб знизити втрати – робити бекапи частіше (кілька разів на день), але створювати їх так часто вручну просто неможливо.

2. Збереження бекапів без їх перевірки
Наявність резервної копії ще не гарантує можливість відновлення з неї.
Процедура створення бекапів зазвичай триває довго, і адміни не хочуть витрачати додатковий час на їх перевірку. Нехтування валідацією резервних копій часто призводить до того, що останній бекап з якоїсь причини виявляється пошкодженим. Тоді показник RPO погіршується вдвічі, оскільки доводиться використовувати попередній (старий) бекап, і добре, якщо він взагалі є.

Тому в Acronis Backup (Advanced) перевірка резервної копії файлів може виконуватися автоматично після створення кожного бекапа або запуску за розкладом. Під час перевірки імітується процедура відновлення всіх файлів з резервної копії в фіктивну папку. При перевірці бекапа всього диска або тому обчислюється контрольна сума для кожного блоку даних, збережених в резервної копії.

3. Перезапис існуючих даних при відновленні з пошкодженого бекапа
Бекапи записуються блоками. Якщо контрольні суми цих блоків збігаються, то резервна копія вважається створеною успішно. При цьому самі дані у бекапі не перевіряються. Вони спочатку можуть зчитуватися пошкодженими і збережуться в такому вигляді. При спробі відновити з бекапа відбувається перезапису оригінальних файлів, що посилює проблему. Вихідні файли більше не відновити, оскільки нові мають ті ж самі імена і виявилися пошкоджені. Тому є сенс робити проміжний бекап вже після збою і до початку процедури відновлення з резервної копії. Так зберігається можливість відкотиться і при необхідності виконати часткове відновлення файлів з різних бекапів.

4. Відсутність контролю за вільним місцем для бекапа
Ця проблема особливо характерна для ручного створення резервних копій. По мірі зростання обсягу вихідних даних для їх повного бекапа потрібно усе більше місця. В якийсь момент така копія не вміщується в об'єм, що залишився, і тривалий процес її створення завершується з помилкою. Часто така ситуація викликає цілий каскад нових помилок. Наприклад, для збільшення вільного місця адмін може видалити один з колишніх бекапів і помилково вибрати не той. Щоб уникнути подібних ситуацій, Acronis Backup (Advanced) можна створювати плани резервного копіювання і вказувати час життя кожного бекапа. Старі будуть автоматично видалятися після того, як втратять актуальність.

5. Видалення попередньої копії бекапа до того, як буде створена нова
Для надійності кожен момент часу рекомендується мати хоча б дві повних резервних копій. При ручній очистці сховища бекапів є ризик, що адмін випадково видалить самий новий замість самого старого, зітре часткові бекапи і порушить схему диференціального або інкрементного копіювання. Якщо відбудеться збій в той момент, коли останній бекап вже видалений для звільнення місця, а новий ще не створено, то параметр RPO погіршиться як мінімум втричі. Доведеться робити відкат на більш стару копію і миритися з втратою всього, що було створено за останній час.

Які з усього сказаного вище можна зробити висновки?
Найпоширеніші помилки бекапа виникають під впливом людського фактора. Тому сучасні програми для резервного копіювання розвиваються по шляху все глибшої автоматизації рутинних дій. Вони враховують особливості сучасних практичних завдань і дозволяють звести ймовірність помилки до мінімуму. Більш детально висновки я сформулюю у своїй наступній статті.

Корисні посилання:
» Вебінари по бэкапу та захисту даних
» Демоверсія для бекапа корпоративних серверів Acronis Backup Advanced

Не забувайте бэкапиться вчасно, Друзі!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.