Я видел десятки проектов, которые превращались в прах из-за отсутствия нормальных бэкапов. Один неудачный апдейт, атака хакеров или банальный сбой диска — и вот ты уже объясняешь клиенту, почему его интернет-магазин с оборотом в миллион рублей в месяц лежит мёртвым грузом.
За 10+ лет работы с Bitrix, WordPress и Laravel я выработал железную систему резервного копирования. И сегодня расскажу, как делать бэкапы правильно, чтобы спать спокойно и не терять деньги клиентов.
Зачем нужны бэкапы: истории из практики
Честно говоря, многие разработчики и владельцы сайтов относятся к бэкапам как к чему-то необязательному. "А зачем, у нас же хостинг делает копии!" — слышу я регулярно. И вот реальные случаи из моей практики, которые заставили меня пересмотреть отношение к резервному копированию.
Был у меня клиент с интернет-магазином на Bitrix. Оборот — около 800 тысяч в месяц, база клиентов — 15 тысяч человек. Решили обновить модуль интеграции с 1С. Обновление прошло криво, база данных частично повредилась. Хостинг делал бэкапы раз в неделю, а последний рабочий был недельной давности. Потеряли заказы, базу клиентов, настройки. Восстанавливали почти месяц, потери составили около 200 тысяч рублей.
А ещё был случай с WordPress-сайтом агентства недвижимости. Сайт взломали, залили вирусы, поисковики заблокировали. Автоматические бэкапы хостинга тоже оказались заражены — они делались каждый день, но вирус сидел уже две недели. Пришлось восстанавливать из месячного архива и заново вносить все новые объявления.
Грубо говоря, бэкапы нужны в трёх случаях: технические сбои, человеческие ошибки и внешние атаки. И по моей статистике, 70% проблем приходится на человеческий фактор — неудачные обновления, ошибки в коде, случайное удаление файлов.
Типы бэкапов и что включать в резервную копию
На практике я выделяю три типа бэкапов: полные, инкрементные и дифференциальные. Каждый имеет свои плюсы и минусы, и я обычно комбинирую их для максимальной защиты.
Полный бэкап — это копия всех файлов и базы данных на определённый момент. Занимает много места, но восстанавливается быстро. Я делаю полные бэкапы раз в неделю для небольших проектов и раз в день для критически важных.
Инкрементный бэкап сохраняет только изменения с момента последнего бэкапа любого типа. Экономит место, но восстановление может быть долгим — нужно применить все инкременты по порядку.
Дифференциальный бэкап сохраняет изменения с момента последнего полного бэкапа. Компромисс между размером и скоростью восстановления.
Что включать в бэкап? Тут многие делают ошибку, сохраняя только файлы сайта. А нужно сохранять:
- Все файлы сайта (включая .htaccess, robots.txt, sitemap.xml)
- Базу данных целиком
- Конфигурационные файлы веб-сервера (nginx.conf, apache.conf)
- SSL-сертификаты
- Логи (последние 30 дней минимум)
- Кеш и временные файлы (иногда в них есть важные данные)
У одного клиента был казус — после переезда хостинга сайт работал, но email-уведомления не приходили. Оказалось, в .htaccess были специальные правила для почтовых скриптов, которые не попали в бэкап. Пришлось восстанавливать по памяти.
Автоматические бэкапы: настройка и скрипты
Ручные бэкапы — это хорошо, но человек всё равно забудет. Поэтому автоматизация критически важна. Я настраиваю автоматические бэкапы на всех проектах без исключений.
Для Linux-серверов использую cron. Вот мой базовый скрипт для бэкапа WordPress:
#!/bin/bash
SITE_PATH="/var/www/example.com"
BACKUP_PATH="/backups"
DB_NAME="wordpress_db"
DB_USER="db_user"
DB_PASS="password"
DATE=$(date +%Y%m%d_%H%M%S)
# Создаём директорию для бэкапов
mkdir -p $BACKUP_PATH/$DATE
# Бэкап базы данных
mysqldump -u$DB_USER -p$DB_PASS $DB_NAME > $BACKUP_PATH/$DATE/database.sql
# Бэкап файлов
tar -czf $BACKUP_PATH/$DATE/files.tar.gz -C $SITE_PATH .
# Удаляем старые бэкапы (старше 30 дней)
find $BACKUP_PATH -type d -mtime +30 -exec rm -rf {} +
echo "Backup completed: $DATE"
Для Bitrix скрипт немного сложнее, потому что нужно учитывать структуру модулей и временно отключать сайт во время бэкапа базы:
#!/bin/bash
BITRIX_PATH="/var/www/bitrix"
BACKUP_PATH="/backups/bitrix"
DB_NAME="bitrix_db"
DB_USER="bitrix_user"
DB_PASS="bitrix_password"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p $BACKUP_PATH/$DATE
# Включаем режим обслуживания
touch $BITRIX_PATH/.maintenance
# Бэкап базы
mysqldump --single-transaction --routines --triggers -u$DB_USER -p$DB_PASS $DB_NAME > $BACKUP_PATH/$DATE/bitrix_db.sql
# Бэкап файлов (исключаем кеш и временные файлы)
tar --exclude='bitrix/cache' --exclude='bitrix/managed_cache' --exclude='bitrix/tmp' -czf $BACKUP_PATH/$DATE/bitrix_files.tar.gz -C $BITRIX_PATH .
# Отключаем режим обслуживания
rm $BITRIX_PATH/.maintenance
echo "Bitrix backup completed: $DATE"
В crontab прописываю так:
# Полный бэкап каждое воскресенье в 3:00
0 3 * * 0 /root/scripts/full_backup.sh
# Инкрементный бэкап каждый день в 2:00
0 2 * * 1-6 /root/scripts/incremental_backup.sh
# Бэкап только базы каждые 6 часов
0 */6 * * * /root/scripts/db_backup.sh
Для WordPress рекомендую плагины UpdraftPlus или BackupBuddy. Они умеют загружать бэкапы на облачные сервисы и отправлять уведомления о статусе.
Облачные хранилища для бэкапов
Хранить бэкапы только на том же сервере — это плохая идея. Если сервер сгорит физически или его взломают, вы потеряете и сайт, и резервные копии. Поэтому обязательно используйте внешние хранилища.
Я работаю с несколькими облачными сервисами:
Яндекс.Диск — 10 ГБ бесплатно, есть API для автоматизации. Хорошо подходит для небольших проектов. Загрузка через rclone работает стабильно.
Google Drive — 15 ГБ бесплатно (общий лимит с Gmail), отличная интеграция с различными бэкап-утилитами.
Amazon S3 — платно, но очень надёжно. Использую для критически важных проектов. Есть разные классы хранения — для часто используемых данных и архивных.
Selectel — российский провайдер, S3-совместимое API. Дешевле Amazon, данные хранятся в России.
Вот пример настройки загрузки бэкапов в Selectel через s3cmd:
# Устанавливаем s3cmd
apt-get install s3cmd
# Настраиваем конфиг
s3cmd --configure
# В скрипте бэкапа добавляем загрузку
s3cmd put $BACKUP_PATH/$DATE/files.tar.gz s3://my-backup-bucket/site-backups/
s3cmd put $BACKUP_PATH/$DATE/database.sql s3://my-backup-bucket/db-backups/
# Удаляем старые бэкапы из облака (старше 60 дней)
s3cmd ls s3://my-backup-bucket/ | awk '{print $4}' | grep $(date -d '60 days ago' +%Y%m%d) | head -10 | xargs -I {} s3cmd del {}
На практике я настраиваю загрузку в два разных облака. Основное — Selectel (быстро и дёшево), резервное — Google Drive (бесплатно, но медленно). Так получается тройная защита: локальные бэкапы, основное облако, резервное облако.
Тестирование бэкапов и проверка целостности
Самая частая ошибка — делать бэкапы, но никогда их не проверять. У меня был клиент, который полгода делал автоматические бэкапы, а когда понадобилось восстановление, оказалось, что все архивы битые из-за ошибки в скрипте.
Поэтому я всегда настраиваю автоматическую проверку бэкапов. Вот что проверяю:
Целостность архивов: можно ли распаковать tar.gz без ошибок?
#!/bin/bash
BACKUP_FILE="/backups/20261215_030001/files.tar.gz"
if tar -tzf $BACKUP_FILE > /dev/null; then
echo "Archive is OK"
else
echo "Archive is corrupted!" | mail -s "Backup Error" admin@example.com
fi
Проверка базы данных: можно ли импортировать SQL-дамп без ошибок?
-- Создаём тестовую базу
CREATE DATABASE test_restore_db;
-- Пробуем импортировать
mysql -u root -p test_restore_db < /backups/20261215_030001/database.sql
-- Проверяем количество таблиц
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'test_restore_db';
-- Удаляем тестовую базу
DROP DATABASE test_restore_db;
Размер бэкапа: не слишком ли маленький? Если размер сильно отличается от предыдущих, возможно, что-то пошло не так.
Раз в месяц я делаю полное восстановление на тестовом сервере. Это занимает время, но даёт уверенность, что в критический момент всё сработает. Процедура такая:
- Поднимаю чистый сервер (обычно использую Docker-контейнер)
- Устанавливаю веб-сервер, PHP, MySQL тех же версий
- Восстанавливаю из бэкапа
- Проверяю, что сайт открывается и работают основные функции
- Засекаю время восстановления
У одного клиента такая проверка выявила, что я забыл включить в бэкап папку с загруженными файлами. Сайт восстанавливался, но все изображения были битыми. Хорошо, что обнаружили это не во время реального ЧП.
Восстановление из бэкапа: пошаговая инструкция
Когда случается катастрофа, важно действовать быстро, но без паники. У меня есть чёткий алгоритм восстановления, который я отрабатывал на практике десятки раз.
Шаг 1: Оценка ущерба
Сначала определяю, что именно повреждено. Файлы? База данных? И то, и другое? От этого зависит стратегия восстановления. Если повреждены только файлы, можно восстановить их без остановки сайта.
Шаг 2: Выбор точки восстановления
Беру самый свежий рабочий бэкап. Но тут есть нюанс — если проблема была не замечена сразу, то и свежие бэкапы могут быть повреждены. Поэтому всегда проверяю 2-3 последних копии.
Шаг 3: Включение режима обслуживания
Для WordPress создаю файл .maintenance в корне сайта:
<?php
$upgrading = time();
Для Bitrix аналогично создаю .maintenance или использую встроенный механизм через админку.
Шаг 4: Восстановление базы данных
# Создаём резервную копию текущей (возможно, повреждённой) базы
mysqldump -u root -p current_db > damaged_db_backup.sql
# Очищаем базу
mysql -u root -p -e "DROP DATABASE current_db; CREATE DATABASE current_db;"
# Восстанавливаем из бэкапа
mysql -u root -p current_db < /backups/20261215_030001/database.sql
Шаг 5: Восстановление файлов
# Создаём резервную копию текущих файлов
tar -czf damaged_files_backup.tar.gz /var/www/site/
# Очищаем директорию (кроме .htaccess на всякий случай)
find /var/www/site/ -mindepth 1 ! -name '.htaccess' -delete
# Восстанавливаем файлы
tar -xzf /backups/20261215_030001/files.tar.gz -C /var/www/site/
# Проверяем права доступа
chown -R www-data:www-data /var/www/site/
chmod -R 755 /var/www/site/
Шаг 6: Проверка и запуск
Убеждаюсь, что сайт открывается, основные функции работают. Проверяю логи на ошибки. Только после этого отключаю режим обслуживания.
Весь процесс для среднего сайта занимает 15-30 минут. Для крупных проектов с большими базами может потребоваться несколько часов.
Особенности бэкапов для Bitrix
Bitrix — специфическая CMS, и подход к бэкапам тут имеет свои нюансы. За годы работы с этой системой я выработал особую методику.
Что обязательно включать в бэкап Bitrix:
- Папка /bitrix/ целиком (ядро системы)
- Все пользовательские файлы в корне
- Папка /upload/ (файлы, загруженные через админку)
- Папка /local/ (кастомные модули и настройки)
- Файл .settings.php (настройки подключения к БД)
- Файлы .htaccess и robots.txt
Что можно исключить:
- /bitrix/cache/ — кеш восстановится автоматически
- /bitrix/managed_cache/ — тоже кеш
- /bitrix/tmp/ — временные файлы
- /bitrix/backup/ — старые бэкапы
Особенность Bitrix в том, что система активно использует базу данных для хранения настроек, и даже небольшие повреждения могут сломать весь функционал. Поэтому для Bitrix я делаю бэкапы базы чаще — каждые 4 часа для активных проектов.
Вот мой скрипт для "горячего" бэкапа Bitrix без остановки сайта:
#!/bin/bash
BITRIX_PATH="/var/www/bitrix"
BACKUP_PATH="/backups/bitrix"
DB_NAME="sitemanager"
DB_USER="bitrix"
DB_PASS="password"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p $BACKUP_PATH/$DATE
# Бэкап базы с блокировкой таблиц
mysqldump --single-transaction --lock-tables=false --routines --triggers -u$DB_USER -p$DB_PASS $DB_NAME > $BACKUP_PATH/$DATE/bitrix_db.sql
# Бэкап файлов с исключениями
tar --exclude='bitrix/cache/*' \
--exclude='bitrix/managed_cache/*' \
--exclude='bitrix/tmp/*' \
--exclude='bitrix/backup/*' \
--exclude='*.log' \
-czf $BACKUP_PATH/$DATE/bitrix_files.tar.gz \
-C $BITRIX_PATH .
# Проверяем размер бэкапа
BACKUP_SIZE=$(du -sh $BACKUP_PATH/$DATE/bitrix_files.tar.gz | cut -f1)
echo "Backup size: $BACKUP_SIZE"
# Загружаем в облако
/usr/local/bin/rclone copy $BACKUP_PATH/$DATE/ selectel:bitrix-backups/$DATE/
echo "Bitrix backup completed: $DATE"
Также важно помнить про лицензии Bitrix. При восстановлении на новом сервере может потребоваться перепривязка лицензии. Для этого в личном кабинете партнёра нужно сменить домен привязки.
И ещё один момент — если используете модули от сторонних разработчиков, обязательно сохраняйте их установочные файлы отдельно. Бывает, что модуль снимают с продажи или разработчик закрывается, и восстановить функционал становится проблематично.
Бэкапы WordPress: плагины и ручные методы
WordPress в плане бэкапов проще Bitrix — структура более стандартная, есть отличные плагины. Но и тут есть свои подводные камни.
Плагины для автоматических бэкапов:
UpdraftPlus — мой фаворит. Бесплатная версия умеет делать полные бэкапы и загружать их в облако. Платная добавляет инкрементные бэкапы и миграцию. Настраивается за 5 минут, работает стабильно.
BackupBuddy — платный, но очень мощный. Умеет делать бэкапы в реальном времени, есть функция восстановления одним кликом. Использую для VIP-клиентов.
Duplicator — больше для миграции, чем для регулярных бэкапов. Но создаёт удобные пакеты для переноса сайта.
Но я всё равно настраиваю дублирующий ручной бэкап через cron. Плагины могут сломаться, обновиться с багами, или их может отключить другой разработчик.
Вот мой универсальный скрипт для WordPress:
#!/bin/bash
WP_PATH="/var/www/wordpress"
BACKUP_PATH="/backups/wordpress"
DB_NAME="wordpress"
DB_USER="wp_user"
DB_PASS="wp_password"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p $BACKUP_PATH/$DATE
# Получаем настройки БД из wp-config.php
DB_NAME=$(grep DB_NAME $WP_PATH/wp-config.php | cut -d "'" -f 4)
DB_USER=$(grep DB_USER $WP_PATH/wp-config.php | cut -d "'" -f 4)
DB_PASSWORD=$(grep DB_PASSWORD $WP_PATH/wp-config.php | cut -d "'" -f 4)
# Бэкап базы данных
mysqldump -u$DB_USER -p$DB_PASSWORD $DB_NAME > $BACKUP_PATH/$DATE/wp_database.sql
# Бэкап файлов (исключаем кеш плагинов)
tar --exclude='wp-content/cache/*' \
--exclude='wp-content/uploads/cache/*' \
--exclude='*.log' \
-czf $BACKUP_PATH/$DATE/wp_files.tar.gz \
-C $WP_PATH .
# Отдельно сохраняем wp-config.php (иногда в нём есть кастомные настройки)
cp $WP_PATH/wp-config.php $BACKUP_PATH/$DATE/
# Создаём информационный файл
echo "WordPress backup created: $(date)" > $BACKUP_PATH/$DATE/backup_info.txt
echo "WordPress version: $(grep wp_version $WP_PATH/wp-includes/version.php | cut -d "'" -f 2)" >> $BACKUP_PATH/$DATE/backup_info.txt
echo "PHP version: $(php -v | head -n1)" >> $BACKUP_PATH/$DATE/backup_info.txt
echo "WordPress backup completed: $DATE"
Особенность WordPress — активные плагины могут мешать восстановлению. Если восстанавливаете на новом сервере с другой версией PHP или MySQL, некоторые плагины могут выдавать ошибки. Поэтому я всегда сначала восстанавливаю базовый WordPress без плагинов, проверяю работу, а потом подключаю дополнения.
И обязательно тестируйте бэкапы после обновления WordPress или плагинов. Бывает, что обновление ломает процедуру бэкапа, и вы узнаёте об этом только когда понадобится восстановление.
Бэкапы баз данных: MySQL, PostgreSQL
База данных — это сердце любого сайта. Потерять файлы — неприятно, потерять базу — катастрофа. Поэтому к бэкапам БД у меня особое отношение.
MySQL/MariaDB бэкапы
Стандартный mysqldump подходит для большинства случаев, но у него есть ограничения. Для больших баз (больше 1 ГБ) лучше использовать более продвинутые методы.
Базовый дамп:
# Простой дамп
mysqldump -u root -p database_name > backup.sql
# Дамп с дополнительными опциями
mysqldump --single-transaction --routines --triggers --lock-tables=false -u root -p database_name > backup.sql
# Дамп нескольких баз
mysqldump --databases db1 db2 db3 -u root -p > multiple_backup.sql
# Дамп всех баз
mysqldump --all-databases -u root -p > all_databases.sql
Для больших баз использую Percona XtraBackup — он делает "горячий" бэкап без блокировки таблиц:
# Установка Percona XtraBackup
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
dpkg -i percona-release_latest.generic_all.deb
apt update
apt install percona-xtrabackup-80
# Создание бэкапа
xtrabackup --backup --target-dir=/backups/mysql/$(date +%Y%m%d_%H%M%S) --user=root --password=password
# Подготовка бэкапа для восстановления
xtrabackup --prepare --target-dir=/backups/mysql/20261215_030001
PostgreSQL бэкапы
Для PostgreSQL использую pg_dump и pg_basebackup:
# Логический дамп одной базы
pg_dump -h localhost -U postgres -d database_name > backup.sql
# Дамп с сжатием
pg_dump -h localhost -U postgres -d database_name | gzip > backup.sql.gz
# Дамп всех баз
pg_dumpall -h localhost -U postgres > all_databases.sql
# Физический бэкап всего кластера
pg_basebackup -h localhost -U postgres -D /backups/postgres/$(date +%Y%m%d_%H%M%S) -Ft -z -P
Важный момент — тестирование восстановления. Я регулярно проверяю, что дампы можно импортировать без ошибок:
# Тест восстановления MySQL
mysql -u root -p -e "CREATE DATABASE test_restore;"
mysql -u root -p test_restore < backup.sql
mysql -u root -p -e "SELECT COUNT(*) as table_count FROM information_schema.tables WHERE table_schema='test_restore';"
mysql -u root -p -e "DROP DATABASE test_restore;"
# Тест восстановления PostgreSQL
createdb test_restore
psql test_restore < backup.sql
psql -c "\dt" test_restore
dropdb test_restore
Для критически важных проектов настраиваю репликацию. Master-slave репликация даёт дополнительную защиту — если основной сервер упадёт, можно быстро переключиться на реплику.
Мониторинг бэкапов и оповещения
Делать бэкапы — это полдела. Нужно ещё убеждаться, что они создаются успешно и вовремя. У меня был случай, когда скрипт бэкапа "тихо" ломался три недели, а я узнал об этом только когда понадобилось восстановление.
Поэтому я настраиваю мониторинг на нескольких уровнях:
1. Проверка выполнения скриптов
Каждый скрипт бэкапа отправляет уведомление о результате:
# В конце скрипта бэкапа
if [ $? -eq 0 ]; then
echo "Backup completed successfully: $(date)" | mail -s "Backup OK - $HOSTNAME" admin@example.com
else
echo "Backup FAILED: $(date)" | mail -s "BACKUP FAILED - $HOSTNAME" admin@example.com
fi
# Альтернативно — отправка в Telegram
curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
-d chat_id="$CHAT_ID" \
-d text="✅ Backup completed successfully on $HOSTNAME at $(date)"
2. Проверка размера и возраста бэкапов
#!/bin/bash
BACKUP_DIR="/backups"
EXPECTED_MIN_SIZE="100M" # Минимальный ожидаемый размер
MAX_AGE_HOURS=25 # Максимальный возраст в часах
# Находим последний бэкап
LATEST_BACKUP=$(find $BACKUP_DIR -name "*.tar.gz" -type f -printf '%T@ %p\n' | sort -n | tail -1 | cut -d' ' -f2-)
if [ -z "$LATEST_BACKUP" ]; then
echo "❌ No backups found!" | mail -s "BACKUP ALERT" admin@example.com
exit 1
fi
# Проверяем возраст
BACKUP_AGE=$(find "$LATEST_BACKUP" -mtime +1 | wc -l)
if [ $BACKUP_AGE -gt 0 ]; then
echo "⚠️ Latest backup is older than $MAX_AGE_HOURS hours: $LATEST_BACKUP" | mail -s "BACKUP ALERT" admin@example.com
fi
# Проверяем размер
BACKUP_SIZE=$(du -b "$LATEST_BACKUP" | cut -f1)
MIN_SIZE_BYTES=$(numfmt --from=iec $EXPECTED_MIN_SIZE)
if [ $BACKUP_SIZE -lt $MIN_SIZE_BYTES ]; then
echo "⚠️ Backup size is too small: $(du -h "$LATEST_BACKUP" | cut -f1)" | mail -s "BACKUP ALERT" admin@example.com
fi
3. Внешний мониторинг
Использую сервисы типа UptimeRobot или Pingdom не только для проверки доступности сайта, но и для мониторинга бэкапов. Создаю специальный endpoint, который возвращает информацию о последнем бэкапе:
<?php
$backup_dir = '/backups';
$latest_backup = '';
$backup_time = 0;
// Находим последний бэкап
$files = glob($backup_dir . '/*.tar.gz');
if ($files) {
usort($files, function($a, $b) {
return filemtime($b) - filemtime($a);
});
$latest_backup = $files[0];
$backup_time = filemtime($latest_backup);
}
$hours_ago = round((time() - $backup_time) / 3600, 1);
// Если бэкап старше 25 часов — ошибка
if ($hours_ago > 25) {
http_response_code(500);
echo "ERROR: Last backup is $hours_ago hours old";
} else {
echo "OK: Last backup $hours_ago hours ago";
}
?>
Этот скрипт размещаю по адресу example.com/backup-status.php и добавляю в UptimeRobot. Если бэкапы перестают создаваться, сервис пришлёт уведомление.
Также рекомендую вести журнал восстановлений. Записывайте, когда и почему пришлось восстанавливаться, сколько времени это заняло, какие были проблемы. Эта информация поможет улучшить процедуры бэкапа.
Частые ошибки при работе с бэкапами
За годы практики я видел все возможные косяки с бэкапами — как свои, так и коллег. Расскажу о самых частых ошибках, чтобы вы их не повторяли.
Ошибка №1: Хранение бэкапов на том же сервере
Классика жанра. Делают бэкапы в папку /backups на том же диске, где лежит сайт. Сервер сгорает — и сайт, и бэкапы пропадают. Обязательно дублируйте копии на внешние носители.
Ошибка №2: Не тестировать восстановление
Бэкап, который нельзя восстановить — это не бэкап, а самообман. Регулярно проверяйте свои копии на тестовом сервере. У одного клиента полгода создавались бэкапы базы, а когда понадобилось восстановление, оказалось, что в SQL-дампе не хватает команд CREATE DATABASE.
Ошибка №3: Игнорирование конфигурационных файлов
Сохраняют только код и базу, забывая про .htaccess, nginx.conf, SSL-сертификаты. Сайт вроде восстанавливается, но работает неправильно — не работают ЧПУ, нет HTTPS, ломается кеширование.
Ошибка №4: Слишком редкие бэкапы
Раз в месяц — это мало для любого активного сайта. Интернет-магазин за месяц может получить тысячи заказов, добавить сотни товаров. Потерять месяц данных — катастрофа.
Ошибка №5: Отсутствие версионности
Делают один файл backup.tar.gz и каждый раз его перезаписывают. А если повреждения в базе были замечены не сразу? Тогда и единственный бэкап оказывается битым.
Ошибка №6: Неправильные права доступа
После восстановления забывают проставить корректные права на файлы. Сайт не работает из-за 403 ошибок, или наоборот — слишком открытые права создают дыры в безопасности.
# Правильные права для WordPress
find /var/www/wordpress/ -type d -exec chmod 755 {} \;
find /var/www/wordpress/ -type f -exec chmod 644 {} \;
chmod 600 wp-config.php
# Правильные права для Bitrix
find /var/www/bitrix/ -type d -exec chmod 755 {} \;
find /var/www/bitrix/ -type f -exec chmod 644 {} \;
chmod 600 .settings.php
Ошибка №7: Забывать про зависимости
Восстанавливают сайт на сервере с другой версией PHP или MySQL, и половина функций перестаёт работать. Всегда документируйте системные требования вместе с бэкапом.
Ошибка №8: Отсутствие уведомлений
Настроили автоматические бэкапы и забыли. А скрипт уже месяц падает с ошибкой, но никто не знает. Обязательно настраивайте мониторинг и алерты.
Я видел проект, где разработчик настроил бэкапы через cron, но указал неправильный путь к mysqldump. Скрипт работал, отчёты приходили, но дампы базы были пустыми. Обнаружили это только через полгода при попытке восстановления.
Чтобы избежать подобных проблем, ведите чек-лист проверки бэкапов и регулярно его выполняйте. Лучше потратить час в месяц на проверку, чем потом неделю на восстановление данных по крупицам.
И помните: идеального решения для бэкапов не существует. Но грамотно настроенная система резервного копирования может спасти ваш бизнес и нервы в критический момент. Если у вас нет времени или знаний для настройки — обратитесь к специалистам. Безопасность сайта и надёжность бэкапов — это не та область, где стоит экономить.
Нужна профессиональная настройка системы резервного копирования?
Наши специалисты помогут настроить автоматические бэкапы и обеспечить максимальную безопасность ваших данных.