fssync - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

fssync - інструмент синхронізації файлової системи (односторонній, через SSH)

СИНТАКСИС

fssync -d db -r корінь [варіант...] господар

ОПИС

fssync — це односторонній інструмент синхронізації файлів, який відстежує inodes і підтримує локальний
база даних файлів, які знаходяться на віддаленому боці, що дозволяє:

· ефективно обробляти величезну кількість каталогів/файлів

· виявляти перейменування/переміщення та жорсткі посилання

Він спрямований на мінімізацію мережевого трафіку та синхронізацію кожної деталі файлової системи:

· усі типи inode: файл, каталог, блок/символ/fifo, сокет, символічне посилання

· зберегти жорсткі посилання

· час модифікації, володіння/дозвіл/ACL, розширені атрибути

· розріджені файли

Інші особливості:

· його можна налаштувати на виключення файлів із синхронізації

· fssync можна перервати та відновити в будь-який час, що робить його стійким до випадкових збоїв
(наприклад, помилка мережі)

· Алгоритм синхронізації вмісту файлів призначений для роботи з великими файлами, такими як зображення ВМ
ефективно, оновлюючи змінені блоки фіксованого розміру на місці

Основне використання fssync полягає в тому, щоб запобігти втраті даних у разі збою обладнання, де є RAID1
неможливо (наприклад, у ноутбуках).

On Btrfs [1] файлових систем, fssync є корисною альтернативою btrfs послати (І отримати)
команди завдяки можливостям фільтрації. Це можна поєднати з моментальним знімком Btrfs
на стороні призначення для повного резервного копіювання.

ВИКОРИСТАННЯ

Скористайтесь fssync --допомога щоб отримати повний список опцій.

Найголовніше, що потрібно пам’ятати, це те, що локальна база даних повинна точно відповідати тому, що є
на хості призначення:

· Файли, які скопійовані на цільовий хост, не можна змінювати. І нічого не повинно
створюватися вручну всередині цільових каталогів. Якщо ви все ще хочете отримати доступ до даних на
віддаленого хоста, ви повинні зробити це за допомогою монтування прив’язки лише для читання (потрібен Linux >=
2.6.26).

· Ви повинні мати 1 базу даних для кожного місця призначення, якщо ви плануєте мати кілька її копій
вихідний каталог.

Подивись на -c варіант, якщо вам цікаво, чи відповідає ваша база даних цільовому каталогу.

Перший запуск fssync:

· Найпростіший спосіб – дозволити fssync робити все. Вкажіть шлях до неіснуючого файлу -d
і порожній або неіснуючий каталог призначення (див -R варіант). fssync буде
автоматично створює базу даних і копіює всі каталоги/файли на віддалений хост.

· Швидшим способом може бути створення початкової копії іншим способом, як-от необроблена копія a
перегородка. Якщо ви абсолютно впевнені, що джерело та призначення абсолютно однакові,
Ви можете ініціалізувати базу даних, вказавши - як господар. Якщо номери inode однакові
з обох сторін, як у випадку, якщо дані були скопійовані на рівні блоку, ви можете змінити
вихідний розділ, поки ви ініціалізуєте БД на цільовому, і поверніться назад
БД локально.

Приклад обгортки навколо fssync із фільтром можна знайти за адресою examples/fssync_home

fssync ніколи не переходить до каталогів інших файлових систем. Іноди, замасковані точками монтування
також пропущені, тому їх слід тимчасово відключити, якщо ви хочете, щоб вони були
синхронізовані. Того ж результату можна досягти за допомогою синхронізації з монтування прив’язки.

Див. Також NONE шифр перемикання [2] виправте, якщо вам не потрібне шифрування і ви хочете
прискорити ваше SSH-з'єднання.

ЯК IT РОБОТИ

fssync підтримує єдину таблицю SQLite з усіма каталогами/файлами, які знаходяться на віддаленому боці. Кожен
рядок відповідає шляху з його inode (на локальній стороні), іншими метаданими (на віддаленій стороні) та
перевірено прапор

Під час виконання fssync рекурсивно перебирає всі локальні каталоги/файли та для кожного шляху
що не ігнорується (див -f опція), він запитує БД, щоб вирішити, що робити. Якщо вже
перевірено, шлях відразу пропускається. Коли шлях синхронізовано, він позначається як
перевірено. В кінці всі рядки, яких немає перевірено відповідає неіснуючим шляхам
більше. Після того, як вони будуть видалені на віддаленому боці, все перевірено прапори скидаються.

Провал терпимість
Насправді, fssync не вимагає, щоб база даних ідеально відповідала пункту призначення. Це
допускає деякі відмінності, щоб відновити будь-яку перервану синхронізацію, викликану a
збій мережі, помилка роботи з файлом або щось інше, крім збою операційної системи
локального хоста (або щось подібне, як-от збій живлення).

У більшості випадків це робиться віддаленим хостом, який автоматично створює (або перезаписує)
індекс очікуваного типу, якщо необхідно. Єдиний виняток – це дистанційний пристрій
ніколи не видаляйте непорожній каталог самостійно. Для найбільш складних випадків fssync веде журнал
операція в базі даних: у разі збою fssync зможе відновитися на наступному
синхронізація.

Гонки Умови
Умова гонки означає, що інші процеси на локальному хості змінюють іноди, які
fssync синхронізується. fssync обробляє будь-які умови гонки. Насправді, fssync має
в більшості випадків нічого робити.

Коли відбувається гонка, fssync не гарантує, що віддалені дані знаходяться в a
послідовний стан. Кожна синхронізація завжди виправляє наявні невідповідності, але може вводити
інші, тому fssync не підходить для гарячого резервного копіювання баз даних.

За допомогою Btrfs ви можете отримати узгодженість, зробивши знімки на стороні джерела.

ПОДІБНИЙ ПРОЕКТИ

Ідея підтримки локальної бази даних насправді виникла csync2 [3]. Я збирався
прийняти його, коли я зрозумів, що мені дійсно потрібен інструмент, який завжди виявляє перейменування/переміщення
великі файли. Ось чому я бачу fssync як часткове перезапис csync2 з відстеженням inode та
без двонаправленої синхронізації. Локальна база даних дійсно створює fssync і csync2
швидше, ніж відомі rsync [4].

Використовуйте fssync онлайн за допомогою служб onworks.net