При миграции сайта нужно перенести тысячи файлов между серверами. Выбор инструмента влияет на скорость, безопасность и удобство — особенно при повторных синхронизациях.
Сравнение инструментов переноса
| Инструмент | Скорость | Безопасность | Инкрементальность | Требования |
|---|---|---|---|---|
| rsync | Высокая | Высокая (SSH) | Да (только изменения) | SSH на обоих серверах |
| SCP | Средняя | Высокая (SSH) | Нет | SSH на обоих серверах |
| FTP/SFTP | Средняя | Низкая/Высокая | Нет | FTP-клиент |
| tar + SSH pipe | Высокая | Высокая | Нет | tar, SSH |
rsync — лучший выбор для миграции
rsync передаёт только изменённые блоки файлов, что делает его незаменимым для финальной синхронизации перед переключением DNS:
# Синхронизировать директорию с удалённым сервером
rsync -avz --progress /var/www/example.com/ root@new-server:/var/www/example.com/
# Ключи:
# -a — архивный режим (сохраняет права, время, симлинки)
# -v — подробный вывод
# -z — сжатие при передаче
# --progress — показать прогресс
# Исключить ненужные директории
rsync -avz --exclude=".git" --exclude="node_modules" /var/www/example.com/ root@new-server:/var/www/example.com/
# Удалить на цели файлы, которых нет в источнике
rsync -avz --delete /var/www/example.com/ root@new-server:/var/www/example.com/
SCP — быстрый перенос архивов
># Скопировать файл на удалённый сервер
scp backup.tar.gz root@new-server:/tmp/
# Скопировать директорию рекурсивно
scp -r /var/www/example.com root@new-server:/var/www/
# Скопировать с удалённого сервера локально
scp root@old-server:/var/www/example.com/config.php ./
# Использовать нестандартный SSH-порт
scp -P 2222 backup.tar.gz root@new-server:/tmp/
tar + SSH pipe — перенос без промежуточных файлов
# Передать директорию напрямую без создания архива на диске
tar -czf - /var/www/example.com/ | ssh root@new-server "tar -xzf - -C /var/www/"
# Это быстрее чем: создать архив → scp → распаковать
SFTP (безопасный FTP) через lftp
># Параллельная загрузка через lftp (5 соединений)
lftp -u username,password sftp://new-server <<'EOF'
mirror -P5 /var/www/example.com /var/www/example.com
quit
EOF
- День 1: Первичная синхронизация rsync (все файлы, медленно)
- День миграции: Финальный rsync --delete (только изменения, быстро — 1–5 минут)
- Переключить DNS
SSH-ключи для автоматизации
># Создать ключевую пару (без пароля для автоматизации)
ssh-keygen -t ed25519 -C "migration-key" -f ~/.ssh/migration_key -N ""
# Добавить публичный ключ на новый сервер
ssh-copy-id -i ~/.ssh/migration_key.pub root@new-server
# Использовать конкретный ключ в rsync
rsync -avz -e "ssh -i ~/.ssh/migration_key" /var/www/example.com/ root@new-server:/var/www/example.com/
Типичные ошибки при переносе файлов
| Ошибка | Причина | Что делать |
|---|---|---|
| rsync: command not found на удалённом сервере | Пакет rsync не установлен на целевом сервере — клиента недостаточно, нужен и на сервере | Установите на обеих сторонах: apt install rsync -y |
| Permission denied (publickey) | SSH-ключ ещё не скопирован на новый сервер, либо используется не тот ключ по умолчанию | Добавьте ключ явно: ssh-copy-id -i ~/.ssh/migration_key.pub root@new-server |
| rsync error: some files/attrs were not transferred (code 23) | Не хватает прав на часть файлов, либо среди них есть битые симлинки, указывающие в никуда | Запустите с --dry-run -v, чтобы увидеть конкретные проблемные файлы перед реальным переносом |
| scp: /var/www/example.com: No such file or directory | Целевая директория на новом сервере ещё не создана | Создайте её заранее: ssh root@new-server "mkdir -p /var/www/example.com" |
Какой инструмент выбрать по сценарию
| Сценарий | Рекомендуемый инструмент |
|---|---|
| Разовый перенос одного архива | SCP |
| Регулярная синхронизация с повторными запусками | rsync |
| Перенос без промежуточного файла на диске, мало свободного места | tar + SSH pipe |
| Много мелких файлов, нужна параллельная загрузка | lftp с флагом mirror -P |
Когда ни один из этих инструментов не подходит
- Переносится база данных, а не файлы — rsync и SCP копируют файловую систему, для базы нужен mysqldump или физический бэкап СУБД
- Объём данных — десятки терабайт — прямой перенос по сети займёт дни, разумнее физическая отправка диска или прямая репликация в объектное хранилище
- Перенос между сильно разными файловыми системами (например с Windows-хостинга) — права доступа и атрибуты не переносятся один в один, нужна дополнительная нормализация
- Сайт продолжает принимать запись данных от пользователей во время переноса — нужна пауза записи или очередь синхронизации, иначе последние минуты активности потеряются
Для регулярных повторяющихся синхронизаций между серверами, а не разового переноса, есть отдельный разбор в статье «rsync: синхронизация серверов и резервное копирование». Если переносится именно WordPress, полный сценарий с базой данных описан в статье «Перенос WordPress на VDS: пошаговое руководство».
Проверка результата
После переноса убедитесь, что на обеих сторонах данные идентичны:
# Количество файлов должно совпадать на старом и новом сервере
find /var/www/example.com -type f | wc -l
ssh root@new-server "find /var/www/example.com -type f | wc -l"
# Суммарный размер директории на обеих сторонах
du -sh /var/www/example.com
ssh root@new-server "du -sh /var/www/example.com"
# Контрольная сумма ключевого файла конфигурации
md5sum /var/www/example.com/wp-config.php
ssh root@new-server "md5sum /var/www/example.com/wp-config.php"
Полный чеклист проверки сайта после переноса, включая DNS и SSL, — в статье «Чеклист проверки сайта после миграции на новый хостинг».