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 на shared-хостинге

Классическое правило резервного копирования — три копии данных, на двух разных типах носителей, одна из которых хранится вне основной площадки. На shared-хостинге его несложно выполнить, если не полагаться только на автоматический бэкап самого провайдера:

• Копия №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: резервное копирование и восстановление.