Безопасный перенос сайта на новый VPS или диск

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

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

Оценка VPS и подготовка нового хранилища

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

Сначала составьте перечень данных:

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

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

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

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

Защищённая передача файлов

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

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

Проверить подходящий вариант можно на странице Beget.

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

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

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

rsync -aHAX --numeric-ids --info=progress2 \
  -e "ssh -o IdentitiesOnly=yes" \
  /srv/www/example/ deploy@new-server:/srv/www/example/

Параметры -a, -H, -A и -X требуют осознанного применения: они сохраняют разные свойства файлов, но не всегда нужны и могут требовать расширенных прав. Если приложение не использует специальные владельцы, ACL или расширенные атрибуты, состав параметров можно сократить. Важно не копировать вслепую временные каталоги, кэш и открытые журналы, если они не нужны для запуска.

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

Согласованность данных и финальная синхронизация

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

Перед финальной синхронизацией:

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

Перед настройкой откройте Beget и сверьте актуальные условия.

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

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

Проверка сайта до переключения

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

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

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

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

Переключение и план отката

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

Когда требования понятны, перейдите в Beget и проверьте выбранный вариант.

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

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

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

Мониторинг после миграции

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

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

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

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

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

Обложка вдохновлена картиной Виктора Васнецова «Витязь на распутье» (1882). Посмотреть оригинал в Wikimedia Commons.