www.teamhosting.ru

Потеря данных может привести к длительной недоступности сайта, финансовым убыткам и полной остановке бизнеса. Причиной могут стать ошибки администратора, сбой оборудования, вредоносное программное обеспечение, проблемы с обновлением или случайное удаление файлов.

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

Из чего состоит система резервного копирования

Полноценная система бэкапа должна защищать не только файлы сайта. В резервные копии обычно включают следующие данные:

HTML, CSS, JavaScript и другие файлы сайта.
Изображения, видео и пользовательские загрузки.
Базы данных MySQL, MariaDB, PostgreSQL или MongoDB.
Конфигурационные файлы сайта и сервера.
Файлы `.htaccess`, настройки PHP и задания cron.
Почтовые настройки и важные DNS-параметры.
Журналы и другие данные, необходимые для анализа работы проекта.

Этап 1. Планирование резервного копирования

1.1. Определите важность данных

Сначала разделите данные на категории и определите, какие из них необходимо восстанавливать в первую очередь.

Критически важные данные: базы данных, заказы, платежи и учетные записи пользователей.
Важные данные: файлы сайта, изображения, документы и конфигурации.
Дополнительные данные: временные файлы, кэш и журналы, которые можно восстановить отдельно.

1.2. Определите RPO и RTO

Для планирования бэкапов используются два важных показателя:

RPO это допустимый объем потери данных. Например, при RPO в 24 часа можно потерять изменения, сделанные за последние сутки.
RTO это допустимое время восстановления работы сайта после сбоя.

Если сайт принимает заказы постоянно, резервные копии базы данных должны создаваться чаще, чем для обычного информационного сайта.

1.3. Выберите тип резервного копирования

Полный бэкап. Сохраняются все выбранные файлы и данные. Такой бэкап занимает больше места, но позволяет быстрее восстановить проект.
Инкрементный бэкап. После создания полной копии сохраняются только изменения с момента последнего резервного копирования.
Дифференциальный бэкап. Сохраняются все изменения с момента последной полной копии. Восстановление обычно проще, чем при инкрементной схеме.

1.4. Составьте график

Периодичность зависит от того, как часто меняются данные:

Базы данных и заказы: каждый час или несколько раз в день.
Файлы сайта: ежедневно.
Полная копия проекта: еженедельно.
Архивные копии: ежемесячно или ежегодно.

Этап 2. Выбор места хранения

Хранить все резервные копии на том же сервере, где находится сайт, небезопасно. При сбое диска, взломе или удалении аккаунта могут исчезнуть и рабочие данные, и их копии.

Правило 3-2-1

Для важных проектов рекомендуется использовать правило 3-2-1:

Минимум 3 копии данных.
Минимум 2 разных типа хранилищ.
Минимум 1 копия в другом физическом месте.

Варианты хранения

Локальное хранилище. Позволяет быстро восстановить данные, но не защищает от сбоя самого сервера.
Удаленный сервер. Подходит для хранения автоматических копий через FTP, SFTP, rsync или SSH.
Облачное хранилище. Можно использовать S3-совместимые хранилища и специализированные сервисы резервного копирования.
Внешние носители. Подходят для долгосрочных архивов, которые не нужно менять каждый день.

Этап 3. Резервное копирование через панель хостинга

cPanel

Войдите в панель cPanel.
Откройте раздел `Backup`, `Backup Wizard` или `JetBackup`.
Выберите файлы сайта и базы данных.
Укажите место хранения и расписание, если такая функция доступна.
Создайте первую резервную копию вручную.

Plesk

Откройте раздел резервного копирования.
Создайте новое задание.
Выберите файлы, базы данных и настройки, которые необходимо сохранить.
Укажите периодичность и место хранения копий.
Выполните тестовое создание бэкапа.

DirectAdmin

Откройте раздел резервного копирования пользователя.
Выберите домен, файлы и базы данных.
Создайте резервную копию аккаунта.
Скачайте архив или настройте передачу копии на удаленное хранилище.

Этап 4. Резервное копирование файлов сайта

Через FTP или SFTP

Подключитесь к серверу через FileZilla, WinSCP или другой клиент.
Найдите корневую директорию сайта. Обычно это `public_html`, `www` или `httpdocs`.
Скачайте все необходимые файлы и папки.
Сохраните архив с датой создания в названии.
Загрузите копию на внешний диск или удаленное хранилище.

Не забудьте проверить скрытые файлы, особенно `.htaccess`, `.env` и другие конфигурационные файлы.

Через rsync

Для автоматической синхронизации файлов между серверами можно использовать команду `rsync`:

rsync -avz --delete /var/www/html/example.com/ \
user@backup-server:/backups/example.com/

Параметр `--delete` удаляет из резервной копии файлы, которые были удалены из исходной директории. Используйте его осторожно и только после проверки правильности путей.

Этап 5. Резервное копирование базы данных

Через phpMyAdmin

Войдите в phpMyAdmin.
Выберите базу данных сайта.
Откройте вкладку `Экспорт`.
Выберите полный экспорт всех таблиц.
Укажите формат SQL.
Для уменьшения размера выберите сжатие GZIP, если оно доступно.
Скачайте готовый файл на компьютер или загрузите его в облачное хранилище.

Через командную строку MySQL

mysqldump -u username -p database_name > backup.sql

Для создания сжатой копии используйте:

mysqldump -u username -p database_name - gzip > backup.sql.gz

Для резервного копирования всех баз данных:

mysqldump -u username -p --all-databases - gzip > all-databases.sql.gz

Через командную строку PostgreSQL

pg_dump -U username -d database_name -f backup.sql

Для создания сжатой копии:

pg_dump -U username -d database_name - gzip > backup.sql.gz

Этап 6. Автоматизация резервного копирования

Ручное создание копий подходит только для небольших проектов. Для регулярной защиты сайта лучше создать скрипт и запланировать его запуск через cron.

Пример Bash-скрипта

#!/bin/bash

SITE_DIR="/var/www/html/example.com"
BACKUP_DIR="/var/backups/example.com"
DATE=$(date +%Y-%m-%d_%H-%M)

mkdir -p "$BACKUP_DIR/$DATE"

tar -czf "$BACKUP_DIR/$DATE/site-files.tar.gz" \
 -C "$SITE_DIR".

mysqldump -u "database_user" -p"database_password" "database_name" \
 - gzip > "$BACKUP_DIR/$DATE/database.sql.gz"

find "$BACKUP_DIR" -mindepth 1 -maxdepth 1 -type d -mtime +14 \
 -exec rm -rf {} \;

echo "Backup completed successfully: $DATE"

Для безопасности не рекомендуется хранить пароль базы данных непосредственно в командной строке. Лучше использовать отдельный конфигурационный файл с ограниченными правами доступа.

Настройка cron

Откройте планировщик заданий:

crontab -e

Для ежедневного запуска скрипта в 3 часа ночи добавьте:

0 3 * * * /usr/local/bin/backup-site.sh >> /var/log/backup-site.log 2>&1

После настройки проверьте запуск скрипта вручную и убедитесь, что архив файлов и дамп базы данных создаются без ошибок.

Этап 7. Политика хранения и ротация копий

Постоянное хранение всех копий быстро заполнит дисковое пространство. Поэтому необходимо заранее определить срок хранения и правила удаления устаревших резервных копий.

Ежедневные копии: хранить 7-14 дней.
Еженедельные копии: хранить 4-8 недель.
Ежемесячные копии: хранить 3-12 месяцев.
Годовые архивы: хранить в соответствии с требованиями бизнеса и законодательства.

Перед автоматическим удалением старых файлов убедитесь, что в хранилище остается необходимое количество рабочих копий.

Этап 8. Защита резервных копий

Шифруйте конфиденциальные архивы перед загрузкой в облако.
Ограничьте доступ к папке с резервными копиями.
Используйте отдельную учетную запись для доступа к хранилищу.
Включите двухфакторную аутентификацию, если сервис ее поддерживает.
Храните ключи шифрования отдельно от самих архивов.
Не размещайте открытые резервные копии внутри публичной директории сайта.
Регулярно проверяйте журналы доступа к хранилищу.

Этап 9. Проверка резервных копий

Факт создания архива еще не гарантирует его пригодность для восстановления. Поврежденный архив или неполный дамп базы данных может оказаться бесполезным в аварийной ситуации.

Проверка файлов

Распакуйте архив на тестовом сервере.
Проверьте наличие основных файлов и папок.
Проверьте права доступа.
Откройте сайт и проверьте основные функции.

Проверка базы данных

Создайте тестовую базу данных.
Импортируйте SQL-файл.
Проверьте наличие таблиц и записей.
Подключите тестовую копию сайта к восстановленной базе.
Проверьте авторизацию, поиск, формы и другие функции.

План восстановления после сбоя

Заранее подготовьте понятную инструкцию, которой можно воспользоваться во время аварии. В ней укажите:

Контакты ответственных сотрудников.
Адреса серверов и резервных хранилищ.
Данные для подключения.
Порядок восстановления файлов.
Порядок восстановления базы данных.
Настройки DNS и SSL-сертификата.
Способы проверки работоспособности сайта.

Распространенные проблемы

Недостаточно места для хранения

Используйте сжатие, инкрементные копии и автоматическую ротацию. Также можно хранить старые архивы в более дешевом облачном хранилище.

Ошибка при создании дампа базы данных

Проверьте права пользователя базы данных, доступное место на диске, размер базы и лимиты выполнения команд.

Архив создан, но не восстанавливается

Проверьте целостность архива, используйте несколько версий копий и регулярно выполняйте тестовое восстановление.

Резервные копии доступны посторонним

Уберите архивы из публичной директории, ограничьте права доступа, включите шифрование и двухфакторную аутентификацию.

Итог

Надежная система резервного копирования строится не на одном архиве, а на сочетании автоматизации, нескольких мест хранения, защиты и регулярного тестирования восстановления.

Для большинства сайтов достаточно ежедневного резервного копирования файлов, более частого сохранения базы данных и еженедельного полного архива проекта.

Если данные критически важны для бизнеса, используйте правило 3-2-1, храните одну копию вне основного сервера и заранее подготовьте понятный план восстановления.

Рекомендация: Создайте первую резервную копию уже сейчас, сохраните ее в отдельном хранилище и выполните тестовое восстановление. Это позволит проверить систему до возникновения реальной аварии.

Как создать полноценную систему резервного копирования для сайта