rsync через VPN: какая сторона — источник истины?

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

Решите, какая копия главнее, прежде чем вводить команду

Запишите направление одним предложением, включая имя хоста и путь с каждой стороны, и получите согласие того, кому принадлежат данные. В этом разборе источник — /srv/publish/, а приёмник — учётная запись на fileserver.example, которой разрешено писать только в /srv/mirror/.

Подтвердите факты о транспорте до копирования: ключ хоста SSH проверен, учётная запись приёмника может писать в область реплики и никуда больше, а оба хоста имеют совместимые версии rsync. Эти предварительные условия не дают небольшой ошибке планирования превратиться в инцидент с правами. Они также говорят, какая учётная запись появится в журналах приёмника, когда что-то пойдёт не так.

Просмотрите копию в пробном прогоне и прочитайте подробный список

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

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

Завершающая косая черта имеет значение. На стороне источника она означает содержимое этого каталога, а её отсутствие добавляет дополнительный уровень каталога с именем источника. Руководство rsync описывает обе формы вместе с флагами сохранения метаданных, и нужный набор параметров зависит от данных, а не от привычки.

Читайте каждую строку применительно к тому приёмнику, который вы задумали. Удаление флага пробного прогона выполняет копирование и может перезаписать файлы, а без параметра удаления лишние файлы, уже существующие на приёмнике, просто остаются на месте. Это безопасное поведение по умолчанию только в том случае, если вы действительно решили, что оставленные устаревшие файлы допустимы. Если ответ отрицательный, принимать нужно решение об удалении, описанное ниже, а не добавлять ещё один флаг в эту команду.

Затем решите, передаются ли удаления

Сделать приёмник зеркалом — второе решение, а не уточнение первого. Просмотрите его отдельно, добавив флаг удаления и ничего больше не меняя, чтобы разница в списке целиком относилась к этому решению.

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

Удаления убирают лишние файлы на принимающей стороне в пределах синхронизируемой области, поэтому ошибочный путь источника, неподключённый каталог или фильтр, исключающий больше задуманного, могут сделать разрушительный запуск похожим на чистое зеркало. Список пробного прогона — единственное место, где эта разница становится видна до того, как станет дорогой. Держите независимую копию для восстановления там, где данные это оправдывают, и помните, что зеркало верно воспроизводит случайное удаление вместо сохранения истории.

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

Две односторонние задачи не дают двусторонней синхронизации

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

Если пользователи должны редактировать обе копии, это другое продуктовое решение: обработка конфликтов, отслеживание удалений и инструмент, спроектированный под такую модель. Приближать его порядком расписания — так общая папка получает две версии каждого документа, которые никто не может согласовать. Решите это явно, вместо того чтобы приближать двумя записями cron и надеждой.

Автоматизируйте только после того, как политика записана

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

Когда источник — живая база данных или другой многофайловый набор данных, сначала сделайте согласованный с приложением экспорт или скоординированный снимок. Рекурсивный обход файлов не является транзакцией, а копия изменяющегося набора данных не является согласованной.

Записывайте завершения и сбои и проверяйте набор данных на приёмнике, а не только код возврата. Восстановление VPN после сбоя восстанавливает связность; оно ничего не говорит о том, завершилась ли последняя копия или были ли когда-либо разрешены конфликтующие изменения.