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

Ubuntu | Amber | Комментировать запись

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

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

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 обычно используется надежный пароль. Однако 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, которая выведет ключ в терминал:

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.example.com 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 data/

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

touch 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 ранее, вы увидите следующую информацию:

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command

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

Если вы захотите получить доступ к бэкап-серверу в качестве пользователя 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@backup_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 намного быстрее и безопаснее с помощью частной сети.