Когда перенос с одного хостинга на другой превращается в лотерею: «Загрузится — не загрузится», «База подключится — не подключится», «Файлы не потеряются — потеряются»? Это не ваша вина. Это цена удобства. Графические панели управления, drag-and-drop-интерфейсы, «один клик — и готово» — всё это прекрасно, пока проект умещается в пару мегабайт и пару десятков записей в базе. Но как только сайт начинает жить по-настоящему — расти, накапливать контент, обрастать пользователями — эти же удобства становятся клеткой.
Потому что под капотом ничего не изменилось: вы по-прежнему зависите от скорости вашего интернета, от стабильности браузера, от лимитов на загрузку файлов, от таймаутов веб-интерфейсов. Вы не переносите сайт. Вы молитесь, чтобы он перенёсся сам.
Но есть иной путь. Путь, которым пользуются те, кто не хочет быть заложником абстракции. Путь, где вы говорите с серверами напрямую, без посредников, без промежуточных звеньев, без риска потери данных. Этот путь — командная строка.
Он не для «хакеров». Он для владельцев. Для тех, кто считает свой сайт не просто «страничкой в интернете», а цифровым активом, достойным честного, прозрачного и надёжного обращения.
Представьте: у вас сайт на 5 ГБ. Это не редкость — медиа, резервные копии, кэш, старые версии. Через FTP вы скачиваете это на локальный компьютер. Уходит два часа. Затем вы загружаете на новый хостинг — ещё два часа. За это время соединение может оборваться. Файл может повредиться. Антивирус может заблокировать часть данных. И вы не узнаете об этом, пока не начнёте проверять вручную.
А теперь представьте: вы подключаетесь по SSH к старому серверу, выполняете одну команду — и данные напрямую копируются на новый сервер. Без вашего участия. Без локального промежуточного звена. Без риска потери. Это не магия. Это rsync.
То же с базой данных. Вы не экспортируете SQL через phpMyAdmin, не ждёте, пока браузер не зависнет на 2-гигабайтном файле. Вы выполняете mysqldump — и получаете чистый, структурированный дамп. Затем — scp для передачи, mysql для импорта. Всё — в терминале. Всё — под контролем.
Командная строка не экономит время. Она экономит нервы, ресурсы и доверие к процессу.
Подготовка
Прежде чем вводить первую команду, убедитесь, что у вас есть:
SSH-доступ к старому и новому аккаунтам. Без этого ничего не получится. На большинстве хостингов он включается в панели управления — иногда требуется запрос в поддержку.
Логин и имя сервера для обоих аккаунтов. Обычно это выглядит как u12345 и vh229.moyhosting.ru.
Понимание путей. На хостингах с изолированными аккаунтами домашняя директория часто имеет вид /home/l/login/, где l — первая буква логина, а login — сам логин. Корневая папка сайта — обычно public_html внутри этой директории.
Это координаты, и если вы ошибётесь в одной букве — команда завершится ошибкой. И это правильно. Потому что в командной строке нет «может быть». Есть «да» или «нет».
Перенос файлов
Существует множество способов копировать файлы: scp, ftp, wget, даже tar по pipe. Но rsync — это золотой стандарт. Почему?
Потому что rsync:
- копирует только изменения при повторном запуске,
- сохраняет права, владельца, временные метки,
- работает по SSH (безопасно),
- показывает прогресс,
- устойчив к разрывам соединения.
Команда выглядит так:
rsync -avz —progress /путь/к/исходной/папке/ login@server:/путь/к/целевой/папке/
Разберём флаги:
- -a — архивный режим (сохраняет структуру, права, симлинки),
- -v — подробный вывод,
- -z — сжатие данных при передаче (экономит трафик),
- —progress — показывает ход копирования.
Обратите внимание на слэш в конце исходного пути.
/public_html/ — копирует содержимое папки.
/public_html — копирует саму папку.
Это важно. Если вы укажете без слэша, на новом сервере получите /public_html/public_html/… — и сайт не заработает.
Пример:
rsync -avz —progress public_html/ u12345@vh229.sweb.ru:/home/u/u12345/public_html/
Эта команда выполнится на старом сервере (откуда вы подключены по SSH). Она скопирует всё содержимое public_html напрямую в public_html на новом сервере.
Если соединение оборвётся — просто запустите команду снова. Rsync докопирует только то, что не успел. Никаких дублей. Никаких потерь.
Перенос базы данных: от дампа до импорта
Файлы — это полдела. Вторая половина — база данных. И здесь командная строка раскрывает всю свою мощь.
Шаг 1: Создание дампа
На старом сервере выполняем:
mysqldump -u имя_пользователя -p имя_базы > dump.sql
Система запросит пароль. После ввода — начнётся экспорт. Файл dump.sql появится в текущей директории.
Если база большая, можно сжать на лету:
mysqldump -u имя_пользователя -p имя_базы | gzip > dump.sql.gz
Это сэкономит место и ускорит передачу.
Шаг 2: Передача дампа
Теперь копируем файл на новый сервер. Используем scp:
scp dump.sql u12345@vh229.sweb.ru:/home/u/u12345/
Если файл сжат — копируем .gz.
scp работает по SSH, поэтому передача зашифрована. И, что важно, — не проходит через ваш компьютер. Данные идут напрямую между серверами.
Шаг 3: Импорт базы
Подключаемся по SSH к новому серверу. Переходим в папку с дампом.
Если файл не сжат:
mysql -u имя_нового_пользователя -p имя_новой_базы < dump.sql
Если сжат:
gunzip < dump.sql.gz | mysql -u имя_пользователя -p имя_базы
Импорт может занять время. Но вы видите процесс. Вы видите ошибки, если они есть. Вы не зависите от таймаутов веб-интерфейса.
Настройка подключения к базе
После импорта сайт ещё не заработает. Потому что конфигурационный файл (например, wp-config.php) всё ещё содержит старые данные подключения: имя базы, логин, пароль.
Их нужно заменить на новые — те, что вы создали в панели управления нового хостинга.
Вы можете отредактировать файл через nano или vim прямо в терминале:
nano public_html/wp-config.php
Найдите строки:
define(‘DB_NAME’, ‘старая_база’);
define(‘DB_USER’, ‘старый_логин’);
define(‘DB_PASSWORD’, ‘старый_пароль’);
И замените на новые значения.
Сохраните (Ctrl+O, Enter), выйдите (Ctrl+X).
Теперь сайт технически готов.
Почему это лучше графического интерфейса
Потому что вы не теряете контроль.
В панели управления вы не видите, сколько файлов скопировано. Не знаете, не прервалась ли загрузка. Не можете возобновить процесс. Вы просто ждёте — и надеетесь.
В терминале — всё иначе. Вы видите каждую строку. Каждую ошибку. Каждый переданный файл. Вы можете прервать, изменить, повторить. Вы не «нажимаете кнопку и молитесь». Вы управляете.
И ещё один момент: скорость. Передача между серверами в дата-центре происходит по внутренней сети — в разы быстрее, чем через ваш домашний интернет. Гигабайт данных может уйти за минуты, а не за часы.
Безопасность: что нужно помнить
Никогда не оставляйте дампы в публичных папках. Файл dump.sql содержит все данные сайта — пароли, email, заказы. После импорта — удалите его:
rm dump.sql
Используйте временные пароли для базы данных во время миграции, если возможно.
Проверяйте права доступа к файлам после копирования. Иногда rsync может скопировать права, несовместимые с новым окружением. В большинстве случаев достаточно:
find public_html -type f -exec chmod 644 {} \;
find public_html -type d -exec chmod 755 {} \;
Проверка и финал
После всех операций — проверьте сайт. Лучше всего через файл hosts или тестовый домен, как описано в других инструкциях. Убедитесь, что:
- страницы открываются,
- формы отправляются,
- изображения загружаются,
- админка доступна.
Только после этого меняйте DNS.
Работа с командной строкой — это ответственность, потому что когда вы переносите сайт через терминал, вы не полагаетесь на «автоматику». Вы понимаете, что делаете. Вы видите последствия каждого действия. Вы не боитесь ошибок — вы их диагностируете.
