Бэкап стоит копейки, а его отсутствие однажды стоит всего сайта. Разобрали, как правильно настроить резервное копирование, по какому правилу хранить копии и почему «бэкап на том же хостинге» — это иллюзия защиты.
Если коротко: правильное резервное копирование сайта — это автоматические копии по расписанию, которые хранятся отдельно от сайта (на другом сервере или в облаке), в нескольких версиях, и которые вы хотя бы раз в квартал реально разворачиваете для проверки. Идеальный ориентир — правило «3-2-1»: три копии данных, на двух разных носителях, одна из них вне основной площадки. Настраивается это один раз, а спасает бизнес целиком. Ниже — как сделать по-человечески и не наступить на типовые грабли.
Про бэкапы вспоминают в двух ситуациях: когда настраивают сайт «с запасом на будущее» и когда сайт уже лёг, а копии нет. Вторая ситуация встречается, к сожалению, чаще. Сайт падает после неудачного обновления, хостинг сбоит, разработчик случайно сносит каталог, приходит шифровальщик — и выясняется, что последний бэкап делали полгода назад вручную, да и тот не сохранился.
Зачем вообще нужны резервные копии
Бэкап — это не про предотвращение проблем, а про восстановление после них. Защита от взлома снижает вероятность беды, а резервная копия гарантирует, что даже если беда случилась, вы вернётесь в строй за час, а не начнёте с нуля. Это разные вещи, и одно не заменяет другое.
Сценариев, когда копия спасает, больше, чем кажется. Вот основные — и ни один из них не экзотика, все встречаются на реальных проектах.
- Взлом и заражение. Сайт заразили вирусом или встроили редиректы — откатываетесь на чистую версию до взлома.
- Неудачное обновление. Обновили модуль или ядро, что-то сломалось — возвращаете рабочее состояние.
- Человеческая ошибка. Сотрудник или подрядчик удалил не то — восстанавливаете за минуты.
- Сбой хостинга. Упал сервер или повредились данные — разворачиваете сайт на резервной площадке.
- Проблемы у провайдера. Хостер ушёл с рынка или заблокировал аккаунт — переезжаете с полной копией на руках.
Что входит в полный бэкап сайта
Многие думают, что бэкап — это «файлы сайта». На деле полная копия состоит из двух частей, и без любой из них восстановление будет неполным.
- Файлы. Весь код, шаблоны, картинки, загруженные документы, настройки. Это «тело» сайта.
- База данных. Тексты, товары, заказы, пользователи, настройки модулей. Это «память» сайта — без неё файлы пустые.
Отдельный нюанс для интернет-магазинов: база данных меняется постоянно — каждый новый заказ это новые строки. Поэтому для магазина частота копирования базы должна быть выше, чем для сайта-визитки, иначе при сбое потеряются свежие заказы. Файлы меняются реже, их можно копировать пореже.
Правило 3-2-1: золотой стандарт хранения
Простое правило, которое придумали айтишники и которое работает для любого бизнеса. Расшифровывается так: 3 копии данных, на 2 разных типах носителей, и 1 копия — за пределами основной площадки. Звучит сложно, на практике — нет.
На примере сайта это выглядит так: рабочая версия живёт на хостинге, одна копия делается автоматически на том же сервере (для быстрого отката), а ещё одна уезжает в облако или на отдельное хранилище. Если упадёт хостинг целиком — у вас останется внешняя копия. Если ошиблись с обновлением — быстро откатитесь с локальной. Так закрываются оба сценария разом.
Как часто делать бэкапы
Частота зависит от того, как часто меняется сайт. Универсального ответа нет, но есть здравые ориентиры. Главный принцип: спросите себя — потерю данных за какой период вы переживёте безболезненно? Вот от этого и пляшите.
| Тип сайта | Частота копий | Сколько версий хранить |
|---|---|---|
| Сайт-визитка, лендинг | 1 раз в неделю | 4–8 последних |
| Корпоративный сайт, блог | 1 раз в 1–3 дня | 10–14 последних |
| Интернет-магазин | База — ежедневно или чаще, файлы — раз в несколько дней | 14–30 последних |
Почему важно хранить несколько версий, а не одну последнюю? Потому что заражение или поломку замечают не сразу. Если вы перезаписываете единственную копию каждый день, то к моменту, когда заметили взлом неделю спустя, свежий бэкап уже заражён. Несколько версий дают глубину отката — возможность вернуться к заведомо чистому состоянию.
Чем делать резервное копирование
Инструментов хватает, и выбор зависит от платформы и того, кто этим занимается. Вот основные подходы — от встроенных в CMS до серверных.
- Встроенные средства CMS. В 1С-Битрикс есть штатное резервное копирование с выгрузкой в облако «1С-Битрикс». Удобно, что копия сразу уезжает вовне.
- Средства хостинга. Многие хостеры делают бэкапы на стороне сервера. Удобно, но проверьте, что копии хранятся отдельно и доступны вам для скачивания.
- Внешние облака. Выгрузка в S3-совместимое хранилище, Яндекс Облако или подобное — копия гарантированно вне площадки сайта.
- Скрипты и серверный cron. Для нестандартных проектов — автоматизация на уровне сервера. Гибко, но требует специалиста.
На наших проектах бэкап без проверки восстановления мы за бэкап не считаем. Раз в квартал берём свежую копию и разворачиваем её на тестовой площадке. Звучит занудно, но именно эта проверка однажды экономит клиенту весь сайт — потому что «битый» архив вы обнаружите заранее, а не в день аварии.
Главная ошибка: бэкап, который не проверяли
Сам факт, что копии делаются, ничего не гарантирует. Архив может оказаться повреждённым, неполным или попросту не разворачиваться из-за несовместимости версий. И узнают об этом ровно в тот момент, когда копия нужна позарез — то есть в худший возможный.
Поэтому проверка восстановления — обязательная часть процесса, а не приятное дополнение. Достаточно раз в квартал развернуть свежую копию на тестовом окружении и убедиться, что сайт поднимается и работает. Для интернет-магазина — проверить, что подтянулись товары и заказы. Это полчаса работы против недель восстановления с нуля.
Кто должен отвечать за бэкапы
Резервное копирование ломается не на технике, а на ответственности. «Бэкапы вроде настроены» — самая опасная формулировка: настроены кем, куда, проверял ли кто-то, что они идут. Если за копии не отвечает конкретный человек, рано или поздно они тихо перестают делаться, а узнаёте вы об этом в день аварии.
Вариантов, по сути, два. Либо в команде есть технический специалист, который держит это в голове и по регламенту, либо копированием занимается подрядчик на техподдержке — тогда за бэкапами и их проверкой следит он, а вы получаете отчёт. Для малого бизнеса в Хабаровске, Комсомольске-на-Амуре или Находке второй путь обычно проще: держать в штате отдельного админа ради бэкапов накладно, а отдать это на обслуживание — недорого и спокойно. Расстояние тут роли не играет — копирование настраивается и контролируется удалённо.
Частые вопросы
Разве хостинг не делает бэкапы сам?
Часто делает, но не всегда и не так, как нужно вам. Уточните частоту, срок хранения, можно ли скачать копию и лежит ли она отдельно от вашего сервера. Полагаться только на хостера рискованно — при блокировке аккаунта вы рискуете потерять и сайт, и его копии разом.
Как часто делать резервное копирование интернет-магазина?
Базу данных с заказами — ежедневно или чаще, файлы — раз в несколько дней. Магазин меняется постоянно, поэтому частота для него выше, чем для визитки. Храните 14–30 последних версий для глубины отката.
Сколько места занимает бэкап и сколько это стоит?
Зависит от размера сайта: визитка — десятки мегабайт, крупный магазин с фото — гигабайты. Хранение в облаке обходится в сотни рублей в месяц — несопоставимо мало на фоне стоимости потери сайта.
Можно ли восстановить сайт, если есть только база без файлов?
Нет, полноценно не выйдет. База — это контент и данные, а файлы — это код и оформление. Для полного восстановления нужны обе части, поэтому копировать надо и то и другое.
Кто должен следить за бэкапами?
Либо ваш технический специалист, либо подрядчик на техподдержке. Главное, чтобы за это отвечал конкретный человек по регламенту, а не «по настроению». Бэкапы без ответственного быстро превращаются в забытые и неактуальные.
Не уверены, что ваши копии вообще делаются и разворачиваются? Проверим текущую схему бэкапов, настроим надёжное копирование с хранением вне сайта и возьмём контроль на себя — удалённо по всему Дальнему Востоку и России. Звоните: 8 800 55-100-10. Подробнее — поддержка и обслуживание сайтов, а если думаете о новом проекте — разработка сайтов.
