Під час роботи з віртуальним сервером можна створити снапшот, який зафіксує поточний стан системи перед оновленням, зміною налаштувань або встановленням нового програмного забезпечення. У панелі керування він часто виглядає як ще один різновид резервної копії: якщо систему можна відновити, отже, дані захищені. Помилка стає помітною, коли проблема виходить за межі невдалих змін: пошкоджується сховище, зникає віртуальна машина або зловмисник отримує доступ до інфраструктури.
Снапшот і бекап справді дають можливість повернути дані. Проте вони розраховані на різні ситуації, мають різний термін зберігання і по-різному залежать від основної системи.
Снапшот фіксує стан системи, бекап створює запасний шлях
Снапшот, або знімок, фіксує стан диска чи віртуальної машини у визначений момент. Його зручно створити перед оновленням операційної системи, зміною конфігурації вебсервера або розгортанням нової версії застосунку. Якщо після змін сайт перестав працювати, сервер можна швидко повернути до попереднього стану.
Снапшот не копіює всі дані віртуального сервера в окреме сховище. Він фіксує стан віртуальної машини у визначений момент, а подальші зміни записуються окремо. Якщо потрібно повернутися назад, система використовує основний диск і дані снапшота, щоб відновити попередній стан.
Саме тому знімок створюється швидко й зазвичай займає менше місця, ніж повна резервна копія. Водночас він залишається пов’язаним з основним диском та інфраструктурою, на якій працює віртуальний сервер. Якщо вихідні дані або саме сховище будуть втрачені, одного снапшота може виявитися недостатньо для відновлення.
Резервна копія розрахована на триваліше зберігання та ширший набір подій. Вона може містити окремі файли, базу даних, конфігурації, образ диска або всю систему. Для бекапів встановлюють розклад, глибину зберігання, правила шифрування та розташування копій.
Різниця полягає не в тому, що бекап обов’язково великий і повільний, а снапшот завжди створюється за кілька секунд. Резервні копії також бувають інкрементними. Головне питання звучить інакше: чи залишиться доступною точка відновлення, якщо основна система буде втрачена.
Читайте також: Як вибрати операційну систему для VPS-сервера
Чому самого снапшота недостатньо
Перед оновленням PHP адміністратор створив снапшот. Нова версія виявилася несумісною із сайтом, тому сервер повернули до попереднього стану. Для такого випадку знімок підходить добре: відновлення швидке, а зберігати його місяцями немає сенсу.
Інша ситуація: співробітник видалив каталог із документами, але помилку помітили через п’ять днів. Короткостроковий снапшот уже міг бути видалений. Тут потрібна серія резервних копій із достатньою глибиною зберігання.
Є й небезпечніший сценарій. Зловмисник отримав адміністративний доступ і видалив сервер разом зі снапшотами. Якщо всі точки перебували в тому самому обліковому записі, формально копії існували, але аварію не пережили.
Снапшоти також не варто залишати без контролю. У системах, де вони утворюють ланцюжок залежних дисків, знімки поступово займають більше місця і можуть впливати на продуктивність. VMware радить не тримати один снапшот довше 72 годин і обмежувати ланцюжок двома-трьома знімками. Це рекомендація для конкретної платформи, але вона добре показує призначення технології: коротке страхування перед змінами, а не архів.
ВАЖЛИВО ЗНАТИ! Складнощі можуть виникнути, якщо снапшот створюється під час активної роботи системи. Наприклад, інтернет-магазин саме записує нове замовлення до бази даних. Частина інформації вже збережена, а частина ще обробляється. Якщо зафіксувати стан сервера в цей момент, операція може потрапити до знімка незавершеною.
Після повернення до такого снапшота сервер, найімовірніше, запуститься, але останні зміни можуть відновитися некоректно. Тому перед створенням знімка важливих систем запис даних тимчасово призупиняють або використовують інструменти, які спочатку завершують поточні операції.
Чи можна створити снапшот на виділеному сервері
На виділеному сервері зазвичай немає готової кнопки для створення снапшота, як у панелі керування VPS/VDS. Клієнт отримує окрему фізичну машину, а можливість зберігати її проміжні стани залежить від установленої системи та способу організації дисків.
Снапшоти можна налаштувати на рівні файлової системи або дискового сховища, наприклад за допомогою ZFS чи LVM. Інший варіант — установити на фізичному сервері платформу віртуалізації, розділити його ресурси між кількома віртуальними машинами та створювати знімки кожної з них. Такий підхід використовують, зокрема, коли на одному виділеному сервері потрібно ізольовано розмістити кілька сайтів, застосунків або робочих середовищ.
Налаштовувати цю можливість краще до запуску проєкту, оскільки для неї потрібно правильно організувати диски та передбачити вільне місце. Якщо снапшот зберігається в тому самому дисковому масиві, він не захистить від фізичної несправності накопичувачів або втрати всього сервера. Тому на виділеній машині знімки також використовують переважно для швидкого повернення після невдалих змін, а резервні копії зберігають окремо.
Читайте також: Оптимізація освітнього процесу за допомогою Windows VPS
Як поєднати снапшоти та резервні копії
Робоча схема не змушує вибирати лише один інструмент. Вона розподіляє між ними завдання:
-
снапшот створюється перед оновленням, переналаштуванням або деплоєм і видаляється після перевірки системи;
-
резервні копії формуються автоматично та мають кілька точок відновлення;
-
принаймні одна копія зберігається окремо від основного сервера й не видаляється тими самими обліковими даними;
-
для баз даних налаштовується узгоджене копіювання, а не механічний знімок активного диска;
-
відновлення періодично перевіряється на тестовій машині, оскільки завершене копіювання ще не гарантує справність даних.
Для критичної інформації доцільно орієнтуватися на правило 3-2-1: мати три копії даних, використовувати два різні типи сховищ і тримати одну копію поза основною інфраструктурою. Це не готова схема для кожного проєкту, але вона прибирає залежність, коли сервер, снапшоти та бекапи можна втратити через одну подію.
Снапшот скорочує час повернення після невдалих змін. Резервна копія захищає історію даних і дає можливість відновитися після серйознішої аварії. Надійність з’являється тоді, коли ці інструменти працюють як різні рівні захисту.