Быстрый и простой перенос Borg Backup на другой сервер

Резервное копирование - это важная часть работы любого системного администратора. Не так давно мы рассказывали как установить простой и эффективный сервер резервного копирования Borg Backup. Сегодня мы рассмотрим иную ситуацию - как быть, если его нужно перенести на другой сервер. Причины для этого могут быть разные, но чаще всего это выход за аппаратные возможности конфигурации оборудования, без возможности ее изменения (так обычно бывает на VPS), либо иные причины, вызванные внешними факторами.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Как мы уже говорили, Borg Backup прост - это всего лишь один бинарный файл и файловая структура репозитория. Благодаря этому управление и миграция сервера резервного копирования может быть выполнена очень быстро и просто, основное время у вас займет копирование данных. Не будем терять времени и приступим к настройкам.

Подготовка нового сервера

В качестве сервера может выступать любой компьютер или виртуальная машина с ОС семейства Linux, мы будем традиционно использовать Debian / Ubuntu, но данная инструкция подойдет и для других систем с поправками на работу с пакетным менеджером.

Прежде всего повысим права до суперпользователя, в Ubuntu выполните:

sudo -s

В Debian по умолчанию sudo не установлен, поэтому используйте:

su -

Обратите внимание, что в первом случае вы должны ввести пароль текущего пользователя, во втором - пароль суперпользователя root.

Обновим список пакетов и установим Borg Backup:

apt update
apt install borgbackup

И создадим пользователя borg с домашней директорией в стандартном расположении:

useradd -m borg

При необходимости расположение домашней директории можно изменить:

useradd -m -b /storage1 borg

Где /storage1 - место размещения домашней директории пользователя.

Теперь создадим SSH-ключ для суперпользователя, от установки пароля на закрытый ключ следует отказаться.

ssh-keygen

Получим содержимое открытого ключа командой:

cat /root/.ssh/id_rsa.pub

Он не является секретным и может быть передан по открытым каналам связи. Скопируйте ту его часть, которая выделена на скриншоте желтым цветом.

Теперь перейдите на старый сервер и выполните команду:

echo 'ssh-rsa public_key' >> ~borg/.ssh/authorized_keys

Где вместо public_key вставьте скопированное содержимое открытого ключа.

Перенос данных со старого сервера на новый

Снова вернемся на новый сервер, наша задача - скопировать всю домашнюю директорию borg со старого сервера. Это можно сделать разными способами, мы будем использовать утилиту scp, которая позволяет безопасно передавать файлы по защищенному SSH-соединению.

scp -r borg@203.0.113.112:~borg/* ~borg

Где 203.0.113.112 - условный адрес старого сервера. Обратите внимание, что мы используем относительные пути к домашней директории ~borg, что делает команду универсальной, вне зависимости от реального расположения домашней директории в файловой системе.

Это самая длительная операция и, в зависимости от объема данных, может занять продолжительное время.

После ее окончания восстановим владельца полученных файлов:

chown -R borg:borg ~borg

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

Изменяем настройки клиента Borg Backup

Теоретически на клиентах достаточно просто изменить адрес сервера со старого на новый, если вы используете обращение по IP-адресу. При использовании FQDN ничего менять не надо, но потребуется изменить A-запись для доменного имени, там есть свои особенности, мы коснемся их позже. Кроме того, есть некоторые неочевидные моменты, которые нужно обязательно учесть, чтобы не получить неприятных сюрпризов.

Начнем с IP-адресов. Для автоматизации резервного копирования можно использовать как скрипты, так и юниты systemd, которые содержат необходимые команды, включающие в себя адрес старого сервера, который нужно замнить на новый. Можно, конечно, выполнить замену руками, но это не наш способ, тем более что Linux позволяет просто и эффективно решать такие задачи.

Выполним для каждого файла скрипта или юнита:

sed -i "s/203.0.113.112/198.51.100.100/g" /etc/borg-backup.sh

Где 203.0.113.112 - адрес старого сервера, 198.51.100.100 - адрес нового, /etc/borg-backup.sh - путь к фалу скрипта или юниту, напомним, что юниты располагаются в директории /etc/systemd/system.

Затем следует выполнить сеанс работы с новым сервером интерактивно, т.е. вручную. Зачем? Сейчас поясним. Для начала можно выполнить команду list или info:

borg list borg@198.51.100.100:my_repo

Если это первое подключение к данному узлу, то вы получите стандартное SSH-предупреждение:

The authenticity of host '198.51.100.100 (198.51.100.100)' can't be established.
ECDSA key fingerprint is SHA256:EqczFABn+qRymyXdd+NOroXiGfv5ewlBa6LfNx^yuoo.
Are you sure you want to continue connecting (yes/no)?

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

Сразу после этого вы получите еще одно предупреждение, теперь уже от Borg Backup:

Warning: The repository at location ssh://borg@198.51.100.100/./my_repo was previously located at ssh://borg@203.0.113.112/./my_repo
Do you want to continue? [yN]

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

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

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

Особенности использования FQDN в качестве адреса репозитория

По большому счету использование IP-адресов - дурной тон, их тяжело запоминать, они могут меняться и т.д. и т.п. Более правильно и удобно использовать для этой цели доменные имена (FQDN), скажем borg.example.com - и выглядит лучше, и запомнить проще и скрипты не нужно менять. Казалось бы, сплошные плюсы. Но, как и любой инструмент, FQDN имеет и свои обратные стороны, которые нужно знать и учитывать.

В частности нужно понимать, как работает система DNS и каким образом происходит обновление информации в ней. Если коротко - то вся информация о домене хранится на обслуживающем его сервере имен, а остальные сервера получают информацию от него посредством рекурсивных запросов. Так как рекурсивные запросы вызывают большую нагрузку сервера кешируют результат на время, указанное в параметре TTL домена. Однако данный параметр не является догмой и сервера могут его игнорировать, устанавливая собственное время кеширования (этим обычно грешат небольшие провайдеры и корпоративные сети).

Таким образом, после того как вы изменили IP-адрес в записи доменного имени до его полного распространения в системе DNS может пройти время не менее указанного в TTL, а иногда и более. Поэтому может сложиться неоднозначная ситуация, когда одни ваши клиенты получают уже новый адрес сервера, а другие старый. Что делать?

Для начала - подготовиться. По умолчанию для TTL устанавливаются достаточно большие значения, так как данные меняются редко и не следует увеличивать нагрузку на сервера имен, обычно это 14400 или 21600 секунд (4 или 6 часов), поэтому перед переносом сервера есть смысл уменьшить эти значения, скажем до 600 или 900 сек. Сделать это нужно не позднее чем за промежуток равный двум старым значениям TTL. Это заставит другие сервера чаще обновлять данные о вашем домене и уменьшит время необходимое на обновление информации.

Но данный процесс находится вне рамок нашего контроля и повлиять на него мы никак не можем. Что можно сделать еще? Если вы делаете копии достаточно редко, то сделайте их вручную, выключите регламентное задание и измените A-записи. После того, как все клиенты будут разрешать имя домена в правильный IP-адрес снова включите копирование по расписанию.

Если же нужно работать здесь и сейчас, то новый адрес можно временно добавить на DNS-сервер предприятия или роутера, в крайнем случае добавить в файл /etc/hosts запись вида:

198.51.100.100 borg.example.com

В большинстве случаев DNS-сервера следуют указанным для домена TTL и обновление информации произойдет быстро. После чего мы советуем снова увеличить значение TTL до нескольких часов, а также удалить статические записи с локального DNS, роутера и файлов hosts.

Записки IT специалиста