Как перенести сайт на другой хостинг без потери данных

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

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

В руководстве разберём перенос с сохранением домена. Примеры используют условный адрес example.com: заменяйте его своим доменом. Они не требуют переносить регистрацию домена к новому провайдеру.

Что нужно перенести кроме файлов

Начните с инвентаризации. Частая причина неудачного переезда — сервис, о существовании которого вспомнили уже после отключения старого аккаунта. Например, сайт открывается, но перестали отправляться уведомления, потому что SMTP-пароль остался только в прежней панели.

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

Проверьте совместимость нового хостинга

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

Сравните версии PHP у веб-сервера и в командной строке. Команда php -v показывает CLI-интерпретатор; сайт может обслуживаться другой версией. Подробно выбор окружения разобран в статье как выбрать версию PHP для сайта, а требования к размещению — в руководстве по PHP-хостингу.

Не совмещайте переезд с обновлением CMS, темы, всех расширений и major-версии СУБД. Чем больше независимых изменений, тем сложнее найти причину ошибки и вернуться к рабочему состоянию. Сначала воспроизведите исправный сайт на новом месте, затем планируйте отдельное обновление.

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

Выберите окно переноса и определите допустимую паузу

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

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

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

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

Шаг 1. Сохраните DNS-зону и снизьте TTL заранее

Запишите текущие A, AAAA, CNAME, MX и TXT-записи, а также используемые NS-серверы. Домен может использовать внешнюю почту, сервис подтверждения владения или отдельный поддомен приложения. Копировать только запись основного сайта недостаточно при смене всей зоны.

Если планируете уменьшить TTL записи, сделайте это заранее: старое значение должно успеть истечь у кеширующих резолверов. Изменение TTL за минуту до переноса не очистит уже сохранённые ответы.

При сохранении DNS-провайдера обычно достаточно заменить адрес сайта в A-записи и при необходимости AAAA. Менять NS ради самого факта переезда не обязательно. Подробности подключения и проверки адресов есть в статье как привязать домен к хостингу.

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

Шаг 2. Сделайте независимую резервную копию

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

Для WordPress официальная документация по резервному копированию отдельно рассматривает файлы и базу. Тот же принцип применим к другим CMS: без одного из компонентов восстановление часто оказывается неполным.

На Linux содержимое архива можно проверить без распаковки:

tar -tzf site-backup.tar.gz | head -n 30
sha256sum site-backup.tar.gz

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

Не храните архив с конфигурацией и паролями в доступной посетителям папке. Название вроде backup-old-final.zip не защищает файл от скачивания.

Шаг 3. Создайте сайт и базу на новой площадке

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

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

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

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

Шаг 4. Скопируйте файлы

Для небольшого проекта подойдёт архив: загрузите, распакуйте и проверьте структуру. Частая ошибка — получить лишнюю вложенность site/site/public_html, из-за которой сервер показывает пустую страницу или список файлов.

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

rsync -avz --dry-run /home/account/site/ user@new-server:/home/account/site/
rsync -avz /home/account/site/ user@new-server:/home/account/site/

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

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

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

Шаг 5. Импортируйте базу данных

Для MySQL пример экспорта выглядит так:

mysqldump --single-transaction --quick --no-tablespaces \
  -u db_user -p db_name > site.sql

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

Импорт выполняется в заранее созданную пустую базу:

mysql -u new_db_user -p new_db_name < site.sql

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

Если используется MariaDB или другая СУБД, выбирайте соответствующие инструменты и совместимый формат. Важные различия экспорта описаны в руководстве MySQL по mysqldump.

Шаг 6. Обновите настройки приложения

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

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

Разверните SSL-сертификат для боевого имени. Если нужно выпустить его до смены A-записи, рассмотрите DNS-проверку владения или возможность панели. Проверять HTTPS через отключение проверки сертификата недостаточно: посетитель будет использовать обычную строгую проверку.

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

Шаг 7. Проверьте новый сервер до смены DNS

Открытие IP-адреса не проверяет домен: виртуальный хост и сертификат выбираются с учётом имени. Для точной проверки можно использовать локальный файл hosts или curl --resolve:

curl --resolve example.com:443:203.0.113.20 \
  -sS -o /dev/null -w '%{http_code}\n' https://example.com/

203.0.113.20 — адрес из диапазона для документации; укажите реальный IP новой площадки. Команда направляет этот запрос на новый сервер, сохраняя доменное имя и TLS-проверку.

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

Шаг 8. Выполните финальную синхронизацию

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

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

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

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

Шаг 9. Переключите домен

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

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

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

Шаг 10. Проведите проверку после переключения

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

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

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

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

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

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

Если адрес действительно изменился, настройте адресный постоянный редирект на соответствующую новую страницу. Не отправляйте все старые URL на главную: посетитель теряет нужный материал, а поисковая система — соответствие страниц.

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

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

План отката

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

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

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

Типичные ошибки

Пример плана переезда небольшого магазина

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

За день до окна работ команда проверяет доступы, копии, DNS и возможность вернуть прежний адрес. Оператор знает время паузы, разработчик — порядок синхронизации, владелец — критерии отмены. Если новая площадка не проходит тестовую оплату, переключение не начинается.

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

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

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

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

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

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

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

Что записать в отчёт о завершении

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

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

Через выбранный период наблюдения повторно проверьте ошибки, почту, задания и рост данных. Успешный первый час не исключает задачу, которая запускается только ночью или раз в неделю.

Частые вопросы

Нужно ли переносить домен к новому регистратору?

Нет. Регистрация домена, DNS и размещение сайта — разные услуги. Для смены хостинга обычно достаточно изменить нужные DNS-записи.

Можно ли переехать совсем без простоя?

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

Достаточно ли бесплатного переноса силами провайдера?

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

Когда отключать старый хостинг?

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

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

• Составлен список файлов, баз, почты и интеграций.

• Подтверждена совместимость нового окружения.

• Сохранена DNS-зона и подготовлено окно работ.

• Сделана и проверена независимая копия.

• Новая площадка проверена до изменения DNS.

• Остановлена запись на старой стороне и выполнена финальная синхронизация.

• Проверены HTTPS, формы, заказы, почта и фоновые задачи.

• Сохранены рабочие URL, правила индексации и план отката.

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