Резервна копія, якою ви справді користуєтеся
Більшість компаній дізнаються, що їхня резервна копія не працює, лише коли трапляється катастрофа. Тому ми радимо ставитися до резервного копіювання як до процесу, а не до галочки: автоматичні копії, що зберігаються окремо від робочого сервера, і регулярно перевірювані відновлення. На cPanel щоденна резервна копія створюється автоматично, а відновлюєте ви її з панелі; на VPS і виділених серверах команда DevOps може налаштувати регулярні тести відновлення в межах ваших включених годин.
Яке резервне копіювання входить у кожен тариф
Хостинг cPanel має автоматичну щоденну резервну копію, яку ви відновлюєте з панелі. VPS має снапшоти — повні копії стану сервера — без гарантованої частоти. Виділені сервери за замовчуванням не включають резервного копіювання: диски NVMe йдуть парами, а RAID налаштовується під час встановлення, але RAID — це не резервна копія. Зовнішнє резервне копіювання, PITR для баз даних і тести відновлення налаштовує наша команда в межах включених годин DevOps (5–10 h/міс на виділених серверах).
| Тариф | Резервне копіювання | Відновлення | Розташування |
|---|---|---|---|
| Хостинг cPanel | Автоматична щоденна резервна копія | З панелі клієнта | ЄС (Франкфурт) |
| VPS | Снапшоти, без гарантованої частоти | Зі снапшота | ЄС (Франкфурт) |
| VPS — зовнішнє резервне копіювання | На замовлення, з годин DevOps | Відповідно до налаштованої стратегії | Узгоджується з командою |
| Виділений сервер | За замовчуванням не входить — налаштовується на замовлення | Відповідно до стратегії (3-2-1, PITR) | ЄС (Франкфурт) + зовнішнє сховище на замовлення |
RPO і RTO — цифри, які варто визначити самому
Замість «резервне копіювання якнайшвидше» краще зафіксувати два конкретні значення. RPO (Recovery Point Objective) показує, скільки даних ви можете дозволити собі втратити. RTO (Recovery Time Objective) показує, скільки може тривати відновлення. Команда будує стратегію навколо цих значень.
Максимальна втрата даних, яку ви готові прийняти. Щоденна резервна копія означає втрату до доби; зі стрімінгом WAL база даних опускається нижче однієї хвилини — налаштовується на замовлення.
Час відновлення залежить від обсягу даних і обраної стратегії. Ми не гарантуємо RTO — єдина надійна цифра — та, що виміряна під час тесту відновлення.
Сценарії катастроф — і як від них захиститися
Катастрофи трапляються рідко, але мають серйозні наслідки. Ось найпоширеніші сценарії та захист, який ми рекомендуємо для кожного. На VPS і виділених серверах команда налаштовує ці заходи в межах включених годин DevOps.
Апаратна відмова (диск, RAM)
Найчастіша причина втрати даних. Виділені сервери мають парні диски NVMe з RAID, налаштованим під час встановлення, а також пам'ять ECC на рівнях EPYC і Xeon. RAID зберігає роботу сервера, коли диск виходить з ладу, але не замінює резервну копію — зовнішня копія все одно потрібна.
Захист: RAID + зовнішня резервна копіяПрограма-вимагач або компрометація облікового запису
Зловмисник шифрує файли сервера — і будь-яку копію, до якої сервер має доступ. Тому принаймні одна копія має зберігатися поза сервером, де робочий обліковий запис не може її змінити (незмінна або офлайн). Ми налаштовуємо це на замовлення, з годин DevOps.
Захист: ізольована копіяВипадкове видалення даних
«DROP TABLE users», виконане на продакшені. Найпоширеніша людська помилка. Якщо для бази даних налаштовано відновлення на момент часу (PITR), ви повертаєтеся до моменту безпосередньо перед помилкою; щоденна резервна копія повертає лише до останньої копії.
Захист: PITR на замовленняПовна відмова дата-центру
Пожежа, повінь, тривала відмова оператора. Захист — копія в іншому місці, наприклад у другому дата-центрі. Реплікація та перемикання на резерв за замовчуванням не входять; команда налаштовує їх на замовлення, з годин DevOps.
Захист: копія в іншому місціПомилка в застосунку пошкоджує дані
Розгортання вносить помилку, що пошкоджує записи бази даних. З окремою резервною копією бази ви відновлюєте лише БД (а не весь сервер) — файли застосунку залишаються, дані відкочуються.
Захист: окрема резервна копія БДМіграція на інший сервер
Ви переростаєте поточний тариф. VPS переходить на вищий рівень із більшою кількістю vCPU, RAM і диска; для переходу на інший сервер ми заздалегідь плануємо міграцію, щоб простій був коротким.
Порада: плануйте міграцію заздалегідьРезервне копіювання баз даних — стратегії для кожного рушія
Повної резервної копії VPS не завжди достатньо. Бази даних мають власні механізми відновлення на момент часу (PITR) — вони дають змогу повернутися точно до обраного моменту, а не лише до останнього снапшота. Ми налаштовуємо їх на замовлення, з включених годин DevOps.
Що входить — і що налаштовується на замовлення
Окремо «преміального резервного копіювання» немає: що входить, зазначено в кожному тарифі, а все, що понад це, команда будує з годин DevOps у вашій підписці. Години понад квоту оплачуються окремо, погодинно.
- cPanel: автоматична щоденна резервна копія, відновлення з панелі — входить
- VPS: снапшоти, без гарантованої частоти — входить
- Виділені сервери: парні диски NVMe, RAID налаштовується під час встановлення — резервне копіювання за замовчуванням не входить
- Зовнішнє резервне копіювання за правилом 3-2-1 — на замовлення, з годин DevOps (5–10 h/міс на виділених серверах)
- PITR для баз даних (WAL, binlog, oplog) — на замовлення, з годин DevOps
- Тести відновлення та період зберігання — узгоджуються з командою та налаштовуються з годин DevOps
Відновлення резервної копії — у 4 кроки
Відкрийте панель
Увійдіть у панель клієнта. На cPanel ви відновлюєте щоденну резервну копію саме там; на VPS обираєте снапшот.
Оберіть момент часу
Оберіть копію, створену безпосередньо перед проблемою. Остання не завжди підходить, якщо помилка існує вже певний час.
Натисніть «Відновити»
Відновлення перезаписує поточний стан. Якщо ви не певні, попросіть команду спочатку відновити копію в окремому середовищі, щоб порівняти.
Перевірте результат
Переконайтеся, що застосунок працює, а дані на своєму місці. Тривалість відновлення залежить від обсягу даних.
Поширені запитання
Чи потрібно зупиняти сервер для створення снапшота?
Зазвичай ні: снапшот VPS створюється, поки сервер працює. Проте для бази даних снапшот працюючого сервера не завжди узгоджений, тому ми рекомендуємо окрему резервну копію бази (дамп або WAL/binlog), яку команда налаштовує на замовлення.
Скільки триває відновлення дуже великого снапшота (наприклад, 500 GB)?
Це залежить від обсягу даних, диска та місця зберігання копії — відновлення із зовнішньої копії триває довше, ніж з локальної. Ми не обіцяємо фіксованого часу: реалістичну цифру дає тест відновлення, який ми можемо провести разом із вами.
Чи шифруються резервні копії?
Шифрування зовнішніх резервних копій — частина стратегії, яку ми налаштовуємо на замовлення: наприклад, копії залишають сервер лише в зашифрованому вигляді, а ключі зберігаються окремо від продакшену. Повідомте команді свої вимоги під час замовлення налаштування.
Що, якщо мені потрібен період зберігання понад 30 днів?
Період зберігання зовнішніх резервних копій задається, коли команда налаштовує стратегію, залежно від ваших потреб і ваших законних зобов'язань щодо архівування. Сховище для довшого зберігання узгоджується з командою; тарифи ви знайдете на сторінці цін.
Чи можна завантажити снапшот локально?
На VPS і виділених серверах ви маєте root-доступ і копіюєте свої дані зручними для вас інструментами (rsync, tar). Команда також може налаштувати автоматичні копії у зовнішнє сховище з годин DevOps, наприклад AWS S3, Google Cloud Storage або Azure Blob.
Ваші дані надто цінні, щоб покладатися на удачу
cPanel включає щоденне резервне копіювання, а VPS — снапшоти. На виділених серверах команда будує стратегію резервного копіювання з включених годин DevOps. Подробиці — у цінах.
Переглянути тарифи →