Резервное копирование больших каталогов с помощью Unison в Ubuntu 18.04

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

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

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

Требования

Сервер

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

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

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

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

su - 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:

mkdir .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/unison-primary
.ssh/unison-primary.pub

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

cat .ssh/unison-primary.pub

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

nano .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 на первичном сервере:

mkdir .unison

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

nano .unison/default.prf

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

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 есть достаточно прав для чтения и записи.

Читайте также: Привилегии в Linux: что это и как с этим работать

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

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

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

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

mkdir /home/primary_user/data

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

touch /home/primary_user/data/file{1..5}

Последняя часть, file{1..5}, использует расширение Bash для создания пяти файлов. Когда оболочка bash получает {1..5}, она автоматически заполняет пропущенные числа 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 не может автоматически решить, какой вариант сохранить, а какой перезаписать.

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

При первом запуске эта команда вернет длинное сообщение:

Contacting server...
Connected [//primary_server_ip//home/primary_user/data -> //primary_server_ip//home/backup_user/data]
Looking for changes
Warning: No archive files were found for these roots, whose canonical names are:
/home/primary_user/data
//backup_server_ip//home/backup_user/data
This can happen either
because this is the first time you have synchronized these roots,
or because you have upgraded Unison to a new version with a different
archive format.
Update detection may take a while on this run if the replicas are
large.
Unison will assume that the 'last synchronized state' of both replicas
was completely empty.  This means that any files that are different
will be reported as conflicts, and any files that exist only on one
replica will be judged as new and propagated to the other replica.
If the two replicas are identical, then no changes will be reported.
If you see this message repeatedly, it may be because one of your machines
is getting its address from DHCP, which is causing its host name to change
between synchronizations.  See the documentation for the UNISONLOCALHOSTNAME
environment variable for advice on how to correct this.
Donations to the Unison project are gratefully accepted:
http://www.cis.upenn.edu/~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 синхронизируются во время этого прогона.

При каждом последующем запуске 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, введите команду:

crontab -l

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

no crontab for primary_user

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

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 – ведь для входа в систему требуется больше, чем одна команда.

Если вы захотите получить доступ к бекап-серверу в качестве пользователя backup_user, вы должны будете сначала войти в систему как пользователь 8host, а затем перейти к backup_user с помощью команды su — 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 работает, вы увидите:

Unison 2.48

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

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

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

Заключение

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

Имейте в виду:

  • Unison – не лучший выбор для обработки маленьких объемов данных. В этом случае больше подходит rsync. Подробнее об rsync вы можете прочитать в мануале Использование Rsync для синхронизации локального и удаленного каталогов на VPS.
  • Резервное копирование больших объемов данных может занять много времени и перегрузить полосу пропускания через общедоступные сетевые интерфейсы. Если вы используете виртуальные серверы, то с помощью частной сети вы сможете выполнять резервное копирование Unison намного быстрее и безопаснее.
Tags: , , , ,