Резервное копирование сайтов в ispmanager: расписание, удалённое хранилище и восстановление

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

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

Надёжная схема резервного копирования должна отвечать на четыре вопроса:

• какие файлы, базы данных и настройки входят в копию;
• где хранятся архивы;
• сколько версий сохраняется и когда удаляются старые;
• проверялось ли восстановление сайта из созданной копии.

В этой статье разберём, как настроить расписание резервного копирования в ispmanager, подключить удалённое хранилище, определить глубину хранения, проверить созданные архивы и восстановить сайт вместе с базой данных.

Что должно входить в резервную копию сайта

Перед настройкой расписания нужно определить, какие данные потребуются для возвращения сайта в рабочее состояние.

Файлы сайта и база данных

Для большинства сайтов минимальный комплект состоит из двух частей:

1. файлов сайта;
2. базы данных.

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

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

Основной модуль резервного копирования ispmanager создаёт копии данных пользователя, включая сайты, базы данных и почтовые ящики. Отдельный модуль резервного копирования сайта позволяет сохранить и восстановить файлы, настройки сайта, связанную базу данных и сведения о SSL-сертификате.

Перед включением автоматического задания составьте перечень данных, которые необходимо сохранить:

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

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

Что ещё проверить перед настройкой

Для каждого сайта зафиксируйте:

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

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

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

Почему копия на том же VPS не защищает от всех аварий

ispmanager позволяет хранить копии локально — в каталоге на сервере. Это удобно для быстрого отката отдельных файлов, но не защищает от потери самого VPS.

Вместе с сервером могут оказаться недоступны:

• рабочий сайт;
• его база данных;
• локальные архивы;
• настройки панели;
• журналы, необходимые для диагностики.

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

Как настроить расписание резервного копирования в ispmanager

В ispmanager расписание настраивается в разделе «Резервные копии» через действие «Расписание». Панель позволяет отдельно указать дни и время создания полных и дифференциальных копий. При выборе времени нужно учитывать именно время сервера.

Чем полная копия отличается от дифференциальной

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

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

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

Для обычного корпоративного сайта начальной схемой может быть:

• одна полная копия в неделю;
• дифференциальные копии в остальные дни;
• запуск в период минимальной посещаемости;
• отдельная проверка результата после первого выполнения.

Это пример, а не универсальная настройка. Для интернет-магазина, CRM или другого сайта с часто изменяющейся базой интервал следует выбирать по допустимой потере данных.

Как выбрать время запуска

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

Перед выбором времени проверьте:

• когда минимальна посещаемость;
• нет ли в этот период других заданий cron;
• когда выполняются обновления;
• не создаются ли параллельно другие архивы;
• достаточно ли производительности и свободного места.

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

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

Как проверить задание после сохранения

После настройки расписания дождитесь первого автоматического запуска и убедитесь, что:

1. копия появилась в разделе резервных копий;
2. дата и время соответствуют расписанию;
3. архив загружен в выбранное хранилище;
4. по пользователю нет ошибки;
5. объём копии выглядит правдоподобно;
6. в панели отсутствуют уведомления об ошибках.

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

Удалённое хранилище, ротация и уведомления

ispmanager поддерживает локальный каталог и несколько типов внешних хранилищ: Dropbox, Google Drive, Amazon S3, S3-совместимые сервисы, FTP и SFTP. Набор вариантов и поля подключения отображаются при выборе типа хранилища.

Как выбрать удалённое хранилище

Для регулярного резервного копирования сайтов обычно подходят:

• S3-совместимое объектное хранилище;
• отдельный сервер с SFTP;
• специализированный облачный сервис из поддерживаемых панелью.

При выборе учитывайте:

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

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

Данные доступа к хранилищу не следует использовать в других сервисах. Для S3 создайте отдельный ключ с доступом только к нужной корзине, а для SFTP — отдельного пользователя и каталог.

После подключения проверьте не только успешное сохранение настроек, но и реальную передачу тестовой копии.

Как определить глубину хранения

Глубина хранения показывает, за какой период можно выбрать состояние данных.

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

Практичная схема должна содержать несколько временных уровней:

• ежедневные копии за последние дни;
• еженедельные копии за несколько недель;
• при необходимости — более редкие долгосрочные копии.

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

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

Оценить требуемый объём можно так:

1. измерить размер первой полной копии;
2. посмотреть средний размер ежедневных изменений;
3. умножить размеры на планируемое количество версий;
4. добавить запас на рост сайта;
5. оставить место для одновременного хранения старой и новой полной копии.

Не задавайте лимит ровно по текущему объёму. Базы, журналы, почта и пользовательские файлы растут.

Как контролировать выполнение

После настройки администратор должен регулярно проверять:

• дату последней успешной копии;
• статус по каждому пользователю;
• наличие архива во внешнем хранилище;
• свободное место;
• уведомления ispmanager;
• изменения размера архива;
• ошибки подключения к хранилищу.

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

В ispmanager стоит включить отправку уведомлений на электронную почту и периодически просматривать раздел «Уведомления». Ошибка копирования не должна оставаться незамеченной до момента аварии.

Как проверить резервную копию и провести тест восстановления

Архив считается рабочим не после создания, а после успешного восстановления.

Проверка должна состоять из двух уровней:

1. контроль задания и содержимого;
2. пробное восстановление.

Что проверить в созданной копии

Откройте резервную копию в ispmanager и убедитесь, что в ней присутствуют:

• нужный пользователь;
• файлы сайта;
• база данных;
• актуальная дата;
• ожидаемый объём;
• необходимые дополнительные данные.

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

Проверяйте архив после:

• первого запуска;
• смены хранилища;
• изменения структуры сайта;
• переноса каталога;
• подключения новой базы;
• существенного обновления CMS;
• изменения исключений.

Почему просмотра архива недостаточно

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

• несовместимая версия PHP;
• отсутствующее расширение;
• неправильные права;
• повреждённая база;
• устаревшие реквизиты подключения;
• неверный путь к каталогу;
• восстановленный старый SSL-сертификат;
• отсутствие фоновых заданий.

Поэтому нужно проверять не только архив, но и работоспособность восстановленного сайта.

Как организовать тест восстановления

Безопаснее выполнять тест на отдельном сайте или в изолированной среде, а не поверх рабочей версии.

Пример порядка действий:

1. создайте отдельный тестовый сайт;
2. закройте его от внешнего доступа;
3. восстановите файлы и базу;
4. скорректируйте адрес и параметры подключения при необходимости;
5. откройте основные страницы;
6. проверьте авторизацию;
7. выполните тестовую операцию записи;
8. проверьте загрузку файлов и работу форм;
9. зафиксируйте продолжительность восстановления;
10. удалите тестовые данные после проверки.

Модуль ispmanager для отдельного сайта поддерживает восстановление копии не только в исходный, но и в другой сайт. Это позволяет проверить архив без перезаписи рабочей среды.

Проверку следует повторять регулярно, а также после изменения схемы резервного копирования.

Как восстановить сайт и базу данных

Перед восстановлением сначала определите масштаб проблемы.

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

Восстановление отдельных файлов

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

Перед операцией:

• сохраните текущую повреждённую версию отдельно;
• проверьте дату архива;
• убедитесь, что выбран правильный сайт;
• определите, будут ли затронуты существующие файлы;
• предупредите ответственного сотрудника.

Не удаляйте текущие данные до проверки архива, если это не требуется самим сценарием восстановления.

Восстановление сайта

Для копии отдельного сайта используется раздел «Сайты» и действие «Восстановить сайт из копии». Панель позволяет выбрать файлы, настройки сайта, базу данных и сведения о сертификате.

Последовательность действий:

1. остановите изменения на сайте, если пользователи продолжают записывать данные;
2. сохраните текущее состояние;
3. выберите архив за нужную дату;
4. отметьте необходимые компоненты;
5. запустите восстановление;
6. проверьте результат в панели;
7. откройте сайт;
8. изучите журналы приложения и веб-сервера;
9. проверьте функции записи;
10. возобновите обычную работу.

Восстановление базы данных

С базой нужно действовать особенно осторожно: её состояние должно соответствовать файлам приложения.

Перед восстановлением определите:

• какая база связана с сайтом;
• какое состояние требуется вернуть;
• какие новые данные будут потеряны;
• существует ли база с таким именем;
• нужно ли сохранить текущую версию для сравнения.

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

После восстановления проверьте:

• подключение приложения;
• кодировку;
• наличие таблиц;
• авторизацию;
• чтение и запись данных;
• фоновые задания;
• последние значимые операции.

Что делать, если восстановление не запускается

Сначала не повторяйте операцию многократно. Зафиксируйте ошибку и проверьте:

1. доступность удалённого хранилища;
2. правильность ключей, логина и пароля;
3. наличие нужных файлов архива;
4. свободное место на VPS;
5. свободное место во временных каталогах;
6. совпадение владельца и прав;
7. отсутствие конфликтующих сущностей;
8. уведомления и журналы ispmanager.

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

Если причина неочевидна, сохраните журналы и обратитесь к специалистам до удаления рабочих данных.

Заключение

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

Главный критерий качества — не количество созданных архивов, а возможность вернуть сайт и базу в рабочее состояние за приемлемое время.

Что почитать дальше

Если панель только установлена, сначала проверьте базовые настройки ispmanager после установки.

Чтобы разобраться со структурой сайта, доменом и поддоменами в панели, используйте инструкцию «Как создать сайт в ispmanager».

Когда стоит обратиться к специалистам

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

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

Кратко

• Резервная копия сайта должна включать файлы и связанную базу данных.
• Локальный архив на исходном VPS не защищает от потери всего сервера.
• Полные и дифференциальные копии нужно запускать по расписанию с учётом нагрузки.
• Удалённое хранилище должно быть независимо от сайта и иметь отдельные реквизиты доступа.
• Глубину хранения выбирают по тому, когда может быть обнаружена ошибка или повреждение данных.
• Свободного места должно хватать на создание новой полной копии до удаления старой.
• Успешный статус задания необходимо подтверждать проверкой содержимого и уведомлений.
• Единственный надёжный способ проверить архив — выполнить тестовое восстановление.