Синхронизация файлов

syncthing.
демон, двухсторонняяя синхронизация, умеет inotify - считай мгновенная синхронизация по окончании записи файла

Не эксперт, но вроде rsync подходит.

filebeat?

Если просто файлы копировать, то вызывать rsync.

Если логи забирать в реальном времени, то https://logz.io/blog/filebeat-vs-logstash/

rsync по крону запускать нужно будет

не совсем то, но интересно, спасибо

А если еще немного усложнить? хочу синхронизировать только файлы\папки, которые изменены\добавлены раньше, чем 15 минут.

так тебе по времени или нон-стопом ?? что такое «15 минут раньше» для демона который работает 24/7 последних нн-цать месяцев аптайма сервера ?? раньше чем что ??

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

сформулируй четче что тебе надобно старче

мне нужно синхронизировать файлы сайта между 2-мя серверами. Но я хочу, чтобы оно синхронизировалось с задержкой. Т.е. если на мастере удалить index.php, вместе с ним он не удалится на слейве сразу же. И будет время для реакции. rsync не пойдет - не понятно, завершился ли предыдущий. нужен какой то демон

Возьмите restic и делайте бэкапы каждые 15 минут

rsync не пойдет - не понятно, завершился ли предыдущий

Подойдет. Запускай по крону, сделай обертку на баше, где файл-локи храни, чтобы понимать, прошел предыдущий запуск или нет.

А вообще аноним выше дело говорит, возьми и сделай нормальный бекап того, что тебе надо и подготовь скрипты, чтобы очень быстро востановить то, что тебе надо. Restic для это подойдет прекрасно.

Ты просишь unison, а хочешь syncthing.

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

именно изза этого я и ушел с рсинка. как утилита однократного применения вещчъ хорошая но не более.
syncthing и resilio sync это считай тот же рсинк только с плюсами :)

Если логи забирать в реальном времени

systemd (journald) и большинство реализаций syslog умеют это делать, но нужно настраивать, делается за десять минут.

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

ну смотри - на главной сервере, например, снесли файл index.php или еще что то. слейв, перед синком файлов, чекает доступность основного сервера по коду ответа и еще по другим факторам. если код ответа не 200, то значит что то случилось с мастером, и файлы не обновляем с него и имеет еще живую копию сайта на слейве.

https://syncthing.net/

хехе, обвесить сайт предрелизными тестами это конечно хорошо и все такое. но вот использовать для откатов ошибок временной лаг отправки в продакшен это абсолютно глупо. слишком детская теория. если б в сайте была единственная точка отказа в виде index.php и единственная проблема не прое… потерять данный один единственный файлик, то жизнь б медом казалась.
сайт размером чуть более небольшого хомяка представляет собой огромную сложную взаимодействующую систему.
и лучший вариант защиты от ошибки в таком случае - бекап или версионирование всего содержимого проект. автоматический, ни в коем случае не ручной, частый, если с проектом ведется активная работа и инкрементальный если проект слишком большой.
и все остальное становится не сильно страшным, ибо всегда есть возможность откатить любую жопу.

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

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

для гигабайтных проектов и придумали инкрементальные архивы. плюс снапшоты zfs/btrfs/lvm с выгрузкой инкрементов в btrfs/zfs.
в случае с бд надо смотреть на утилиты базы или впихивать логирование действий в бекенд/субд.

но это никак не связано с выигрыванием от лагов обновления продакшена. ну не поможет тебе в баговылавливании 15 минутная задержка в обновлении, ну никак.