Резервные копии сайта и сервера: что сохранять и как проверить восстановление

Сколько данных и времени можно потерять

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

Первый показатель часто называют RPO: до какого момента нужно иметь возможность вернуть данные. Второй называют RTO: за какое время требуется восстановить работу. Термины полезны для задания специалисту, но их можно сформулировать обычными словами: «не потерять больше согласованного интервала новых заявок» и «вернуть приём заказов за согласованное время».

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

Определите приоритет восстановления. Иногда сначала нужен приём заявок, затем личный кабинет и история. Запишите допустимые ограничения временного режима. Решать это в момент аварии гораздо труднее.

Что должно входить в копию

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

Для WordPress официальная инструкция по копированию отдельно рассматривает базу и файлы. Архив одной темы не восстановит публикации и пользователей, а одна база не вернёт загруженные фотографии.

Для работающей базы используйте поддерживаемый способ резервирования. Простое копирование её каталога во время записи может дать несогласованный результат. Например, документация PostgreSQL описывает ограничения файлового копирования и требования к согласованным снимкам. Конкретный способ выбирают под СУБД и устройство хранилища.

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

Архив, снимок, реплика и RAID

Эти инструменты выполняют разные задачи. Архив содержит выбранные файлы. Выгрузка базы сохраняет данные способом, который определяет инструмент СУБД. Снимок фиксирует состояние диска или другой сущности в рамках возможностей платформы. Реплика получает изменения из основной системы. RAID объединяет диски для выбранного режима хранения.

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

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

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

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

Где хранить копии и кому давать доступ

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

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

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

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

Как выбрать расписание и сроки хранения

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

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

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

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

Как проверить восстановление в отдельной среде

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

1. Получите набор. Скачайте выбранные файлы, выгрузку базы, конфигурацию и сведения о версии. Проверьте чтение и контрольные суммы, если они предусмотрены.
2. Подготовьте окружение. Установите совместимые программы и отдельные тестовые доступы. Не подключайте копию к рабочей базе по ошибке.
3. Ограничьте действия. Отключите реальные платежи, письма, фоновые задания и запись в CRM. Проверьте это до запуска приложения.
4. Восстановите. Зафиксируйте время и все ручные действия, без которых процедура не завершилась.
5. Сверьте данные. Количества основных записей, несколько последних документов, вложения и настройки. Одинаковое число строк не доказывает совпадение всего содержимого.
6. Пройдите сценарии. Вход, чтение данных, работа формы, загрузка файла и административные операции в безопасном режиме.
7. Оформите результат. Какую копию проверяли, что восстановлено, сколько заняло времени и какие зависимости пришлось искать.

Если архив открывается, но сайт не запускается без утраченного расширения или ключа, проверка ещё не пройдена. Дополните состав копии и повторите восстановление. Если восстановление слишком долгое, пересмотрите способ подготовки окружения или размер набора.

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

План на случай настоящего сбоя

Сначала остановите действия, которые ухудшают состояние, и сохраните имеющиеся данные для разбора. Выберите момент восстановления с учётом времени появления ошибки. Не начинайте с удаления рабочей системы и всех свежих копий.

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

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