Как передать файлы на сервер: scp, sftp и rsync

Сервер арендован, доступ по SSH есть, а сайт лежит на ноутбуке. Задача выглядит простой, пока не выясняется, что привычного проводника на сервере нет, а FTP-клиент просит логин и пароль, которых никто не выдавал. На самом деле ничего дополнительно ставить не нужно: канал для передачи файлов уже есть, это тот же SSH.

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

Три инструмента и когда какой

scp, sftp и rsync - чем отличаются и в каком случае брать каждый.
scp, sftp и rsync - чем отличаются и в каком случае брать каждый.

Все три работают поверх SSH, отдельный сервис поднимать не нужно. Отличаются сценарием.

scp - разовая отправка. Одна команда, отправил и забыл. Идеален, когда нужно закинуть архив или забрать логи.

sftp - работа в файловом менеджере. То же соединение, но с привычным интерфейсом: две панели, перетаскивание мышью. Подходит, когда надо походить по каталогам и посмотреть, что где лежит.

rsync - синхронизация. Сравнивает источник и получателя и передаёт только разницу. Незаменим при повторяющихся выгрузках и больших объёмах.

Отдельно про FTP: его поднимать не надо. Классический FTP передаёт пароль и данные открытым текстом, и ставить его ради задачи, которую решает уже работающий SSH, смысла нет.

scp: отправить и забыть

Синтаксис повторяет обычное копирование, только у удалённой стороны указывается пользователь и адрес сервера.

Отправить файл на сервер:

scp archive.tar.gz root@203.0.113.10:/var/www/

Забрать файл с сервера к себе (обратите внимание на точку в конце - это текущий каталог):

scp root@203.0.113.10:/var/log/nginx/error.log .

Отправить каталог целиком:

scp -r ./site root@203.0.113.10:/var/www/

Если SSH работает на нестандартном порту, он указывается заглавной буквой, в отличие от привычной строчной у самого ssh:

scp -P 2222 archive.tar.gz root@203.0.113.10:/var/www/

Команда работает и в Windows: начиная с десятой версии клиент встроен в систему, отдельно ставить нечего. Как настроить само подключение и вход по ключу, разобрано в статье как подключиться к серверу по SSH.

sftp: когда удобнее мышью

Тот же протокол, но с интерфейсом. В командной строке подключение открывает интерактивную сессию:

sftp root@203.0.113.10

Внутри работают знакомые команды: ls, cd, put для отправки, get для скачивания, bye для выхода.

На практике чаще берут графический клиент: в Windows это обычно WinSCP, на macOS и Linux - Cyberduck или FileZilla, а многие редакторы кода умеют открывать удалённый каталог напрямую. Во всех случаях в настройках выбирается именно SFTP, а не FTP, и подключение идёт по тому же порту SSH.

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

rsync: только то, что изменилось

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

rsync -avz ./site/ root@203.0.113.10:/var/www/site/

Флаги: -a сохраняет права и время файлов, -v показывает, что происходит, -z сжимает данные в пути.

Слеш в конце источника важен. С ним копируется содержимое каталога, без него - сам каталог внутрь получателя. Это классическая причина появления /var/www/site/site/.

Исключить лишнее:

rsync -avz --exclude '.git' --exclude 'node_modules' ./site/ root@203.0.113.10:/var/www/site/

И самое полезное - посмотреть, что произойдёт, ничего не меняя:

rsync -avzn --delete ./site/ root@203.0.113.10:/var/www/site/

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

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

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

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

Куда класть. Сайты обычно живут в /var/www/, а домашний каталог пользователя подходит для временных файлов и архивов. В системные каталоги вроде /etc и /usr вручную копировать не нужно.

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

chown -R www-data:www-data /var/www/site

Имя пользователя зависит от системы и веб-сервера, в Debian и Ubuntu это обычно www-data.

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

Проверить, что получилось:

ls -la /var/www/site

Почему это вообще важно и чем опасна постоянная работа под root, разобрано в статье что такое root-доступ.

Большие файлы и резервные копии

Для дампов баз и архивов есть несколько приёмов, экономящих время.

  • Сжимать до отправки. Текстовые дампы сжимаются в разы, и передача идёт быстрее даже с учётом времени архивации.
  • Использовать rsync. При обрыве не придётся начинать сначала.
  • Копировать сразу в нужное место, а не в домашний каталог с последующим переносом: на маленьком диске может не хватить места под две копии.
  • Проверять свободное место до начала: df -h.

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

Частые ошибки

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

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

Запускают --delete без проверки. Режим зеркала удаляет на сервере всё, чего нет в источнике. Сначала -n, потом всерьёз.

Копируют под root и не меняют владельца. Файлы на месте, но веб-сервер их не читает, и в логах ошибка доступа.

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

Заливают вместе с проектом лишнее. Каталоги системы контроля версий и зависимости на сервере не нужны, их исключают явно.

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

Как загрузить файл на VPS? Командой scp: указать локальный файл, затем пользователя, адрес сервера и путь назначения. Отдельный сервис для этого не нужен, всё идёт через SSH.

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

Чем rsync лучше scp? Он передаёт только изменения, продолжает после обрыва и умеет исключать лишнее. Для повторяющихся выгрузок и больших объёмов разница во времени существенная.

Нужен ли FTP-сервер на VPS? Нет. SFTP работает поверх уже настроенного SSH, а классический FTP передаёт пароль и данные открытым текстом.

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

Какие права ставить на файлы сайта? Обычно 755 для каталогов и 644 для файлов. Права 777 использовать не нужно: они дают запись любому процессу в системе.

Как передавать файлы с Windows? Командой scp прямо в терминале, она встроена в систему начиная с десятой версии, либо графическим клиентом с выбором протокола SFTP.


Нужен сервер, на который можно заливать файлы? VPS на NVMe с root-доступом - SSH и SFTP работают сразу после активации, площадки в Москве, Казани и Амстердаме. Активация за 3 минуты, первые 7 дней - тестовый период с возвратом средств.