Unison linux односторонняя синхронизация

Обновлено: 03.07.2024

Unison – инструмент синхронизации файлов с открытым исходным кодом. Он очень эффективен при резервном копировании больших массивов данных, в которых было добавлено или обновлено всего несколько файлов. Такая ситуация возникает, например, на почтовом сервере или корпоративном файловом сервере Samba.

Большинство файлов на таких серверах остаются прежними, но каждый день появляются новые или меняются старые файлы. Unison может обнаруживать и создавать резервные копии этих новых файлов очень быстро, даже среди миллионов файлов и терабайт данных. В этих ситуациях традиционным инструментам типа rsync может потребоваться больше времени для выполнения той же операции.

В этом мануале вы научитесь устанавливать и настраивать Unison на два сервера и использовать его для резервного копирования каталога. Вы также узнаете, как настраивать Unison для поддержки SSH в качестве протокола шифрованной связи и создавать задачи cron для автоматического запуска Unison.

Требования

Два сервера Ubuntu 18.04, настроенные по этому мануалу.
Базовые навыки crontab (читайте Автоматизация задач с помощью Cron).

Серверы в этом мануале выполняют такие роли:

Первичный сервер: сервер, на котором хранятся данные, которые нужно скопировать.
Бэкап-сервер: сервер, на котором будут храниться резервные копии данных.

1: Создание дополнительного пользователя sudo

Мануал по начальной настройке сервера Ubuntu 18.04 помог вам создать одного пользователя sudo (без полномочий root) по имени 8host на первичном и на бэкап-сервере. Сейчас нужно создать еще одного такого пользователя на каждом сервере. Это упростит работу. Кроме того, на бэкап-сервере альтернативный пользователь sudo необходим, если в конце мануала вы хотите включить конфигурацию безопасности SSH.

На каждый сервер войдите по SSH как ваш пользователь sudo.

ssh 8host@primary_server_ip
ssh 8host@backup_server_ip

На первичном сервере создайте пользователя primary_user:

sudo adduser primary_user

Передайте ему права sudo:

sudo usermod -aG sudo primary_user

Теперь откройте его сессию:

Затем выполните те же действия на бэкап-сервере, но назовите пользователя backup_user. Остальные действия мануала рекомендуется выполнять в сессиях этих пользователей.

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

2: Установка Unison

Примечание: Этот раздел нужно выполнить на обоих серверах.

Вы можете использовать пакетный менеджер Ubuntu для установки Unison на оба сервера. При первом использовании apt нужно обновить локальный индекс пакетов с помощью следующей команды:

sudo apt-get update

Это позволяет установить последнюю версию Unison, а также поможет избежать ошибок при установке.

Чтобы установить Unison, введите:

sudo apt-get install unison

Установка Unison завершена. Теперь нужно настроить SSH, чтобы Unison мог обмениваться данными между двумя серверами.

3: Создание SSH-ключей и настройка SSH

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

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

Перейдите в каталог .ssh:

Запустите на первичном сервере в домашнем каталоге пользователя primary_user следующую команду, чтобы сгенерировать ключи SSH:

ssh-keygen -t rsa -b 4096 -f .ssh/unison-primary

При создании ключей SSH обычно используется надежный пароль. Однако Unison будет работать автоматически, поэтому пароль в данной ситуации будет мешать. Нажмите Enter, не вводя пароль. Это создаст пару ключей SSH без пароля.

В команде использованы такие опции:

-t rsa: тип создаваемого ключа. Ключи RSA являются наиболее совместимым типом.
-b 4096: длина ключа. Чем длиннее ключ, тем он надежнее. Рекомендуем установить длину 4096 для ключей RSA.
-f .ssh/unison-primary: имя ключа и место, где он будет сохранен. В этом случае ключ сохранится в каталоге SSH по умолчанию (.ssh), используя выбранное вами имя.

Эта команда создает открытые и закрытые ключи SSH в следующих файлах:

Первый файл – закрытый ключ SSH, а второй – открытый ключ. Вам необходимо скопировать содержимое открытого ключа на бэкап-сервер. Самый простой способ отобразить содержимое файла открытого ключа для копирования – использовать команду cat, которая выведет ключ в терминал:

На бекап-сервере в домашнем каталоге backup_user откройте файл .ssh/authorized_keys с помощью текстового редактора.

Вставьте ключ, сохраните и закройте файл.

Теперь можно проверить, работает ли конфигурация SSH, подключившись к бэкап-серверу с первичного сервера через SSH. Это важный момент, потому что вам нужно принять и сохранить отпечаток SSH-ключа бэкап-сервера, а иначе Unison не будет работать. В своем терминале на первичном сервере выполните из домашнего каталога primary_user следующую команду:

ssh -i .ssh/unison-primary backup_user@backup_server_ip

Параметр -i .ssh/unison-primary позволяет SSH использовать определенный ключ или идентификационный файл. Здесь это ключ unison-primary.

Примите отпечаток, нажав Y, а затем Enter, войдите и сразу выйдите. Сейчас нужно было просто убедиться, что серверы взаимодействуют по SSH, и сохранить отпечаток SSH бэкап-сервера. Его можно сохранить только вручную, поэтому это необходимо сделать до того, как процесс будет автоматизирован.

Теперь убедитесь, что Unison может подключаться, запустив следующую команду с первичного сервера, из домашнего каталога primary_user:

ssh -i .ssh/unison-primary backup_user@backup_server_ip unison -version

Здесь используется та же команда SSH, что и для проверки соединения, просто в конце нужно добавить команду Unison. Когда команда помещается в конце соединения SSH, SSH войдет в систему, выполнит эту команду и затем выйдет. Команда unison -version выведет номер версии Unison.

Если все работает, вы увидите в выводе версию Unison, установленную на бэкап-сервере:

unison version 2.48.3

Теперь, когда вы убедились, что Unison работает между серверами с помощью ключей SSH, можно перейти к настройке Unison.

4: Настройка Unison

Сейчас нужно настроить Unison для запуска простого одностороннего резервного копирования каталога с первичного сервера на бекап-сервер.

Чтобы настроить Unison, сначала нужно создать каталог конфигурации в домашнем каталоге primary_user на первичном сервере:

Далее нужно открыть новый файл default.prf в редакторе (в каталоге .unison). Этот файл содержит конфигурацию Unison. Откройте файл с помощью следующей команды:

Вставьте в файл:

force = /home/primary_user/data
sshargs = -i /home/primary_user/.ssh/unison-primary

Вот что делают эти строки:

force: передает изменения только с первичного сервера на бэкап-сервер. Путь /home/primary_user/data – каталог, где хранятся данные, которые нужно скопировать.
sshargs: позволяет Unison использовать сгенерированный ключ SSH.

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

5: Резервное копирование каталога с помощью Unison

Теперь можно сделать первую резервную копию каталога с помощью Unison. Резервная копия каталога /home/primary_user/data с первичного сервера будет помещена в каталог /home/backup_user/data/ на бэкап-сервере. Каталог, в котором хранятся копируемые данные – это каталог, указанный в параметре force в файле .unison/default.prf.

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

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

С помощью touch создайте 5 пустых файлов:

Последняя часть, file, использует расширение Bash для создания пяти файлов. Когда оболочка bash получает , она автоматически заполняет пропущенные числа 2, 3 и 4. Этот метод полезен для быстрого перечисления большого количества файлов.

Теперь, когда у вас есть каталог данных и несколько тестовых файлов для резервного копирования, можно запустить Unison и скопировать файлы на бэкап-сервер. Введите следующую команду:

unison -batch -auto /home/primary_user/data ssh://backup_user@backup_server_ip//home/backup_user/data

Эти параметры делают следующее:

batch: выполняет команду, не задавая пользователю вопросов.
auto: автоматически принимает любые неконфликтующие действия.

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

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

При односторонней синхронизации данные на первичном сервере всегда будут переписывать данные на бекап-сервере.

bcpierce/unison
Waiting for changes from server
Reconciling changes
dir ----> /
Propagating updates
UNISON 2.48.3 started propagating changes at 16:30:43.70 on 03 Apr 2019
[BGN] Copying from /home/primary_user/data to //backup_server_ip//home/backup_user/data
[END] Copying
UNISON 2.48.3 finished propagating changes at 16:30:43.71 on 03 Apr 2019
Saving synchronizer state
Synchronization complete at 16:30:43 (1 item transferred, 0 skipped, 0 failed)

При каждом последующем запуске Unison будет выдавать все меньше информации. Вот такой вывод появляется, когда файлы не были обновлены:

Contacting server.
Connected [//primary_server_ip//home/primary_user/data -> //backup_server_ip//home/backup_user/data] Looking for changes
Waiting for changes from server
Reconciling changes
Nothing to do: replicas have not changed since last sync.
Если на первичном сервере был обновлен /data/file1, вы увидите такой вывод:
Contacting server.
Connected [//primary_server_ip//home/primary_user/data -> //backup_server_ip//home/backup_user/data] Looking for changes
Waiting for changes from server
Reconciling changes
changed ----> file1
Propagating updates
UNISON 2.48.3 started propagating changes at 16:38:37.11 on 03 Apr 2019
[BGN] Updating file file1 from /home/primary_user/data to //backup_server_ip//home/backup_user/data
[END] Updating file file1
UNISON 2.48.3 finished propagating changes at 16:38:37.16 on 03 Apr 2019
Saving synchronizer state
Synchronization complete at 16:38:37 (1 item transferred, 0 skipped, 0 failed)

После каждого запуска синхронизации бекап-сервер будет получать точную копию каталога с первичного сервере.

Важно! При запуске Unison все новые файлы или изменения в каталоге на бекап-сервере, которые не совпадают с исходным каталогом, будут потеряны.

Теперь вы можете использовать Unison для резервного копирования каталога. Пора автоматизировать процесс резервного копирования, добавив Unison в cron.

6: Создание задачи cron для Unison

Демон cron будет запускать Unison и создавать резервную копию каталога на бекап-сервере с указанной частотой.

Crontab – это файл, который читается процессом cron. Содержащиеся там команды загружаются в cron и выполняются с заданными интервалами.

Чтобы просмотреть текущее содержимое crontab, введите команду:

Параметр -l выводит содержимое crontab текущего пользователя. Если вы не редактировали crontab ранее, вы увидите следующую информацию:

no crontab for primary_user

Затем на первичном сервере выполните команду crontab с параметром -e, чтобы открыть его в режиме редактирования:

Если у вас не настроен редактор по умолчанию для командной строки, при первом запуске команды вам будет предложено выбрать его. Выберите редактор, чтобы открыть crontab.

Как только вы откроете crontab, добавьте следующую команду в первую пустую строку под текущим текстом:

.
* */3 * * * /usr/bin/unison -log -logfile /var/log/unison.log -auto -batch -silent /home/primary_user/data ssh://backup_user@backup_server_ip//home/backup_user/data

Команда, которую нужно поместить в crontab, почти такая же, как та, которую вы использовали ранее при резервном копировании вручную, но с некоторыми дополнительными опциями. Вот эти дополнительные параметры:

-silent: отключает все выходные данные, кроме ошибок. Обычный вывод не нужен, когда Unison выполняется из crontab, так как никто не будет его читать.
-log: позволяет Unison регистрировать действия в логах.
-logfile: указывает, где Unison может регистрировать свои действия. В этом примере Unison запускается каждые 3 часа. Вы можете указать другую частоту, которая лучше соответствует вашим требованиям.

Всякий раз, когда вы редактируете crontab, вы должны добавлять пустую строку в конец файла, прежде чем сохраниться и выйти, иначе cron может некорректно загрузить файл. Это может привести к тому, что команды вообще не будут выполняться.

Сохраните и закройте файл.

На первичном сервере создайте лог для Unison:

sudo touch /var/log/unison.log

Передайте права на него пользователю primary_user.

sudo chown primary_user /var/log/unison.log

Вы можете проверить состояние резервных копий Unison, просмотрев /var/log/unison.log. Unison будет регистрировать что-либо, только если он создал резервную копию нового или обновленного файла или обнаружил ошибку.

Теперь Unison периодически выполняет резервное копирование с помощью crontab.

7: Защита SSH (опционально)

В этом мануале мы создали ключи SSH без пароля. Это проблема безопасности, которую можно устранить, ограничив возможности backup_user при входе через SSH на бекап-сервер.

Для этого нужно настроить SSH так, чтобы при входе через SSH backup_user мог выполнять только одну команду. Таким образом, созданный вами ключ SSH будет использоваться только для выполнения резервного копирования Unison и ни для чего больше. Однако после этого вы не сможете подключаться по SSH к бэкап-серверу в качестве backup_user – ведь для входа в систему требуется больше, чем одна команда.

Отредактируйте конфигурации SSH на бекап-сервере в /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Затем добавьте следующие строки в конец файла:

Match User backup_user
ForceCommand unison -server

Эти опции выполняют следующее:

Match User: когда заданный пользователь входит в систему, SSH применит опцию, которая идет ниже.
ForceCommand: ограничивает заданного пользователя следующей командой. В данном случае backup_user может выполнить только команду unison -server.

Сохраните файл и выйдите из редактора. Затем перезагрузите SSH, чтобы включить новую конфигурацию:

sudo systemctl reload ssh.service

Чтобы проверить настройку, попробуйте войти через SSH с первичного на бекап-сервер как backup_user:

$ ssh -i .ssh/unison-primary backup_user@backcup_server_ip

Если файл /etc/ssh/sshd_config работает, вы увидите:

Сеанс SSH зависнет до тех пор, пока вы не завершите его с помощью клавиш Ctrl и C, потому что Unison ожидает ввода команды.

Это значит, что при входе в систему сервер Unison был вызван автоматически и у пользователя нет никакого другого доступа, кроме связи с сервером Unison.

Теперь у вас есть безопасная система резервного копирования Unison, которая может копировать данные с необходимой частотой.

Заключение

Здесь вы научились устанавливать и настраивать систему резервного копирования и синхронизации Unison, чтобы копировать большие объемы данных по SSH. Также вы теперь умеете автоматизировать работу Unison с помощью cron и защищать беспарольную пару ключей SSH.

Поддержка и обеспечение синхронности различных директорий на нескольких машинах может быть очень трудоемким занятием. Использование Unison - один из путей для облегчения данной задачи.

Статья описывает как установить, настроить и использовать Unison - утилиты для синхронизации файлов, которая работает на Linux, UNIX и Windows.

А как у него с кириллицей в названиях файлов? Год назад смотрел - были проблемы.

You need to use the latest betas if you're going to synchronize files larger than 2GB. :))))))

а cvs уже отменили?

А причем тут versioning system и синхронизация файлов?

> а cvs уже отменили?

>а cvs уже отменили?

Причем здесь cvs, svn и rsync?
Это инструмент для синхронизации изменений в двух ФС.

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

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

>rsync - не подходит, так как не отслеживает двунаправленные изменения.

Не понял. Что значит двунаправленные изменения?

>svn - требует вмешательства пользователя при наличии конфликтной ситуации. Следовательно, тоже не годится для полностью автоматической синхронизации.

Т.е. unison вообще не разбирается с конфликтами, а просто мержит все подряд? Ну и .

А если в одном офисе файл изменили, и в во втором этот же файл изменили - какой файл останется?

Во вот это и есть конфликт. В этом случае эта хрень выкладывает версию файла.

>Во вот это и есть конфликт. В этом случае эта хрень выкладывает версию файла.

rsync такое тоже может. Делаем rsync туда-обратно с опцией --update --backup --backup-dir=. в том числе. Получаем в каталогах самые свежие версии файлов и в каталогах инкриментного backup-а файлы которые были заменены. Вроде так. Или я что-то упустил?

Еще раз. Я говорю о конкретной задаче, где эта штуклвина
применима. Одно из применений - домашний комп и комп на работе.

Второе, и, я думаю, многие здесь согласятся, это организация распределенной ФС, обновляющейся в пакетном режиме с какой-либо периодичностью.
Итак.
Берем два офиса. Или - больше.
Между ними - километры.
Там сидят отнюдь не Линусы - хакеры.
И им совершенно не объяснишь, что нужно искать модифицированную версию документа где-то в специальной папке.
ПРо удаление файла я и вообще молчу.
Итого. Нужна система, которая требует минимума внимания при автообмене.

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

>В этом случае эта хрень выкладывает версию файла.

А как она себя ведет, если юзеры изменяют файлы с версией?
Создает новые версии?
как потом разбираться с этими версиями?

Так. Хороший вопрос. Надо проверить.

>Второе, и, я думаю, многие здесь согласятся, это организация распределенной ФС, обновляющейся в пакетном режиме с какой-либо периодичностью.

У rsync с этим вроде нет проблем.

>И им совершенно не объяснишь, что нужно искать модифицированную версию документа где-то в специальной папке.

Ммм. Вы же им как-то объясили, что вот этот файл с циферкой на конце - старая версия файла? :) С каталогами точно также. Ладно, дело не в этом. Как в unison c кириллицей в именах файлов? Год назад смотрел - были проблемы.

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

Ничего не понял. Вы про unison или про Subversion? Ваши "не Линусы - хакеры" освоили Subversion?

Да нет. Я же сказал - меньше всего проблем.
А не совсем нет проблем.

Я долго пытался прикрутить subversion для офисного использования.
Для программистов это оказалось доступно.
Для стандартных пользователей - нет. Или почти нет.

Кстати, для Subversion есть замечательная приблуда для windows - explorera. Все интуитивно - понятно. Просто появляется еще один пунктик.
Удобно и объяснять не сложно. TortoiseSVN называется.
Для особо одаренных пользователей - даже на русском.

Unison – это инструмент синхронизации файлов с открытым исходным кодом. Он очень эффективен при резервном копировании больших массивов данных, в которых было добавлено или обновлено всего несколько файлов. Такая ситуация возникает, например, на почтовом сервере или корпоративном файловом сервере Samba .

Большинство файлов на таких серверах остаются прежними, но каждый день появляются новые файлы или меняются старые. Unison может обнаруживать и создавать резервные копии этих новых файлов очень быстро, даже среди миллионов файлов и терабайт данных. В этих ситуациях традиционным инструментам типа rsync может потребоваться больше времени для выполнения той же операции.

В этом мануале вы научитесь устанавливать и настраивать Unison на паре серверов и использовать его для резервного копирования каталога. Вы также узнаете, как настраивать Unison для поддержки SSH в качестве протокола шифрованной связи и создавать задачи cron для автоматического запуска Unison.

Требования

Два сервера Ubuntu 16.04, настроенные по этому мануалу.
Базовые навыки работы с crontab (читайте Автоматизация задач с помощью Cron).

Серверы в этом мануале выполняют такие роли:

Первичный сервер: сервер, на котором хранятся данные, которые нужно скопировать.
Бэкап-сервер: сервер, на котором будут храниться резервные копии данных.

1: Создание дополнительного пользователя sudo

Мануал по начальной настройке сервера Ubuntu 16.04 помог вам создать пользователя sudo (без полномочий root) по имени 8host на первичном и на бекап-сервере. Сейчас нужно создать нового пользователя на каждом сервере. Это упростит работу. Кроме того, на бэкап-сервере альтернативный пользователь sudo необходим, если в конце мануала вы хотите включить конфигурацию безопасности SSH.

На каждый сервер войдите по SSH как ваш пользователь sudo.

ssh 8host@primary_server_ip
ssh 8host@backup_server_ip

На первичном сервере создайте пользователя primary_user:

sudo adduser primary_user

Передайте ему права sudo:

sudo usermod -aG sudo primary_user

Теперь перейдите в его сессию:

Затем выполните те же действия на бэкап-сервере, но назовите нового пользователя backup_user. Остальные действия мануала рекомендуется выполнять в сессиях этих пользователей.

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

2: Установка Unison

Примечание: Этот раздел нужно выполнить на обоих серверах.

Вы можете использовать менеджер пакетов Ubuntu для установки Unison на оба сервера. При первом использовании apt нужно обновить локальный индекс пакетов с помощью следующей команды:

sudo apt-get update

Это позволяет установить последнюю версию Unison, а также поможет избежать ошибок при установке.

Чтобы установить Unison, введите:

sudo apt-get install unison

3: Создание SSH-ключей и настройка SSH

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

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

При создании пары ключей SSH обычно используется надежный пароль. Однако Unison будет работать автоматически, поэтому пароль в данной ситуации будет мешать. Нажмите Enter, не вводя пароль. Это создаст пару ключей SSH без пароля.

Запустите следующую команду на первичном сервере в домашнем каталоге пользователя primary_user, чтобы сгенерировать ключи SSH:

ssh-keygen -t rsa -b 4096 -f .ssh/unison-primary

В команде использованы такие опции:

-t rsa: задает тип создаваемого ключа. Ключи RSA являются наиболее совместимым типом.
-b 4096: устанавливает длину ключа. Чем длиннее ключ, тем он надежнее. Рекомендуем установить длину 4096 для ключей RSA.
-f .ssh/unison-primary: задает имя ключа и место, где он будет сохранен. В этом случае ключ сохранится в каталоге SSH по умолчанию (.ssh), используя выбранное вами имя.

Эта команда создает открытые и закрытые ключи SSH в следующих двух файлах:

.ssh/unison-primary
.ssh/unison-primary.pub

Первый файл – это закрытый ключ SSH, а второй – открытый ключ. Вам необходимо скопировать содержимое открытого ключа на бэкап-сервер. Самый простой способ отобразить содержимое файла открытого ключа для копирования – использовать команду cat, которая выведет ключ в терминал:

На бэкап-сервере в домашнем каталоге backup_user откройте файл .ssh/authorized_keys с помощью текстового редактора.

Вставьте ключ, сохраните и закройте файл.

Теперь вы можете проверить, работает ли конфигурация SSH, подключившись к бэкап-серверу с первичного сервера через SSH. Это важный момент, потому что вам нужно принять и сохранить отпечаток SSH-ключа бэкап-сервера, а иначе Unison не будет работать. В своем терминале на первичном сервере выполните из домашнего каталога primary_user следующую команду:

ssh -i .ssh/unison-primary backup_user@backup_server_ip

Параметр -i .ssh/unison-primary позволяет SSH использовать определенный ключ или идентификационный файл. Здесь это новый ключ unison-primary.

Примите отпечаток, нажав Y, а затем Enter, войдите и сразу выйдите. Сейчас нужно было просто подтвердить, что серверы взаимодействуют по SSH, и сохранить отпечаток SSH бэкап-сервера. Его можно сохранить только вручную, поэтому это необходимо сделать до того, как процесс будет автоматизирован.

Теперь убедитесь, что Unison может подключиться, запустив следующую команду с первичного сервера, из домашнего каталога primary_user:

Здесь используется та же команда SSH, которую вы использовали для проверки соединения, просто в конце нужно добавить команду Unison. Когда команда помещается в конце соединения SSH, SSH войдет в систему, выполнит эту команду и затем выйдет. Команда unison -version выведет номер версии Unison.

Если все работает правильно, вы увидите в выводе версию Unison, установленную на бэкап-сервере:

unison version 2.48.3

Теперь, когда вы убедились, что Unison может работать между серверами с помощью ключей SSH, можно перейти к настройке Unison.

4: Настройка Unison

Сейчас нужно настроить Unison для запуска простого одностороннего резервного копирования каталога с первичного сервера на бэкап-сервер.

Чтобы настроить Unison, сначала необходимо создать каталог конфигурации в домашнем каталоге primary_user на первичном сервере:

Далее нужно открыть новый файл default.prf в текстовом редакторе (в каталоге .unison). Этот файл содержит конфигурацию Unison. Откройте файл с помощью следующей команды:

Вставьте в файл:

force = /home/primary_user/data
sshargs = -i /home/primary_user/.ssh/unison-primary

Вот что делают эти строки:

force: передает изменения только с первичного сервера на бэкап-сервер. Путь /home/primary_user/data – это каталог, где хранятся данные, которые нужно скопировать.
sshargs: позволяет Unison использовать сгенерированный вами ключ SSH.

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

5: Резервное копирование каталога с помощью Unison

Теперь вы готовы сделать первую резервную копию каталога с помощью Unison. Резервная копия каталога /home/primary_user/data с первичного сервера будет помещена в каталог /home/backup_user/data/ на бэкап-сервере. Каталог, в котором хранятся копируемые данные – это каталог, указанный в параметре force в файле .unison/default.prf.

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

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

С помощью команды touch создайте 5 пустых файлов:

Последняя часть команды, file, использует расширение Bash для создания пяти файлов. Когда оболочка bash получает , она автоматически заполняет пропущенные числа 2, 3 и 4. Этот метод полезен для быстрого перечисления большого количества файлов.

Теперь, когда у вас есть каталог данных и несколько тестовых файлов для резервного копирования, вы можете запустить Unison и скопировать файлы на бэкап-сервер. Введите следующую команду:

unison -batch -auto /home/primary_user/data ssh://backup_user@backup_server_ip//home/backup_user/data

Эти параметры делают следующее:

batch: выполняет команду, не задавая пользователю никаких вопросов.
auto: автоматически принимает любые не конфликтующие действия.

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

Конфликт может возникнуть только в другом режиме работы Unison, который синхронизирует данные в обоих направлениях. Этот режим удобен, например, если вы обновляете файл на рабочем компьютере и хотите, чтобы это изменение было перенесено на ноутбук и наоборот. Конфликт может возникнуть, если один и тот же файл изменяется с обеих сторон до синхронизации Unison. Тогда Unison не может автоматически решить, какой вариант сохранить, а какой перезаписать.

При односторонней синхронизации данные на первичном сервере всегда будут переписывать данные на бэкап-сервере.

При каждом последующем запуске Unison будет выдавать все меньше и меньше информации. Вот такой вывод появляется, когда файлы не были обновлены:

Если на первичном сервере был обновлен файл /data/file1, вы увидите такой вывод:

Contacting server.
Connected [//primary_server_ip//home/primary_user/data -> //backup_server_ip//home/backup_user/data] Looking for changes
Waiting for changes from server
Reconciling changes
changed ----> file1
Propagating updates
UNISON 2.48.3 started propagating changes at 16:38:37.11 on 03 Apr 2019
[BGN] Updating file file1 from /home/primary_user/data to //backup_server_ip//home/backup_user/data
[END] Updating file file1
UNISON 2.48.3 finished propagating changes at 16:38:37.16 on 03 Apr 2019
Saving synchronizer state
Synchronization complete at 16:38:37 (1 item transferred, 0 skipped, 0 failed)

После каждого запуска синхронизации бэкап-сервер будет получать точную копию каталога с первичного сервере.

Важно! При запуске Unison все новые файлы или изменения в каталоге на бэкап-сервере, которые не совпадают с исходным каталогом, будут потеряны.

6: Создание задачи cron для Unison

Демон cron будет запускать Unison и создавать резервную копию каталога на бэкап-сервере с указанной частотой.

Crontab – это файл, который читается процессом cron. Содержащиеся в нем команды загружаются в cron и выполняются с заданными интервалами.

Чтобы просмотреть текущее содержимое crontab, введите:

Опция -l выводит содержимое crontab текущего пользователя. Если вы не редактировали crontab ранее, вы увидите следующую информацию:

Затем на первичном сервере выполните команду crontab с флагом -e, чтобы открыть его в режиме редактирования:

Если у вас не настроен редактор командной строки по умолчанию, при первом запуске команды вам будет предложено выбрать его. Выберите редактор, чтобы открыть crontab.

Как только вы откроете crontab, добавьте следующую команду в первую пустую строку под существующим текстом:

.
* */3 * * * /usr/bin/unison -log -logfile /var/log/unison.log -auto -batch -silent /home/primary_user/data ssh://backup_user@backup_server_ip//home/backup_user/data

Команда, которую нужно поместить в crontab, почти такая же, как та, которую вы использовали выше при резервном копировании вручную, но с некоторыми дополнительными опциями. Вот эти дополнительные параметры:

-silent: отключает все выходные данные, кроме ошибок. Обычный вывод не нужен, когда Unison выполняется из crontab, так как никто не будет читать его.
-log: позволяет Unison регистрировать свои действия в логах.
-logfile: указывает, где Unison может регистрировать свои действия.

В этом примере Unison запускается каждые 3 часа. Вы можете указать другую частоту, которая лучше соответствует вашим требованиям.

Всякий раз, когда вы редактируете crontab, вы должны помещать пустую строку в конце файла, прежде чем сохраниться и выйти, иначе cron может некорректно загрузить crontab. Это может привести к тому, что команды не будут выполняться.

Сохраните и закройте файл.

На первичном сервере создайте лог для Unison:

sudo touch /var/log/unison.log

Передайте права на него пользователю primary_user.

sudo chown primary_user /var/log/unison.log

Вы можете проверить состояние резервных копий Unison, просмотрев лог /var/log/unison.log. Unison будет регистрировать что-либо, только если он создал резервную копию нового или обновленного файла или обнаружил ошибку.

Теперь Unison периодически выполняет резервное копирование из crontab.

7: Защита SSH (опционально)

В этом мануале вы создали ключи SSH без пароля. Это проблема безопасности, которую вы можете устранить, ограничив возможности backup_user при входе через SSH на бэкап-сервер.

Для этого нужно настроить SSH так, чтобы при входе через SSH backup_user мог выполнять только одну команду. Таким образом созданный вами ключ SSH будет использоваться только для выполнения резервного копирования Unison и ни для чего больше. Однако после этого вы не сможете подключаться по SSH к бэкап-серверу в качестве backup_user – ведь для входа в систему требуется больше, чем одна команда.

Отредактируйте файл конфигурации SSH на бэкап-сервере в /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Затем добавьте следующие строки в конец файла:

Match User backup_user
ForceCommand unison -server

Эти опции делают следующее:

Match User: когда заданный пользователь входит в систему, SSH применит следующую опцию, которая идет ниже.
ForceCommand: ограничивает заданного пользователя следующей командой. В этом случае backup_user может выполнить только команду unison -server.

Сохраните файл и выйдите из текстового редактора. Затем перезагрузите SSH, чтобы включить новую конфигурацию:

sudo systemctl reload ssh.service

Чтобы проверить настройку, попробуйте войти по SSH с первичного на бэкап-сервер как backup_user:

ssh -i .ssh/unison-primary backup_user@backup_server_ip

Если файл /etc/ssh/sshd_config работает правильно, вы увидите:

Сеанс SSH зависнет до тех пор, пока вы не завершите его с помощью Ctrl и C, потому что Unison ожидает ввода команды.

Теперь у вас есть безопасная система резервного копирования Unison, которая будет копировать данные с необходимой частотой.

Заключение

Вы научились устанавливать и настраивать систему резервного копирования и синхронизации Unison, чтобы копировать большие объемы данных по SSH. Также вы умеете автоматизировать работу Unison с помощью cron и защищать беспарольную пару ключей SSH.

Я использую инструмент синхронизации Unison с моими машинами Mac OSX и Ubuntu 9.10 для резервного копирования моей музыки с Mac на Ubuntu. Дело в том, что я хочу, чтобы мой Mac был источником, а Ubuntu был целью, так что машина Ubuntu будет точной копией папки Music на Mac в любое время, но если я удалю что-то из Ubuntu, t удаляется на Mac. Я просмотрел документы, но сейчас это немного похоже на мою голову.

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

Командная строка, подобная этой, может быть полезна (если вы запустите ее из Ubuntu):

Довольно легко переключить вышеприведенную строку, если вы хотите запустить ее с вашего Mac и нажать на компьютер Ubuntu, а не натягивать.

Используйте unison -force :

Включая предпочтение -force root заставляет Unison разрешать все различия (даже не конфликтующие изменения) в пользу root. это эффективно изменяет Unison от синхронизатора в утилиту зеркалирования. Вы также можете указать -force newer (или -force older ), чтобы заставить Unison выбрать файл с более поздним (ранее) modtime. В этом случае -times также должна быть включена. Это предпочтение отменено с помощью forcepartial . это предпочтение следует использовать, только если вы уверены, что знаете, что делаете!

например. (с использованием режима сокета). Запустите unison listener в каталоге, в котором вы хотите быть зеркалом чего-то другого. Направьте этот сокет в вызов клиента unison. Сила вызывает изменения для всех ОДИН ПУТЕЙ от данного корня.

В другом месте или на том же хосте:

В то время как ответ TheToasterThatCould будет «работать», обратите внимание, что он не будет правильно резервировать файловую систему Mac «Ресурсные вилки»

В то время как версия rsync для Mac OSX является доступной для ресурса, Linux-версии rsync не являются (и, вероятно, никогда не будут, потому что версия rsync для Apple является OSX-специфичной и не представляет эти вилки ресурсов для rsync на другой конец в способе, которым может обрабатывать версия rsync, отличная от OSX). Результатом этого является то, что вилки ресурсов не будут rsync'd между Mac и Linux-машинами.

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

Если вы хотите синхронизировать вилки ресурсов, то унисон будет лучшим подходом, потому что (согласно унисонным документам) он может синхронизировать вилки ресурсов.

FreeFileSync - это приложение с открытым исходным кодом, которое способно зеркалировать каталог. Он может работать для односторонней или двухсторонней синхронизации или в режиме «Contribute». Я могу сказать, что он может выполнять работу Microsoft Synctoy. FreeFileSync можно свободно использовать в Mac OS X, Linux и Windows.

Читайте также: