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 після збою відновлює зв'язність; воно нічого не каже про те, чи завершилася остання копія або чи були колись вирішені конфліктні зміни.