Содержание

Подготовка: выбор нового хостинга и создание резервной копии Перенос данных: синхронизация файлов и базы Тестирование и подготовка к переключению DNS Переключение трафика и финальная синхронизация Финализация переноса и проверка стабильности Проверка индексации и SEO после переноса Возможные ошибки после переноса и способы их устранения Финальные рекомендации: как мигрировать без стресса FAQ

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

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

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

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

Подготовка: выбор нового хостинга и создание резервной копии

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

версию PHP;
тип и версию СУБД;
наличие SSL-сертификатов;
доступ к SSH и возможность тонкой настройки сервера.

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

Сделайте полный бэкап

Перед любыми изменениями создайте резервную копию сайта — это ваш «страховой полис» на случай непредвиденных ошибок.

Файлы сайта.
Используйте rsync для синхронизации данных или скачайте архив через FTP. Команда для копирования по SSH может выглядеть так:

 rsync --archive --verbose --progress user@remotehost:/remote/source/ /local/destination/

Здесь разберем ключи подробнее:

--archive (-a) сохраняет структуру каталогов, владельцев, права и временные метки;
--verbose (-v) выводит подробную информацию о процессе синхронизации;
--progress показывает ход передачи, скорость и оставшееся время.

Базы данных.
Для MySQL используйте mysqldump, например:

mysqldump -u username -p database_name > backup.sql

Или воспользуйтесь инструментами админ-панели (phpMyAdmin, Adminer).

Настройте новый сервер

Перед импортом данных убедитесь, что на новом хостинге:

установлены те же версии PHP и СУБД;
активированы необходимые модули;
развернут действующий или тестовый SSL-сертификат.

Современные провайдеры (включая Scalehost) позволяют автоматически развернуть окружение под нужную CMS или фреймворк, что сокращает подготовку к миграции до нескольких минут.

Перенос данных: синхронизация файлов и базы

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

Синхронизируйте файлы

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

rsync -avz --delete /путь/к/папке_сайта/ user@новый_хостинг:/путь/на/сервере/

Для этой команды также разберем ключи:

-a — “архивный” режим, сохраняет структуру каталогов, права и владельцев;
-v — включает подробный вывод о процессе копирования;
-z — сжимает данные при передаче, ускоряя процесс;
--delete — удаляет на новом сервере файлы, которых уже нет в источнике.

Перенесите базу данных

Следующий шаг — перенос базы данных. Если СУБД поддерживает репликацию, можно настроить синхронизацию между серверами. Подробнее о настройке можно узнать здесь. Опция настройки репликации не всегда доступна пользователю из-за отсутствия root-доступа к серверу, в этом случае лучше обратиться к провайдеру за помощью. Как альтернативный вариант, можно временно перевести сайт в режим «только для чтения» во время финальной синхронизации.

Импортируйте данные на новый сервер:

mysql -u пользователь -h хостнейм -p имя_новой_базы < backup.sql

Затем обновите настройки подключения к базе данных в конфигурационном файле сайта - например, wp-config.php для WordPress, .env для Laravel, config.php для OpenCart и т.д.

Важно! Если у вас нет root-доступа или возникают ошибки при импорте, специалисты Scalehost помогут перенести базу вручную или через временную репликацию.

Не забудьте о дубликатах и индексации

Когда сайт уже развернут на новом сервере, старую копию необходимо скрыть от поисковых систем, чтобы избежать проблем с дублированием контента. В корне старого сайта создайте или отредактируйте файл robots.txt, добавив в него:

User-agent: *
Disallow: /

Это запретит индексацию всеми поисковыми роботами.

Важно! Игнорирование этого шага может привести к тому, что поисковики начнут считать старую копию основным сайтом, а новая версия потеряет позиции.

Тестирование и подготовка к переключению DNS

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

Проведите локальное тестирование

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

IP_нового_сервера имя_вашего_домена

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

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

Важно! Обратите внимание! Некоторые модули и внешние сервисы (например, платежные системы, аналитика, API) могут быть привязаны к “старому” IP-адресу. Временно они могут не работать - это нормально. После переключения DNS всё восстановится.

Мы рекомендуем тестировать проект в изолированной staging-среде, где можно безопасно проверить работу сайта до переноса DNS-записей.

Настройте DNS для быстрого переключения

Чтобы после миграции сайт открылся с нового сервера как можно быстрее, заранее настройте DNS-записи:

Уменьшите TTL (Time to Live) — время жизни DNS-записей;
За 24−48 часов до переезда установите значение 300−600 секунд. Это позволит браузерам и провайдерам быстрее «забыть» старый IP и обновить информацию.

Проверьте A- и CNAME-записи

Убедитесь, что в панели управления доменом указаны актуальные IP-адреса и не осталось старых записей. Сохраните текущие значения. Перед изменениями сделайте экспорт DNS-зон — это поможет откатить настройки в случае ошибки.

Переключение трафика и финальная синхронизация

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

1. Синхронизируйте последние изменения

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

Команда для синхронизации:

rsync -avzhHl --progress /path/of/source/folder root@192.168.56.1:/path/to/destination/folder

Флаг --progress позволяет наблюдать процесс в реальном времени.
Если синхронизацию нужно выполнять регулярно (например, в течение периода тестирования), ее можно автоматизировать через Cron.

Создайте скрипт:

vi rsync_to_cron.sh
#!/bin/sh
RSYNC=/usr/bin/rsync
SSH=/usr/bin/ssh
KEY=/root/.ssh/id_rsa
RUSER=root
RHOST=192.168.56.1
RPATH=/remote/dir
LPATH=/local/dir
$RSYNC -az -e "$SSH -i $KEY" $RUSER@$RHOST:$RPATH $LPATH

Добавьте задачу в планировщик:

crontab -e
0 22 * * * /root/scripts/rsync_to_cron.sh

2. Финальная синхронизация базы данных

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

Создайте свежий дамп базы на старом сервере (после остановки записи):

mysqldump --single-transaction -uПОЛЬЗОВАТЕЛЬ -pПАРОЛЬ > final_dump.sql

Ключ --single-transaction сохраняет целостность данных без блокировки таблиц.

Передайте дамп на новый сервер:

rsync -avz -e ssh final_dump.sql user@new_host:/path/to/dump/

Сделайте резервную копию текущей базы на новом сервере - это точка возврата:

mysqldump -uПОЛЬЗОВАТЕЛЬ -pПАРОЛЬ > emergency_backup.sql

Импортируйте обновленный дамп:

mysql -uПОЛЬЗОВАТЕЛЬ -pПАРОЛЬ < final_dump.sql

Если в новом дампе окажется поврежденная таблица, резервная копия (emergency_backup.sql) позволит восстановить рабочую базу за считанные минуты.

3. Проверка целостности данных

После импорта выполните быструю оптимизацию и проверку базы:

mysqlcheck -uПОЛЬЗОВАТЕЛЬ -p --optimize --all-databases

Создайте тестовый заказ или заявку, чтобы убедиться, что данные корректно сохраняются, кэш обновляется (Redis/Memcached), а платежные и уведомляющие сервисы работают стабильно.

4. Обновите DNS-записи

Теперь можно направить пользователей на новый сервер:

Укажите новый IP-адрес или CNAME в панели управления доменом;
Сохраните старые значения DNS - они пригодятся для отката, если понадобится вернуть трафик обратно.

5. Мониторинг распространения DNS

После обновления DNS-записей убедитесь, что изменения распространились по глобальной сети.

Проверить можно:

через онлайн-сервисы вроде DNS Checker,
или командой в Linux: dig @DNS-server-name Hostname
в Windows с помощью утилиты NSLOOKUP, которая показывает IP-адрес и типы записей (A, NS, SOA, MX) для домена.

Процесс обновления DNS может занять от нескольких минут до 24 часов, в зависимости от TTL и провайдера.

Финализация переноса и проверка стабильности

Не спешите отключать старый сервер. Оставьте его активным минимум на 48−72 часа — это позволит быстро откатиться в случае проблем с DNS, производительностью или данными.

1. Проверка нового хостинга

Проанализируйте логи сервера и метрики — отсутствие ошибок 5xx и стабильная скорость загрузки указывают, что все прошло успешно. Убедитесь, что база данных, формы, оплата и уведомления работают без ошибок. Проверьте SSL-сертификат, кэширование и CDN.

2. Создание и проверка резервных копий

Создайте первый бэкап на новом сервере — по той же схеме, что и раньше (через mysqldump или встроенные инструменты панели).

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

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

Для дополнительной уверенности можно попросить вашего провайдера развернуть тестовую копию сайта на поддомене, например backup-test.mysite.com. Затем:

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

Если тестовая копия выдает ошибку 500, немедленно обращайтесь в поддержку.

Проверка индексации и SEO после переноса

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

1. Проверяем карту сайта

Найдите и откройте файл sitemap. xml (например, site.ru/sitemap.xml) — он покажет, какие страницы должны быть в индексе. Также можно:

Проверить sitemap через CMS (в WordPress — плагин Yoast SEO);
Использовать программы WildShark или Xenu’s Link Sleuth — они помогут собрать полный список страниц (но потребуют фильтрации неиндексируемых).

2. Контроль индексации

Используйте инструменты вроде:

Google Search Console;
Яндекс Вебмастер;
Rush Analytics.

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

3. Восстановление SEO-элементов

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

мета-описания (meta description),
заголовки (title),
alt-тексты изображений,
корректность редиректов.

4. Финальный технический аудит SEO

Чтобы сайт не потерял позиции и оставался быстрым:

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

Возможные ошибки после переноса и способы их устранения

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

1. Ошибки совместимости ПО

После переноса сайт может перестать работать из-за несовместимости версий PHP, MySQL, отсутствия модулей (например, mod_rewrite для ЧПУ) или различий в окружении.

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

Если CMS позволяет, обновите домен сайта в ее настройках. При несовпадении версии PHP настройте нужную через файл. htaccess (для Apache) или панель хостинга.

2. Повреждение или неполный перенос базы данных

Ошибки вида «Table doesn’t exist», некорректное отображение данных или пропавшие записи.

Как исправить:
Убедитесь, что экспорт через mysqldump завершился корректно (используйте флаг --single-transaction для больших баз, чтобы избежать блокировок). Проверьте кодировку — чаще всего используется UTF-8. Пример корректного экспорта:

mysqldump -uПОЛЬЗОВАТЕЛЬ -pПАРОЛЬ --default-character-set=utf8 -Q mydatabase > mydump. sql

Если после импорта база не работает, пересоздайте пользователя БД и проверьте его права доступа.

3. Некорректные настройки веб-сервера

Если сайт выдает 500 Internal Server Error, не работают редиректы или перестали открываться ЧПУ-ссылки.

Как исправить:
Сравните файлы конфигурации (.htaccess, nginx. conf) с копиями со старого сервера.
Для Apache убедитесь, что активен модуль mod_rewrite. Проверить это можно через phpinfo () — создайте PHP-файл с содержимым:

<?php phpinfo (); ?>

и откройте его в браузере.

4. Проблемы с путями и ссылками

Если на сайте пропали изображения или выводятся ошибки «File not found», значит, в коде остались абсолютные пути к старому серверу.

Как исправить:
Замените абсолютные пути (/var/www/site/images/logo.png) на относительные (/images/logo.png). Проверьте корневую директорию сайта в настройках веб-сервера. Выполните поиск по проекту — иногда старые IP-адреса или домены «зашиты» в коде или шаблонах.

5. SSL-сертификаты не работают

После переноса браузер может показать сообщение «Your connection is not private».

Как исправить:
Убедитесь, что SSL-сертификат корректно установлен и привязан к домену. Проверьте срок его действия через Qualys SSL Labs. При необходимости переустановите сертификат вручную или заново выпустите Let’s Encrypt через панель хостинга.

Финальные рекомендации: как мигрировать без стресса

Даже самый тщательно подготовленный переезд требует внимания к деталям. Убедитесь, что резервные копии созданы и проверены, новый сервер настроен и протестирован, TTL записей DNS снижен заранее, а новые записи успешно применены. Мониторинг доступности и метрик работает, проведен аудит SEO и технических настроек — все это создает основу для безопасного переноса сайта.

Миграция без простоя это результат системного подхода и аккуратной подготовки.

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

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

Мы поможем провести аудит и оптимизацию серверов, настроить CI/CD, подключить выделенного DevOps-инженера, взять на себя полное администрирование, мониторинг и стресс-тестирование, а также оптимизировать производительность и отказоустойчивость.

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

Свяжитесь с нами

FAQ

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

Для файлов сайта используется архивирование (через панель хостинга или по SSH), включая все директории CMS, пользовательские загрузки и конфигурационные файлы.

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

Забудьте о проблемах с сайтом — переходите на надежный хостинг