Що таке Snapshot
Стаття також доступна російською (перейти до перегляду).
На будь-якому хостингу передбачена наявність системи резервного копіювання, що дозволяє уникнути втрат даних та повернутися до вихідного положення. У статті раніше нами були виписані основні рекомендації по роботі із бекапами на нашому хостингу. Однак, час не стоїть на місті і з’являються нові, більш гнучкі технології, однією з котрих є технологія SnapShot. Розглянемо її особливості та перспективи використання.
Навіщо потрібні системи резервного копіювання даних
При функціонуванні будь-якої розгорнутої на хостингу інформаційної системи, неодмінно будуть виникати ситуації, коли дані можуть бути пошкодженими та вимагають відновлення. Наведемо основні випадки:
-
Збій у програмному забезпеченні серверу або сайту;
-
Вихід з ладу одного або декількох компонентів апаратного забезпечення;
-
Збій у системі енергопостачання серверного обладнання;
-
Необхідність мати розширені можливості тестування веб-системи або програм;
-
Вірусні атаки;
-
Вплив «людського фактору» на будь-якому етапі експлуатації веб-системи;
-
Використання неперевіреного програмного забезпечення.
Вказані причини явилися основним чинником для організації сучасних систем резервування даних, котрі можуть відрізнятися закладеними в них підходами до організації процесу резервування.
Переваги й недоліки систем резервування, заснованих на бекапах
Головною перевагою таких систем є можливість завжди мати кілька повних копій сайту на визначені дати, наприклад, за 2, 3 та 4 дні до поточного моменту часу. Це дає змогу гарантовано відновити VPS-сервер або веб-ресурс у випадку виникнення непередбачуваних обставин, про що вже йшлося раніше. Такий спосіб резервування найбільше підійде для веб-систем, котрі майже не змінюються з часом.
Головні недоліки – необхідний значний об’єм дискового простору для постійного збереження кількох копій сайту; при малому періоді резервування значно збільшується навантаження на сервер і тому продуктивність його роботи падає; є ризик втратити частину даних при інтенсивній роботі з сайтом та постійному оновленні на ньому інформації.
Останній недолік цілком зрозумілий, оскільки неможливо забезпечити, наприклад, щохвилинне або, навіть, щогодинне створення повноцінних резервних копій при значному обсязі даних, що змінюються. Необхідність забезпечення цілісності даних вимагає зупинки внесення змін, що, по суті, призведе до блокування роботи усієї веб-системи.
Вказані недоліки призвели до пошуку альтернативних рішень, котрі дозволяють уникнути розростання розмірів сховища та втрати даних. Одним з них є використання технології SnapShot.
Системи резервування, засновані на технології SnapShot
Сутність технології частково зафіксована у її назві – «миттєвий знімок», що вказує на миттєву фіксацію поточного стану об’єктів файлової системи – файлів, каталогів, тощо.
Особливо ефективно технологія може застосовуватися по відношенню до повністю ізольованих систем та середовищ – віртуальних машин, Docker-контейнерів, VPS-серверів, пісочниць, тощо. Це пов’язано з тим, що такі середовища представляють собою файл із даними, записаний на диску та завантажений до оперативної пам’яті (ОП) комп’ютеру. У якості даних тут може виступати вміст регістрів процесору та віртуальних дисків, опис конфігурації системи, вміст ОП, тощо.
Завдяки використанню спеціальних API або просторів імен, технологія SnapShot може «працювати» із багатьма типами файлових систем (FS). Зокрема, вона вже реалізована для наступних FS – NTFS, ZFS, fossil, NSS, UFS2 та декотрих інших.
Принципи, закладені у роботу SnapShot
Головний принцип – фіксувати лише зміни. Це означає, що дублювання даних не відбувається – записуються лише зміни, котрі вносяться до системи після певного моменту часу (час фіксації або відновлення).
Наведемо у спрощеному вигляді етапи робочого процесу, котрий відбувається одразу ж після активації функції SnapShot засобами панелі управління хостингом по відношенню до визначеного об’єкту віртуалізації:
-
Фіксується час та дата створення снепшоту, тобто створюється точка відновлення;
-
Об’єкт блокується на рівні FS, що унеможливлює внесення до нього змін;
-
Створюється пустий файл, котрий відображає структуру об’єкту і умовно дублює його;
-
Розмір файлу узгоджується із наявним вільним місцем на диску у відповідності із діючим хостинг-планом;
-
«Строк життя» снепшоту може становити від 24-х до 72-х годин в залежності від налаштувань хостингу;
-
У випадку внесення до об’єкту змін Адміністратором чи стороннім ПЗ, вони фіксуються у створеному файлі;
-
По закінченні «строку життя» снепшоту дані на основному носії перезаписуються та відбувається його видалення із системи з поверненням її до нормального режиму роботи;
-
За допомогою відповідних налаштувань панелі управління хостингом завжди можна повернутися до «точки відновлення» та продовжити роботу з об’єктом віртуалізації із вихідного положення;
-
У випадку нестачі місця на диску, відновлення може не відбутися.
Нами був наведений приклад реалізації технології SnapShot із можливістю створення лише однієї точки відновлення, що доволі часто пропонується хостинг-провайдерами. Однак, також можливі варіанти створення системи резервування із кількома точками відновлення, що дозволить у разі потреби повернутися до будь-якої з них.
Відмінності SnapShot від бекапів
На відміну від бекапів, системи, побудовані на SnapShot, дозволяють отримати копії даних, як кажуть, «на льоту», тобто не вимагають припинення роботи із веб-системою під час створення копії, не ризикуючи при цьому порушити цілісність даних.
Створивши снепшот об’єкту даних, не треба відволікатися та контролювати роботу системи резервування – вона все зробить сама та прибере за собою «зайву» копію, якщо вона вам не знадобиться.
Снепшоти не можна розглядати, як повну копію об’єкту даних, а лише як засіб його швидкого відновлення у разі виникнення на те нагальної потреби.
У Таблиці 1 наведена порівняльна характеристика обох систем резервування.
Таблиця 1. Порівняльна характеристика систем резервування
Тип системи резервування |
Цільове призначення |
Місце зберігання копій |
Час зберігання копій, год. |
Розмір копій |
Вплив на продуктивність системи |
Резервне копіювання |
Для створення повних резервних копій даних працюючих інформаційних систем |
Будь-який зовнішній носій. |
Необмежений |
Значний |
Значно знижує при малих періодах резервування |
SnapShot |
Для швидкого відновлення ізольованих віртуальних середовищ |
На основному носії біля файлу ізольованого середовища |
24-72 |
Компактний, за умови виконання періодичного авто/примусового очищення |
Незначний вплив за умови дотримання технології |
Підсумки
Із розглянутого можна зробити висновок, що обидві технології мають принципові відмінності, як у цільовому призначенні, так і організації процесу резервування. І тому не можна, навіть, говорити про можливість повної заміни однієї технології іншою, а лише про їх взаємодоповнення. У такому разі завжди можна обирати те, що найбільше підходить у тому чи іншому випадку.