Menu
Вы когда-нибудь теряли данные интернет-магазина за сутки до Чёрной пятницы? Я - нет, но знаю тех, - кто да. История классическая: владелец полагался на "автоматические бэкапы хостинга", а они лежали на том же сервере, который безвозвратно умер. Злодей зашёл через уязвимый плагин, удалил всё, а самая "свежая" копия была на компьютере, полугодовой давности, лежала там ещё с момента переезда на этот хостинг. Потеряны заказы, клиенты ушли к конкурентам, репутация подорвана. Скажите, это бизнес?
В этой статье я расскажу, как построить надёжную систему резервного копирования именно для сайта, который приносит вам деньги. Без воды, с примерами, расчётами RPO/RTO и чётким пониманием, какие типы бэкапов выбрать. А ещё вы узнаете, почему "бэкап на том же сервере" - это не бэкап, и куда нужно смотреть при выборе облачного хранилища. Поехали.
Для частного пользователя потеря фотографий котика - трагедия, но не смертельная. Для бизнеса потеря базы данных заказов, клиентских профилей или конфигурации интернет-магазина - это прямые убытки, потеря лояльности и штрафы за утечку персональных данных (152-ФЗ никто не отменял). По оценкам аналитиков, час простоя среднего интернет-магазина обходится в 50 000 - 200 000 рублей. А восстановление сайта "с нуля" может занять недели, а то и месяцы.
Причины потери данных на бизнес-сайтах:
Сайт - это не только файлы в корневой папке. Полный бэкап бизнес-сайта должен включать:
Для бизнеса критичны два параметра: объём хранилища и скорость восстановления. Рассмотрим основные типы применительно к веб-проектам.
Полный бэкап (full backup) - копируются все файлы и вся БД. Занимает много места (например, 50 ГБ), но для восстановления нужна только одна копия. Идеально делать полный бэкап раз в неделю. Для маленьких сайтов (до 5 ГБ) можно делать полный бэкап каждый день, особенно если бюджет позволяет хранить много копий.
Инкрементный бэкап (incremental backup) - сохраняются только изменения с момента последнего бэкапа (полного или инкрементного). Занимает мало места: допустим, в понедельник изменилось 200 МБ - инкремент сохранит их. Во вторник - ещё 100 МБ. Цепочка: полный + инкр1 + инкр2 + инкр3. Восстановление дольше, но экономит до 80% дискового пространства. Идеально для сайтов с частыми обновлениями.
Дифференциальный бэкап (differential backup) - сохраняются все изменения с момента последнего полного бэкапа. Каждый дифференциальный бэкап растёт (пн - 200 МБ, вт - 300 МБ, ср - 400 МБ). Восстановление быстрее, чем инкрементное (нужен полный + последний дифференциальный). Компромисс для средних проектов.
Для бизнес-сайта я рекомендую комбинацию: полный бэкап раз в неделю + инкрементные каждый день (или каждые 6 часов). Если сайт высоконагруженный и изменения критичны, можно делать инкременты каждый час и синхронизировать файлы с помощью rsync.
Продвинутые системы бэкапа (например, Kopia, Borg) используют дедупликацию - хранят только уникальные блоки данных. Это позволяет держать десятки копий почти без увеличения места. Для больших проектов - настоящий маст-хэв.
Золотое правило 3-2-1 (три копии, два носителя, одна оффлайн) работает и для сайтов. Но для бизнеса есть нюансы.
Пример хорошей стратегии:
Не обязательно хранить 4 копии, но 3 - минимум.
RPO (Recovery Point Objective) - максимальный период потери данных. Если вы делаете бэкап раз в сутки и сайт упал в 14:00, вы потеряете данные с 00:00 до 14:00. Для интернет-магазина это 14 часов заказов. Рассчитайте: средний чек 2000 руб, 20 заказов в час = 40 000 руб/час. За 14 часов - 560 000 руб. Может, стоит делать бэкап каждый час?
RTO (Recovery Time Objective) - максимальное время восстановления. Восстановление может занять 6-12 часов (найти специалиста, оплатить новый хостинг, закачать файлы, всё отладить). За это время вы теряете уже не данные, а доступность сайта. Плюс недовольство клиентов.
Для бизнес-сайтов рекомендуется:
Хранилище бэкапов должно быть надёжным и географически удалённым. Рассмотрим варианты для бизнеса.
Отдельный диск на сервере (например, /backup на втором диске). Плюс: высокая скорость восстановления. Минус: при аппаратном сбое основного сервера диск может тоже выйти из строя. Подходит как промежуточное хранилище.
Отдельный сервер (backup server) в той же сети. Лучше, но при пожаре/взломе сети может пострадать.
Облачные объектные хранилища (S3, Selectel, Yandex, VK Cloud, Google Cloud). Плюсы: автоматическая репликация, гарантия доступности, возможность включить Object Lock. Минусы: плата за трафик при восстановлении (если сайт большой, может быть существенно).
Glacier-хранилища (Deep Archive, Glacier Flexible Retrieval). Очень дёшево на хранении, но восстановление занимает часы и стоит дополнительно. Используйте как третью, "оффлайн" копию.
Удалённый FTP/SFTP (другой хостинг или VPS). Простой и дешёвый способ. Но без встроенной дедупликации и версионности - только как второй слой.
Ручные бэкапы - зло. Автоматизация - ваш друг.
WordPress: Плагины UpdraftPlus (бесплатно, инкременты, S3, Dropbox, Google Drive, FTB, почта), WP Time Capsule (инкрементные, как Time Machine), BackupBuddy (платный). UpdraftPlus позволяет настроить расписание, разделять файлы и БД, даже делать автоматическое восстановление из облака на новый домен. Для корпоративных сайтов также рекомендую BlogVault (бэкап + миграция + мониторинг).
OpenCart: Есть плагины Backup and Restore (бесплатный, но ограниченный), A2 Hosting Backup. Чаще проще настроить бэкап на уровне хостинга или скриптом через cron.
1С-Битрикс: Встроенный инструмент "Резервное копирование" (в админке → Настройки → Инструменты). Поддерживает полный бэкап в архив, FTP, S3. Можно настроить cron через php-скрипт /bitrix/backup/backup.php. Для Битрикса важно также бэкапить пользовательские файлы и медиабиблиотеку (в базе пути, в файлах - картинки).
Самописные сайты (PHP, Node.js, Python): Используйте системные средства: скрипт с rsync + mysqldump + tar + gpg, запускаемый через cron. Или готовые инструменты: Duplicati (графический интерфейс, работает с любым веб-сервером), BorgBackup (дедупликация, шифрование, монтирование), Kopia (современная, поддержка S3).
Пример скрипта для cron (Linux):
|
1 2 3 4 5 6 7 8 9 10 11 12 |
#!/bin/bash BACKUP_DIR=/backup/$(date +%Y%m%d) mkdir -p $BACKUP_DIR mysqldump --single-transaction -u user -ppass dbname > $BACKUP_DIR/db.sql rsync -avz /var/www/html $BACKUP_DIR/files tar -czf $BACKUP_DIR/archive.tar.gz $BACKUP_DIR # encrypt with gpg gpg --symmetric --passphrase "секрет" $BACKUP_DIR/archive.tar.gz # upload to S3 using aws cli aws s3 cp $BACKUP_DIR/archive.tar.gz.gpg s3://my-bucket/backups/ # remove local files older than 7 days find /backup -type d -mtime +7 -exec rm -rf {} \; |
Бэкап без проверки восстановления - не бэкап. Раз в месяц выделите время на тестовое восстановление на резервном сервере или в контейнере. Сценарий для WordPress через UpdraftPlus:
Если вы используете ручной скрипт, то восстановление: копируете файлы из архива, импортируете дамп БД через mysql, правите wp-config.php (пароли, соли).
Важно: при восстановлении на боевой сервер не забудьте выключить кэш.
Я насмотрелся на "бэкап-стратегии" клиентов, которые обходились им слишком дорого.
Ошибка 1. Единственный бэкап на том же сервере. Это не спасает от физического уничтожения файлов на сервере. И от обычной человеческой безалаберности.
Всегда держите копию в облаке или на другом сервере.
Ошибка 2. Хранение бэкапов в той же учётной записи, что и сайт. Если взломают админку WordPress, то и бэкапы с теми же ключами доступа тоже скомпрометированы. Используйте отдельную учётную запись с минимальными правами (только PutObject, без Delete).
Ошибка 3. Отсутствие шифрования. Ваши бэкапы могут украсть с провайдера. Всегда шифруйте перед отправкой в облако. UpdraftPlus умеет шифровать встроенным AES.
Ошибка 4. Слишком редкие бэкапы. Раз в неделю - это не для бизнеса. Если у вас 200 заказов в день, каждый час простоя - потеря денег.
Ошибка 5. Никто не отвечает за бэкапы. Назначьте ответственного, составьте инструкцию по восстановлению и держите её в надёжном месте.
Резервное копирование бизнес-сайта - это не затраты, а страховка. Вы не ездите без ОСАГО, так почему же ваш сайт остаётся без бэкапов? Настройте автоматические копии сегодня, проверьте восстановление через неделю и спите спокойно, зная, что даже если сервер сгорит, вы восстановите магазин в течение часа.
Рекомендую начать с малого: выберите плагин (UpdraftPlus для WordPress), настройте ежедневный инкрементный бэкап на облачное хранилище (S3, Selectel, Yandex Cloud). Добавьте второй слой - еженедельный полный бэкап на отдельный диск или FTP. И не забывайте про правило 3-2-1.
Ваши данные стоят дороже, чем несколько сотен рублей в месяц на надёжный бэкап. Не рискуйте.
Cloudflare окончательно заблокирован в РФ ещё летом 2025 года.
Функцию фильтрации ботов Cloudflare взял на себя российский антибот Killbot.
Принцип работы отличается от привычного, отслеживаются не знакомые всем при настройке других антибот решений параметры (входящие IP адреса, AS подсети ботов, User Agent и прочее, всё это легко подделывается), а уникальные для каждого набора браузеров слепки.
По отличию оригинального браузера от модифицированного, тот или иной заход определяется либо как заход реального посетителя, либо как заход бота.
Чтобы не повторяться - расписывал более подробно в статьях:
Попробовать бесплатно. При регистрации в Killbot введите промокод
promo13
и получите месяц тестирования платного тарифа Killbot (фильтрация трафика, 1000 руб) и Ads (отключение показа рекламы поведенческим ботам, 1000 руб) в качестве бонуса. Этого вам хватит на то, чтобы понять, подходит вам данное решение, или нет. На данный момент - в Рунете нет более достойной альтернативы, по соотношению цена-качество. Срок действия промокода ограничен по времени, куда-то записывать его нет смысла. В следующий раз промокод уже будет другой, поэтому использовать его нужно сейчас, когда вы читаете этот текст. Промокод действует только в форме регистрации. Если аккаунт уже создан - создайте новый, на другой почте, и при регистрации в последнем поле введите промокод.
Подпишитесь на Telegram канал / MAX для того, чтобы всегда быть в курсе последних новостей и обновленных настроек для защиты от ботов, а также оперативно получать новые материалы, выходящие на antibot24.ru
Автор статей: Сергей (AntiBot24). Эксперт в области фильтрации поведенческого трафика, настройки антибот систем. Высший рейтинг на Kwork, более 680 отзывов, 100% заказов успешно сдано, 56% повторных заказов. Пишу подробные статьи, инструкции по фильтрации ботов в своем блоге antibot24.ru
Всегда нужно иметь в виду, что те советы, которые вы прочли в статьях - это лишь часть настроек, которые я делаю при профессиональной экспертной настройке фильтрации поведенческих ботов. Все остальное - это непубличные профессиональные секреты. Любая информация, становящаяся общедоступной - достаточно быстро устаревает и перестает быть эффективной.
Если вы столкнулись с повышенной роботностью в Яндекс метрике, увеличением числа прямых заходов, увеличением количества отказов - вы всегда можете заказать у меня настройку Killbot.