Содержание
Резервное копирование сайта должно сохранять данные и настройки, из которых можно восстановить работающую систему. Для магазина это обычно база заказов и каталога, пользовательские файлы, код, конфигурация и сведения о внешних зависимостях. Проверяется результат восстановлением на отдельной площадке. Наличие архива в панели хостинга ещё не отвечает на вопросы, сколько данных вы потеряете и когда сайт снова начнёт принимать заказы.
Что должно входить в резервную копию сайта
Начните с перечня того, что понадобится новому администратору на пустом сервере. У него может не быть рабочего приложения, прежних доступов и переписки с разработчиком. Если восстановление требует вспомнить неизвестную настройку, процесс пока зависит от конкретного человека.
| Что сохранить | Зачем это нужно | Частый пробел |
|---|---|---|
| База данных | Заказы, пользователи, каталог, настройки CMS | Архивируют файлы, забывают базу |
| Пользовательские файлы | Фото товаров, документы, вложения | Отдельное хранилище не попало в копию |
| Код и версия выпуска | Запустить совместимое приложение | Репозиторий отличается от кода на сервере |
| Конфигурация окружения | Подключить сервисы и воспроизвести запуск | Неизвестны переменные и расписания |
| Схема инфраструктуры | Восстановить базу, очереди и фоновые задачи | Копируют веб-сервер без остальных компонентов |
| Инструкция и доступы | Получить копии и выполнить восстановление | Всё доступно только через потерянный аккаунт |
Не все элементы нужно хранить одним архивом. Код может находиться в репозитории, файлы в отдельном хранилище, секреты в защищённом хранилище доступов. Важно, чтобы комплект был полным, версии были совместимы, а ответственный мог получить всё необходимое во время аварии.
Пароли и ключи требуют отдельного контроля. Их нельзя размещать в открытой папке бэкапов или передавать всем, кто работает с кодом. Продумайте, кто сможет расшифровать копию, где находится ключ и что произойдёт, если основной администратор недоступен. Зашифрованный архив без доступного ключа не поможет.
Уточните также, как обеспечивается согласованность данных. Копирование файлов работающей базы обычным архиватором может дать непригодный результат. Используйте штатные механизмы вашей СУБД и согласованный способ резервирования. Если документы лежат вне базы, учитывайте связь между записью и файлом на выбранный момент.
Достаточно ли резервного копирования у хостинга
Резервирование у хостинга полезно, но его условия нужно прочитать и проверить. Узнайте, какие данные сохраняются, как часто, сколько версий доступно и кто выполняет восстановление. Отдельно выясните, можно ли получить копию при блокировке основного аккаунта или недоступности панели.
Формулировка «ежедневный бэкап» ничего не говорит о сроке хранения и полноте. Может сохраняться только часть каталогов, а база или внешнее хранилище обслуживаются другим способом. Крупные файлы и отдельные сервисы могут иметь ограничения. Для конкретного тарифа это выясняют у провайдера, а не предполагают по названию услуги.
Копия на том же сервере удобна для быстрого возврата после неудачной правки. При потере сервера, ошибке администратора или компрометации общих доступов она может оказаться недоступной вместе с рабочими данными. Поэтому нужен вариант восстановления за пределами того же места отказа.
Подходящая схема зависит от инфраструктуры: отдельное хранилище, раздельные права, защищённые от изменения версии или изолированные копии. Ограничение удаления нужно проверить фактически. Важна и возможность восстановиться при отказе провайдера, если такой риск входит в согласованные требования.
Как выбрать частоту: RPO и RTO простыми словами
RPO описывает допустимую потерю данных во времени. RTO задаёт целевое время восстановления работы. Эти параметры отвечают на разные вопросы. Частая копия уменьшает потенциальный разрыв в данных, но сама по себе не ускоряет запуск приложения на новом сервере.
Условный пример: база копируется в 02:00, авария случилась в 17:00. При восстановлении только этой копии в ней не будет событий за следующие 15 часов. Часть сведений удастся сверить с оплатой, CRM или учётом, но это отдельная работа. Для магазина с активными продажами такой разрыв может быть неприемлем.
Чтобы выбрать частоту, спросите владельцев процесса, какие данные можно восстановить вручную и за какое время. Затем оцените технологию: полные копии, добавочные копии, журналы изменений, восстановление на момент времени. Конкретный механизм зависит от базы и инфраструктуры. Не каждый тариф хостинга предоставляет все эти возможности.
| Вопрос бизнеса | Что определить технически |
|---|---|
| Сколько новых заказов допустимо потерять? | Целевой RPO и способ получения нужной точки восстановления |
| Как долго можно не принимать покупки? | Целевой RTO и подготовленная площадка |
| Когда заметят повреждение данных? | Глубину истории копий |
| Кто восстановит систему ночью? | Доступы, инструкции и порядок вызова ответственных |
Срок хранения связан ещё и со временем обнаружения ошибки. Если каталог повредили неделю назад, а хранятся только последние несколько копий, все они уже могут содержать повреждение. История должна покрывать разумный для вашего процесса срок обнаружения и разбирательства. Отдельное хранение копий и проверку восстановления также рекомендует британский NCSC.
Как проверить восстановление из резервной копии
Выберите конкретную копию и восстановите её в изолированном окружении. Не распаковывайте архив поверх работающего сайта ради проверки. Заранее убедитесь, что тестовая система не отправит сообщения клиентам, не примет реальную оплату и не запишет тестовые заказы в рабочую 1С.
Начните отсчёт времени в согласованной точке: например, когда ответственный получил уведомление об аварии. Если измерять только импорт базы, из результата выпадут поиск доступов, загрузка архивов и настройка окружения. Для бизнеса важен полный путь до восстановления нужных функций.
Порядок учебного восстановления:
- Получить копию и проверить, к какому моменту относятся данные.
- Подготовить окружение с совместимыми версиями приложения и базы.
- Восстановить базу, файлы и конфигурацию, настроить фоновые задачи.
- Закрыть реальные интеграции и проверить вход ответственных сотрудников.
- Открыть каталог, несколько документов и заказов, выполнить тестовый сценарий.
- Записать время, результат, недостающие элементы и изменения в инструкции.
Главная страница может открываться, когда оформление заказа уже не работает. Поэтому проверяйте функции, ради которых существует сайт. Для магазина это товар, корзина, сохранение заказа, роли сотрудников и необходимые фоновые процессы. Для личного кабинета набор будет другим.
Проверку повторяют после существенных изменений инфраструктуры и по согласованному расписанию. Универсального интервала для всех сайтов нет. Отчёт должен содержать дату, выбранную копию, исполнителя, проверенные сценарии и фактическое время восстановления. Фраза «восстанавливается нормально» не позволит сравнить результат с RTO.
Как не потерять новые заказы и оплаты
Восстановление старой базы возвращает прошлое состояние только части системы. Платёжный провайдер, склад, CRM и 1С могли продолжить работу. После запуска сайт способен показывать заказ неоплаченным, хотя деньги получены, или снова предлагать товар, который уже отгружен.
Перед восстановлением сохраните доступные журналы и данные текущего состояния, если это возможно и безопасно. Определите точку восстановления и период, который предстоит сверить. Для серьёзного инцидента порядок действий должен учитывать причину аварии: копия из скомпрометированной системы тоже требует проверки.
После восстановления сопоставьте события по устойчивым идентификаторам. Отдельно проверьте новые заказы, подтверждённые оплаты, возвраты, резервы и отгрузки. Повторная загрузка не должна создавать дубли. Кто и каким способом выполняет сверку, полезно записать до аварии.
Откат кода после неудачной доработки не всегда требует возврата всей базы. Если изменения позволяют, безопаснее сохранить новые данные и вернуть совместимую версию приложения. Подготовку такого сценария разбираем в статье о доработке интернет-магазина.
Что закрепить в регламенте поддержки
Назначьте владельца резервирования и того, кто проверяет результат. У этих ролей должны быть понятные границы: один человек следит за выполнением задания, другой подтверждает пригодность комплекта к восстановлению. В небольшой команде роли может совмещать один специалист, но обе проверки всё равно нужны.
В регламенте укажите состав копий, расписание, срок хранения, места размещения, доступы, шифрование и порядок восстановления. Зафиксируйте RPO и RTO, уведомления об ошибке и условия проверки. Если услугу выполняет провайдер, отделите его обязанности от обязанностей команды сайта.
Контролировать стоит не только код завершения задания. Проверяйте возраст последней успешной копии, доступность хранилища и признаки неполного результата. Необычно маленький архив или резкое изменение объёма заслуживают проверки, хотя сами по себе ещё не доказывают повреждение. Отдельно отслеживайте дату последнего успешного восстановления.
Для стартовой проверки попросите исполнителя показать три предметных результата: перечень сохраняемых компонентов, доступную историю копий и протокол восстановления. Если последнего нет, статус честнее обозначить как «копирование настроено, восстановление не проверено».
В InTerra первым шагом может быть аудит действующей системы: определить зависимости и проверить, достаточен ли комплект для запуска. После этого резервирование и контроль можно закрепить в регламенте технической поддержки. Состав работ и условия согласуются до начала.
Частые вопросы
Что такое резервное копирование сайта?
Это создание сохраняемых версий данных и компонентов, необходимых для восстановления сайта. В комплект обычно входят база, пользовательские файлы, код и конфигурация. Полнота определяется устройством системы и проверяется запуском из копии.
Чем копия сайта отличается от репозитория с кодом?
Репозиторий обычно хранит исходный код и историю изменений. Рабочая база, новые заказы, загруженные документы и секреты могут в нём отсутствовать. Поэтому репозиторий не заменяет резервирование данных.
Как часто делать бэкап интернет-магазина?
По допустимой потере данных. Если потеря заказов за сутки неприемлема, одной суточной копии недостаточно. Нужный механизм и интервал выбирают после определения RPO и проверки возможностей инфраструктуры.
Можно ли хранить бэкап на том же сервере?
Как дополнительную удобную копию можно, но этого недостаточно для защиты от потери сервера или общих доступов. Нужен независимый вариант, который останется доступным при согласованных сценариях отказа.
Как узнать, что резервная копия работает?
Восстановить её отдельно и проверить основные функции сайта. Зафиксируйте выбранную точку, полноту данных, результат сценариев и затраченное время. Успешное создание архива не заменяет такую проверку.
Что проверить после восстановления магазина?
Доступность покупки, целостность каталога, заказы и изменения после точки восстановления. Оплаты, отгрузки, возвраты и резервы сверяют с внешними системами. До включения обмена убедитесь, что повторная передача не создаст дубли.
