Синхронизация двух директорий через ssh?

Вот пишу я какой-то код на ноуте. А запускаю на сервере. Как мне самым простым способом синхронизировать две директории — локальную и серверную?

Требования:
1)Без дополнительного софта на сервере. Я могу поставить туда synthing, но я не хочу ставить на каждый сервер, на котором хочу поработать день, ставить софтину, настраивать ее через веб-панель, придумывать ей пароль, добавлять ее в локальный конфиг synthing и так далее. Есть ssh, по которому можно передавать файлы. Есть ключ, который уже подходит к новому серверу. Зачем еще что-то?
2)Двухсторонняя синхронизация. Там у меня логи, тут у меня новые версии кода. Хочу смотреть логи в GUI на ноута, как и править код, а запускать на сервере.
3)Быстрая синхронизация. Мне ручками залить файл — пару секунд, хочу не медленнее. Локально можно по триггерам на изменение файла, удаленно — можно снизить "быстрость" до "раз в 30 секунд".
4)Просто синхронизация. Опционально с исключениями. Мне не нужны резервные копии, версионирование, синхронизация на основе гит-а, и так далее. Мне просто надо, чтобы файлы на сервере совпадали с файлами на на локальной машине.
5)Синхронизация, а не удаленный доступ. Я могу смонтировать директорию через ssh или использовать ssh-плагин для вскода, но не хочу. Я хочу отдельные копии файлов и у меня и на сервере, я не хочу зависеть от сети, канала и доступности сервера, когда я в метро достаю ноут, чтобы пофиксить баг в скрипте.
6)Синхронизация, а не системы деплоя. Мне не нужен докер, ансибл или упаковка в deb, чтобы иметь централизованное обновление. Это просто скрипт, который я запускаю на сервере, это не часть продакшена или крупного проекта. Мне пофиг, если он упадет, я увижу это в консоли, у него нет зависимостей и сложного окружения, это просто питон-скрипт в один файл у которого из требований — два pip-пакета. Он просто автоматизирует десяток моих действий в проекте. Он никому кроме меня не нужен. Он коряво написан и будет удален, как только проект кончится через месяц.
7)Linux/macos.
Мне постоянно советуют rsync, но это же просто продвинутая замена scp. Там даже для обратной синхронизации надо его запускать второй раз с другим направлением.
Пока что решение видится как "скрипт с fswatch и rsync, который по локальным изменениям триггерит аплоад-синхронизацию, а раз в 10 секунд делает тоже самое, но по направлению сервер->локальная машина". Но это же писать надо, отлаживать.. Неужели такая странная хотелка, что нет готового решения?
  • Вопрос задан
  • 138 просмотров
Пригласить эксперта
Ответы на вопрос 5
saboteur_kiev
@saboteur_kiev Куратор тега SSH
software engineer
Мне постоянно советуют rsync

Неужели такая странная хотелка, что нет готового решения?

Так тебе и советуют готовое отличное решение.

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

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

Вот пишу я какой-то код на ноуте. А запускаю на сервере. Как мне самым простым способом синхронизировать две директории — локальную и серверную?

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

В твоих требованиях противоречия.
То тебе нужно, чтоыб какие-то файлы не синкались. То есть уже нужно поддерживать список исключений и возможно настраивать его на каждом сервере.
Потом у тебя день поработать на каком-то сервере, а завтра на другом. То есть ситуация, когда у тебя 5-10 серверов и ноут будут синкаться друг с другом?
Потом ты хочешь "готовое решения", но не хочешь ставить его на каждый сервер/ноут и настраивать. Ну вот есть какой-нить unison, который синкает в обе стороны за один запуск, но его нужно будет и ставить и настраивать как и synthing, который ты не хочешь ставить или настраивать.

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

Или уж настрой тот же synthing, а настройку добавь себе в гитхаб, чтобы можно было скриптом скачать готовый сетап и все.
Ответ написан
Vindicar
@Vindicar
RTFM!
Да, странная. Обычно бэкапы делаются по расписанию, а для этих целей rsync хватает.
А твой скрипт после написания и отладки как раз и превратится в неполное подобие syncthing, nextcloud и т.п.
Ответ написан
@rPman
rsync более чем покроет все твои задачи, и он считается стандартом defacto в мире синхронизации файлов, но чтобы добавить полезной информации - у всех механизмов синхронизации на основе файлов есть легкий недостаток, информацию об изменении файла они получают из метаинформации (размер файла, флаги или даты модификации), которая не защищена от изменения, т.е. возможна ситуация, когда файл изменен но его дата нет.
spoiler
А еще есть проблема еще больше, обычно файлы копируются целиком, даже если в них были только минимальные изменения (вопрос что есть изменения - отдельный и философский), классический пример - вставка или удаление новой строки в текстовый файл, с помощью утилиты diff можно сравнить старую версию и новую версию файла, и получить diff patch, текстовый файл, содержащий только информацию об изменениях (так же построчно а не посимвольно), но для проведения этого сравнения нужно прочитать старую версию файла и новую, а так же потратить порядка n^2 памяти (в универсальном случае для binary diff), поэтому этим не пользуются именно для синхронизации файлов, а копируют файл по сети целиком (но помните об этом если у вас есть память для хранения копии старых файлов но очень медленный канал связи).

Теперь о важном - если использовать cow файловые системы типа btrfs/zfs, то можно максимально быстро (без затрат памяти и лишних чтений с диска) получить максимально эффективный патч простых бинарных изменений (без сдвигов содержимого файла) с минимальным размером куска файла - размером с кластер файловой системы (обычно 4 или 8 кб) и послать его по сети, а затем применить его на удаленную файловую систему (btrfs snapshot send), при этом это еще и максимально эффективно для медленных дисков hdd (так как утилиты пытаются обрабатывать данные последовательно а не случайно), в общем никакой другой алгоритм так эффективно синхранизацию больших объемов не сможет сделать (точнее можно, если использовать binary diff и хранить локально копии удаленных старых версий, но это очень ресурсоемко и по памяти и по процессору)
Ответ написан
Комментировать
@Drno
rsync. Я простая команда. Чего еще нало то?
Ответ написан
csync
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы