Резервная копия VPS на Beget: что проверить, чтобы сервис восстановился

Когда рабочий обработчик перестаёт отвечать, руководитель видит не термин «VPS», а остановившийся сервис. Первый вопрос — есть ли копия. Второй, более важный, — вернётся ли из неё именно рабочая система, а не только набор файлов.

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

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

Когда «копия есть» ещё не означает «сервис вернётся»

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

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

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

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

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

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

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

Что именно предлагает Beget для виртуальных серверов

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

Доступ к резервному копированию находится в панели управления, в разделе «Backup». В нём есть две вкладки:

• «Автоматическое копирование»;
• «История заданий».

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

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

Само наличие вкладки «История заданий» также полезно воспринимать как часть контроля: резервное копирование должно быть не разовым обещанием, а наблюдаемым процессом. При этом в доступном описании не указаны конкретные сроки хранения, периодичность создания копий или гарантированное время восстановления. Эти параметры нельзя додумывать по одному факту наличия раздела «Backup».

Два способа восстановления — для разных поломок

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

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

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

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

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

Где находятся главные ограничения

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

Это меняет обычную логику «копия хранится отдельно — значит, она всегда доступна». Отдельное хранение защищает от части проблем, но не превращает резервную копию в независимый архив, которым можно пользоваться при любых обстоятельствах.

Второе ограничение — состав файловой копии. Beget не копирует ряд системных файлов и директорий, среди них /boot, /tmp, /proc, /dev, /run, /sys, /var/cache и /swapfile. Полный перечень приведён в инструкции.

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

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

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

Что проверить до того, как считать сервис защищённым

Ниже — проверка, которую может организовать руководитель без погружения в команды Linux.

1. Найдите нужный сервер в разделе «Backup». Проверьте, что он отображается в списке, а рядом есть резервные копии. Зафиксируйте дату, время и размер подходящей копии.
2. Определите сценарий сбоя. Если нужно вернуть один файл или папку, нужен один тип восстановления. Если сервер не загружается или файловая система повреждена, речь может идти о восстановлении целиком.
3. Отделите файлы от базы данных. Спросите у ответственного за сервис, хранится ли его рабочее состояние в базе и каким способом база копируется отдельно. Если такого ответа нет, резервная защита неполна.
4. Запишите последствия полного восстановления. В инструкции указано, что системные настройки могут сброситься, а ядро Linux будет взято из дистрибутива ОС. Нужно заранее понимать, какие параметры после этого придётся проверять.
5. Проверьте сценарий удаления сервера. Зафиксируйте, кто принимает решение об удалении, кто обращается в поддержку при ошибке и какие гарантии остаются в таком случае. Документация Beget предупреждает, что наличие копий после удаления не гарантируется.

Эта проверка не доказывает, что восстановление пройдёт успешно. Она показывает, где именно остаётся неизвестность. Для управленческого решения это ценнее, чем простая отметка «резервное копирование включено».

Что сделать на этой неделе

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

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

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

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

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

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

• Нужна ли база данных лендингу: проверка на примере Beget
• Beget.API: что можно утверждать о переносе приложений
• SSL для n8n: как настроить HTTPS и подготовить сервер
• Виртуальный хостинг Beget: когда хватит без отдельного сервера
• Где разместить Telegram-бота, чтобы он работал без вашего компьютера