1. Основні критерії вибору програми для бекапів
2. Повний бекап (full backup)
3. Інкрементальний, або інкрементний, бекап (incremental backup)
4. Диференціальний бекап (differential backup)

Про резервне копіювання останнім часом багато говорять і пишуть. І ми, SIM-Networks, в тому числі. :)

Це не дивно: з огляду на активний розвиток зловредів, випереджальний розвиток антивірусів, найбільш раціонально будувати ІТ-безпеку навколо системи резервного збереження інформації - замість того, щоб витрачати ресурси на запобігання атак і боротьбу з вірусами, набагато простіше, дешевше і легше підняти систему і збережені дані з актуальних резервних копій.

Крім того, актуальний бекап допоможе нівелювати наслідки втручання форс-мажорних обставин або людського фактора, а також збій обладнання внаслідок різних причин. Адже не дарма одна із заповідей сисадміна говорить: готуючи новий сервер до роботи, спочатку настрій резервне копіювання!

Бекап можна робити самостійно - інструментів на сьогоднішній день вистачає, Google із задоволенням підкаже. Але якщо ви не є крутим профі в області системного адміністрування, краще довіритися тим, хто компетентний і здатний налаштувати резервне копіювання, повністю відповідаючи за результат.

Дуже важливо звернути увагу на два моменти: копії критичною для вас інформації повинні робитися регулярно, а зберігатися - в віддаленому місці, як можна далі від оригіналів.

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

Важливість другого моменту можна проілюструвати так: якщо ваше резервне сховище для бекап-копій розміщується, припустимо, на тому ж сервері, де і основна система, то в разі, якщо сервер згорить - згорить дійсно все. Остаточно і безповоротно.

Тому дбаємо про правильне розкладі резервного копіювання та забезпечуємо віддаленість сховища для резервних копій.

Основні критерії вибору програми для бекапів

У тому випадку, якщо ви все-таки хочете ризикнути і самостійно зайнятися організацією резервного копіювання ваших даних, в пошуку програми для бекапів експерти рекомендують керуватися чотирма універсальними критеріями:

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

Варто відзначити, що сучасне ПО, що використовується професійними адміністраторами, завжди відповідає цим критеріям. Крім того, люди, спеціально навчені і мають за плечима багатий і різноманітний досвід налаштування резервного копіювання, можуть підібрати найбільш оптимальний варіант бекапа для кожного конкретного випадку. Тому все-таки настійно рекомендуємо звертатися за допомогою до фахівців, щоб не було потім болісно боляче від затертих правильних копій (так буває, якщо обраний невідповідний метод копіювання і занадто малий обсяг резервної СГД), поверх яких записується помилкова інформація, відновлення якої не принесе вам бажаного результату.

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

Повний бекап (full backup)

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

Трохи врятує ситуацію механізм дедуплікаціі - виявлення і видалення дубльованих даних в повних копіях. Він також задається спеціальними програмними засобами як на рівні СГД або сервера, так і на клієнті безпосередньо. Статистика в деяких джерелах призводить вражаючі результати ступеня дедуплікаціі - від 90% до 98%.

Перевагою повного бекапа можна назвати хіба що швидкість відновлення: коли дані піднімаються з одного архіву, це відбувається швидше, ніж при Інкрементальний або диференційований бекапе.

На сьогоднішній день метод повного резервного копіювання, як правило, використовується виключно як базовий в поєднанні з іншими методами, менш ресурсоємними. Іноді такий підхід називають ще змішаним або синтетичним бекапом.

Інкрементальний, або інкрементний, бекап (incremental backup)

У порівнянні з full backup набагато економічніше і швидше, оскільки в цьому процесі копіюються тільки ті файли, які змінилися з часу попереднього резервного копіювання. Механізм інкрементального копіювання простий: в якості початкової точки бекапа Х0 зазначається термін (наприклад, опівночі з неділі на понеділок), в яке робиться повний бекап; в точці Х1 (опівночі з понеділка на вівторок) робиться копіювання файлів, змінених і / або з'явилися з моменту Х0; в точці Х2 (опівночі з вівторка на середу) копіюються файли, змінені / з'явилися з моменту виконання Х1; ... в точці Хn відбувається завершення циклу і робиться наступний повний бекап.

Цей метод набагато більш економічно витрачає ресурси і місця в сховищі, і часу, і трафіку передачі даних, в порівнянні з іншими. Однак при відновленні даних в разі необхідності з резервної копії відбувається поетапне відновлення з точок Хn-1 ... Х2, Х1, Х0 - до останнього повного резервного копіювання включно, і цей процес може зайняти багато часу.

Диференціальний бекап (differential backup)

Виграє перед інкрементального в разі відновлення даних - час на цю операцію у нього менше, оскільки порівнюються повні копії Х0 і Хn і не потрібно поетапного відновлення. Однак в частині обсягу простору для розміщення в СГД диференціальне резервне копіювання можна порівняти з повним, тому економії місця в сховищі і трафіку практично не досягається.

При диференціальному бекапе відбувається копіювання «наростаючим підсумком»: кожен змінений файл у кожній наступній точці бекапа копіюється заново. Тобто виглядає це як: Х0, Х1, Х1 + Х2, Х1 + Х2 + Х3, ... + Хn, Х0 + Х (1 + ... n)

Словом, дуже громіздко і складно при розрахунку місця в СГД.

Зрозуміти різницю між інкрементального і диференціальним бекапом досить просто. Фактично - вона в одному слові. Просто порівняйте:

• інкрементальний бекап обробляє файли, змінені або створені з моменту виконання попереднього бекапа;
• диференційний бекап обробляє файли, змінені або створені з моменту виконання попереднього повного бекапа.

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

Його відрізняє висока швидкість створення, крайня економія місця і значно менше (в порівнянні з інкрементального і диференціальним бекапіть) кількість надлишкових даних. Здавалося б, застосовувати дельту повинні все, але цього не відбувається, оскільки створення резервних копій таким способом і відновлення інформації відбувається засобами спеціального ПО. Крім того, відновлення з дельта-бекапа відбувається дуже довго: дані доводиться збирати з мозаїки змінених шматочків. Проте, цим методом зручно користуватися для забезпечення безперервної захисту даних (коли бекап файлу робиться безпосередньо після його створення або внесення в нього змін - механізм, який віддалено нагадує автосохранение в файлах Word'а))) або у випадках зниженої пропускної здатності при збереженні резервних копій в віддаленому СГД.

Аналогічно дельта-блоковому бекапіть діє розроблений програмістами метод бінарних патчів, при якому копіюються частинки змінених файлів, але застосовується інша база порівняння (в дельті - блоки, в цьому методі - біти інформації).

Однак необхідно мати на увазі, що обидва згаданих методу застосовуються в зв'язці з диференціальним або інкрементального резервним копіюванням, але не самі по собі.

Іноді резервним копіюванням називають технологію зеркалирования, використовувану, наприклад, на апаратному рівні в RAID1 або при створенні сайтів-дзеркал. По суті ж це - просте копіювання файлів, без архівування та систематизації накопичення змінюваних файлів в заданому періоді.

За останні 12-15 років в технологіях резервного копіювання відбулося багато критичних змін, які змусили переглянути ефективність підходів і відкривши нові способи. Наприклад, впровадження технології снепшот (snapshots) - моментальних «знімків» файлової системи, з яких можна «склеїти» резервну копію, - дозволяють в хмарних системах робити резервне копіювання швидко і безболісно, не зупиняючи віртуальної машини. Крім того, застосовуючи в хмарі, снепшот дозволяють серйозно економити ресурс СГД, оскільки на диску клієнта вони місця не займають.

Наостанок зауважимо, що в процесі організації у своїй хмарної інфраструктурі SIM-Cloud послуги резервного копіювання ( Backup-as-a-Service ) Ми проаналізували ефективність різних підходів до виконання бекапа, і зупинили свій вибір на методі інкрементального копіювання, оптимізувавши його таким чином, що наш показник RTO (час відновлення даних з копії) становить в середньому від 15 до 30 хвилин (в залежності від обсягу даних) . І з впевненістю можемо сказати, що наш хмарний BaaS відповідає всім заявленим вище критеріям високоякісного резервного копіювання.

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

Автор: Аліса Кандеева