cPanel: налаштування автоматичних резервних копій

Вбудовані бекапи cPanel

cPanel → Backup Wizard або Backup. Повний бекап включає: файли, бази даних, Email, DNS-зони.

Налаштування віддаленого FTP-сховища

WHM → Backup Configuration:

Компресія (Compressed) помітно знижує обсяг переданих даних, але збільшує навантаження на CPU в момент створення архіву — на завантажених серверах бекап краще планувати на нічний час, коли відвідуваність мінімальна.

Реальні помилки JetBackup і вбудованого Backup

Якщо віддалене сховище недоступне в момент запуску завдання, у лозі WHM з'являється запис:

Failed to establish connection to destination: Connection timed out
Backup transfer failed for destination: RemoteFTP-01

Причина майже завжди одна з трьох: невірні облікові дані FTP/S3, файрвол блокує вихідне з'єднання з сервера хостингу, або у сховища закінчилося місце. Друга часта проблема — переповнення локального диска до відправлення на віддалене сховище:

Backup failed: not enough free space on /home to complete
local backup before transfer

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

Повний, інкрементальний і лише-файли: порівняння

Відновлення через cPanel

# Лише файли
cPanel → Backup → Restore a Home Directory Backup

# Лише база даних
cPanel → Backup → Restore a MySQL Database Backup

# Через WHM (якщо cPanel недоступна)
WHM → Restore a Full Backup/cpmove File

Правило 3-2-1 на спільному хостингу

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

• Копія №1 — робочі файли і база даних на самому хостингу
• Копія №2 — щоденний автоматичний бекап ZevsHost, що зберігається окремо від робочого розділу
• Копія №3 — бекап на зовнішньому FTP/S3-сховищі, фізично на іншому сервері й в іншого провайдера

Якщо всі три копії лежать на тому самому сервері, при аварії диска чи зламі акаунта можна втратити їх одночасно — саме тому третя копія має бути по-справжньому зовнішньою.

Коли вбудованого розкладу недостатньо

• Потрібна ретенція довша за 4 тижні — вбудований планувальник WHM не зберігає історію глибше останнього циклу weekly/monthly
• Потрібне резервне копіювання частіше одного разу на добу для критичних баз даних — для цього потрібен окремий cron з mysqldump, незалежний від розкладу WHM
• Інфраструктура зростає настільки, що повний бекап не встигає завершитися за нічне вікно — тут допомагає перехід на інкрементальні бекапи JetBackup
• Потрібна перевірка цілісності бекапу автоматичним скриптом одразу після створення, а не ручна розпаковка під час наступного інциденту

Як зрозуміти, що бекап було пропущено

За увімкненого сповіщення WHM надсилає лист після кожної спроби бекапу, навіть невдалої. Успішне завершення виглядає так:

Subject: Backup Completed for user
Backup Type: Full Backup
Status: Success
Duration: 00:14:32

Якщо замість Success у листі стоїть Failed або лист не прийшов узагалі, це сигнал перевірити чергу завдань і вільне місце негайно — пропущений бекап означає, що під час наступної аварії відновлювати доведеться старішу версію сайту, ніж очікувалося.

Перевірка результату

1. Після першого запуску розкладу відкрийте WHM → Backup Configuration і переконайтеся, що останнє завдання завершилося без помилок
2. Завантажте один архів з віддаленого сховища і розпакуйте його локально, щоб переконатися, що він не пошкоджений
3. Раз на квартал робіть пробне відновлення на тестовому акаунті — це єдиний спосіб дізнатися, що бекап справді робочий

Ручний бекап одного сайту перед ризикованими правками описано в статті Як створити резервну копію сайту, а вивантаження і відновлення великих дампів MySQL — у статті mysqldump: резервне копіювання і відновлення.