Borg backup для windows

How to Install BorgBackup on Windows 11

BorgBackup is an open-source backup software that provides deduplication and compression capabilities to create efficient backups. In this tutorial, we will guide you on how to install BorgBackup on Windows 11 operating system.

Prerequisites

Before proceeding with the installation, you need to ensure that your system meets the following prerequisites:

• Windows 11 operating system
• Python 3.x or higher
• pip package installer
• Git

Step 1: Install Python

If you don’t have Python installed on your system, you can download it from the official website. Choose the latest version of Python 3.x and download the installer.

Once the download is complete, run the installer and follow the instructions to install Python on your system.

Step 2: Install pip

Pip is a package installer for Python that allows you to easily install and manage Python packages on your system. To install pip, follow the below steps:

1. Open the command prompt by pressing «Windows + R» keys and then typing «cmd» in the Run dialog box.

2. Type the following command in the command prompt to download the pip installer script:

   curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
   

3. Once the download is complete, run the following command to install pip:

   python get-pip.py
   

4. After pip is installed, you can verify the installation by running the following command:

   pip --version
   

Step 3: Install Git

Git is a version control system that is used to manage and control software development projects. To install Git, follow the below steps:

1. Download Git for Windows from the official website.

2. Run the installer and follow the instructions to install Git on your system.

Step 4: Clone BorgBackup Repository

To install BorgBackup on your system, you need to clone the BorgBackup repository from GitHub. Follow the below steps to clone the repository:

1. Open the command prompt.

2. Navigate to the directory where you want to clone the repository.

3. Type the following command to clone the repository:

   git clone https://github.com/borgbackup/borg.git
   

4. Once the repository is cloned, navigate to the «borg» directory by typing the following command:

   cd borg
   

Step 5: Install BorgBackup

To install BorgBackup, follow the below steps:

1. Run the following command to install the BorgBackup package:

   pip install .
   

2. Once the installation is complete, you can verify the installation by running the following command:

   borg --version
   

Conclusion

In this tutorial, we have shown you how to install BorgBackup on Windows 11 operating system. Now, you can use BorgBackup to create efficient backups of your data.

If you want to self-host in an easy, hands free way, need an external IP address, or simply want your data in your own hands, give IPv6.rs a try!

Alternatively, for the best virtual desktop, try Shells!

Картинка с сайта: habr.com

К нашему огромному удивлению на хабре не оказалось ни одного материала про замечательный Open Source-инструмент для резервного копирования данных ­— Borg (не путать с одноимённым прародителем Kubernetes!). Поскольку уже более года мы с удовольствием используем его в production, в этой статье я поделюсь накопленными у нас «впечатлениями» о Borg.

Предыстория: опыт с Bacula и Bareos

В 2017 году мы устали от Bacula и Bareos, которые использовали с самого начала своей деятельности (т.е. около 9 лет в production на тот момент). Почему? За время эксплуатации у нас накопилось немало недовольства:

• Зависает SD (Storage Daemon). Если у вас настроена параллельность, то обслуживание SD усложняется, а его зависание блокирует дальнейшие бэкапы по расписанию и возможность восстановления.
• Нужно генерировать конфиги и клиенту, и директору. Даже если автоматизировать это (в нашем случае в разное время применялись и Chef, и Ansible, и своя разработка), нужно мониторить, что директор после своего reload’а на самом деле подхватил конфиг. Это отслеживается только в выводе команды reload и вызове messages после (чтобы получить сам текст ошибки).
• Расписание бэкапов. Разработчики Bacula решили пойти собственным путём и написали свой формат расписаний, который не получится просто распарсить или конвертировать в другой. Вот примеры стандартных расписаний бэкапов в наших старых инсталяциях:
  • Ежедневный полный бэкап по средам и инкрементальные в остальные дни:
    Run = Level=Full Pool="Foobar-low7" wed at 18:00
Run = Level=Incremental Pool="Foobar-low7" at 18:00
  • Полный бэкап wal-файлов 2 раза в месяц и инкремент каждый час:
    Run = Level=Full FullPool=CustomerWALPool 1st fri at 01:45
Run = Level=Full FullPool=CustomerWALPool 3rd fri at 01:45
Run = Level=Incremental FullPool=CustomerWALPool IncrementalPool=CustomerWALPool on hourly
  • Сгенерированных schedule на все случаи жизни (в разные дни недели каждые 2 часа) у нас получилось примерно 1665… из-за чего Bacula/Bareos периодически сходили с ума.
• У bacula-fd (и bareos-fd) на каталогах с большим количеством данных (скажем, 40 ТБ, из которых на 35 ТБ приходятся крупные файлы [100+ Мб], а на оставшиеся 5 Тб — мелкие [от 1 Кб до 100 Мб]) начинается медленная утечка памяти, что на production ну совсем неприятная ситуация.
  

  Картинка с сайта: habr.com

• На бэкапах с большим количеством файлов Bacula и Bareos очень сильно зависят от производительности используемой СУБД. На каких она дисках? Насколько мастерски вы умеете её тюнить под эти специфичные нужды? А в базе, между прочим, создаётся одна(!) непартицируемая таблица со списком всех файлов во всех бэкапах и вторая — со списком всех путей во всех бэкапах. Если вы не готовы выделить хотя бы 8 Гб RAM под базу + 40 Гб SSD для вашего бэкап-сервера — сразу готовьтесь к тормозам.
• Зависимость от БД достойна ещё одного пункта. Bacula/Bareos на каждый файл спрашивают директора, был ли уже такой файл. Директор, конечно, лезет в БД, в те самые огромные таблицы… Получается, что резервное копирование можно заблокировать просто тем фактом, что одновременно запустились несколько тяжёлых бэкапов — даже если diff’а там на несколько мегабайт.

Картинка с сайта: habr.com

Несправедливо будет сказать, что никакие проблемы не решались совсем, но мы дошли до того состояния, когда действительно устали от различных workaround’ов, и хотели надёжного решения «здесь и сейчас».

Bacula/Bareos прекрасно работают с небольшим количеством (10-30) однородных job’ов. Сломалось какая-то мелочь раз в неделю? Ничего страшного: отдали задачу дежурному (или другому инженеру) — починили. Однако у нас есть проекты, где количество job’ов исчисляется сотнями, а количество файлов в них — сотнями тысяч. В итоге, 5 минут в неделю на починку бэкапа (не считая нескольких часов настройки до этого) начали приумножаться. Всё это привело к тому, что 2 часа в день нужно было заниматься починкой бэкапов во всех проектах, потому что буквально везде что-то по мелочи или серьёзно ломалось.

Тут кто-то может подумать, что бэкапами должен заниматься выделенный для этого специальный инженер. Непременно, он будет максимально бородат и суров, а от его взгляда бэкапы чинятся моментально, пока он спокойно попивает кофе. И эта мысль в чем-то может быть верна… Но всегда есть но. Не все могут позволить себе круглосуточно чинить и следить за бэкапами, а уж тем более — выделенного под эти цели инженера. Мы же просто уверены, что эти 2 часа в день лучше тратить на что-то более продуктивное и полезное. Поэтому перешли к поискам альтернативных решений, которые «просто работают».

Borg как новый путь

Поиски других Open Source-вариантов были размазаны во времени, поэтому сложно оценить общие затраты, но в один прекрасный момент (в прошлом году) наше внимание устремилось к «виновнику торжества» — BorgBackup (или просто Borg). Отчасти тому способствовал реальный опыт его использования одним из наших инженеров (на предыдущем месте работы).

Borg написан на Python (необходима версия >= 3.4.0), а требовательный к производительности код (сжатие, шифрование и т.п.) реализован на C/Cython. Распространяется на условиях свободной лицензии BSD (3-clause). Поддерживает множество платформ включая Linux, *BSD, macOS, а также на экспериментальном уровне Cygwin и Linux Subsystem of Windows 10. Для инсталляции BorgBackup доступны пакеты для популярных Linux-дистрибутивов и других ОС, а также исходники, устанавливаемые в том числе и через pip, — более подробную информацию об этом можно найти в документации проекта.

Чем же Borg нас так сильно подкупил? Вот его основные достоинства:

• Дедупликация: настоящая и очень эффективная (примеры будут ниже). Файлы в рамках одного Borg repository (т.е. специальном каталоге в специфичном для Borg формате) делятся на блоки по n мегабайт, а повторяющиеся блоки Borg дедуплицирует. Дедупликация происходит именно до сжатия.
• Сжатие: после дедупликации данные ещё и сжимаются. Доступны разные алгоритмы сжатия: lz4, lzma, zlib, zstd. Стандартная фича любого бэкапа, но от этого не менее полезная.
• Работа по SSH: Borg бэкапит на удалённый сервер по SSH. На стороне сервера нужен просто установленный Borg и всё! Отсюда сразу вытекают такие плюсы, как безопасность и шифрование. Вы можете настроить доступ только по ключам и, более того, выполнение Borg’ом только одной своей команды при заходе на сервер. Например, так:

  $ cat .ssh/authorized_keys
  command="/usr/bin/borg serve" ssh-rsa AAAAB3NzaC1yc…

• Поставляется как в PPA (мы преимущественно используем Ubuntu), так и статичным бинарником. Borg в виде статичного бинарника даёт возможность запускать его практически везде, где есть хоть минимально современный glibc. (Но не везде — например, не удалось запустить на CentOS 5.)
• Гибкая очистка от старых бэкапов. Можно задать как хранение n последних бэкапов, так и 2 бэкапа в час/день/неделю. В последнем случае будет оставлен последний на конец недели бэкап. Условия можно комбинировать, сделав хранение 7 ежедневных бэкапов за последние 7 дней и 4 недельных.

Переход на Borg начал осуществляться медленно, на небольших проектах. По началу это были простые скрипты в cron, которые каждый день делали своё дело. Всё так продолжалось около полугода. За это время нам приходилось много раз доставать бэкапы… и оказалось, что Borg не пришлось чинить буквально совсем! Почему? Потому что тут работает простой принцип: «Чем проще механизм, тем меньше мест, где он сломается».

Практика: как сделать бэкап с Borg?

Рассмотрим простой пример создания бэкапа:

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

   sudo wget https://github.com/borgbackup/borg/releases/download/1.1.6/borg-linux64 -O /usr/local/bin/borg
   sudo chmod +x /usr/local/bin/borg

   Примечание: Если для теста вы используете локальную машину и как источник и как приёмник, то вся разница будет только в URI, который мы передадим, но мы же помним, что бэкап нужно хранить отдельно, а не на той же машине.

2. На сервере бэкапов создаём пользователя borg:

   sudo useradd -m borg

   Просто: без групп и со стандартным shell’ом, но обязательно с домашним каталогом.

3. На клиенте генерируется SSH-ключ:

   ssh-keygen

4. На сервере пользователю borg добавляем сгенерированный ключ:

   mkdir ~borg/.ssh
   echo 'command="/usr/local/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf/XmSVWfF7PfjGlbKW00MJ63zal/E/mxm+vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU/JNU0jITLx+vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk/QmteOOclzx684t9d6BhMvFE9w9r+c76aVBIdbEyrkloiYd+vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44/Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam+9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y+IQM7fbDR' > ~borg/.ssh/authorized_keys
   chown -R borg:borg ~borg/.ssh

5. Инициализируем borg repo на сервере с клиента:

   ssh borg@172.17.0.3 hostname # просто для проверки соединения
   borg init -e none borg@172.17.0.3:MyBorgRepo

   Ключ -e служит для выбора метода шифрования репозитория (да, вы можете дополнительно зашифровать каждый репозиторий своим паролем!). В данном случае, т.к. это пример, шифрованием мы не пользуемся. MyBorgRepo — это имя каталога, в котором будет borg repo (создавать его заранее не нужно — Borg всё сделает сам).

6. Запускаем первый бэкап с помощью Borg:

   borg create --stats --list borg@172.17.0.3:MyBorgRepo::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" /etc /root

   Про ключи:

   • --stats и --list дают нам статистику по бэкапу и попавшим в него файлам;
   • borg@172.17.0.3:MyBorgRepo — тут всё понятно, это наш сервер и каталог. А что дальше за магия?..
   • ::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" — это имя архива внутри репозитория. Оно произвольно, но мы придерживаемся формата Имя_бэкапа-timestamp (timestamp в формате Python).

Что дальше? Конечно, посмотреть, что же попало в наш бэкап! Список архивов внутри репозитория:

borg@b3e51b9ed2c2:~$ borg list MyBorgRepo/
Warning: Attempting to access a previously unknown unencrypted repository!
Do you want to continue? [yN] y
MyFirstBackup-2018-08-04_16:55:53    Sat, 2018-08-04 16:55:54 [89f7b5bccfb1ed2d72c8b84b1baf477a8220955c72e7fcf0ecc6cd5a9943d78d]

Видим бэкап с timestamp’ом и как Borg спрашивает нас, действительно ли мы хотим обратиться к нешифрованному репозиторию, в котором ещё ни разу не были.

Смотрим список файлов:

borg list MyBorgRepo::MyFirstBackup-2018-08-04_16:55:53

Достаём файл из бэкапа (можно и весь каталог):

borg@b3e51b9ed2c2:~$ borg extract MyBorgRepo::MyFirstBackup-2018-08-04_16:55:53 etc/hostname
borg@b3e51b9ed2c2:~$ ll etc/hostname 
-rw-r--r-- 1 borg borg 13 Aug  4 16:27 etc/hostname

Поздравляю, ваш первый бэкап с Borg готов!

Практика: автоматизируй это [с GitLab]!

Завернув всё это в скрипты, мы настроили бэкапы вручную подобным образом примерно на 40 хостах. Поняв, что Borg действительно работает, начали переводить на него больше и более крупные проекты…

И тут мы столкнулись с тем, что есть в Bareos, но нет у Borg! А именно: WebUI или какого-то централизованного места для настройки бэкапов. И мы очень надеемся, что это временное явление, но пока нам надо было что-то решить. Погуглив готовые инструменты и собравшись в видеоконференции, мы взялись за дело. Была замечательная идея интеграции Borg с нашими внутренними сервисами, как мы делали раньше с Bacula (сама Bacula забирала список job’ов из нашего централизованного API, к которому мы имели свой интерфейс, интегрированный с другими настройками проектов). Подумали, как можно сделать, обрисовали план, как и куда это можно встроить, но… Нормальные бэкапы нужны сейчас, а на грандиозные планы времени взять неоткуда. Что делать?

Вопросы и требования стояли примерно следующим образом:

• Что использовать как централизованное управление бэкапами?
• Что умеет любой Linux-администратор?
• Что сможет понять и настроить даже менеджер, показывающий график бэкапов клиентам?
• Что каждый день выполняет по расписанию задания на вашей системе?
• Что не будет трудным в настройке и не будет ломаться?..

Ответ был очевиден: это старый добрый crond, который героически выполняет свой долг каждый день. Простой. Не зависает. Сможет поправить даже менеджер, который с Unix на «вы».

Итак, crontab, но где же всё это держать? Неужели каждый раз ходить на машину проекта и править файл руками? Конечно, нет. Мы можем положить наше расписание в Git-репозиторий и настроить GitLab Runner, который по коммиту будет обновлять его на хосте.

Примечание: Именно GitLab был выбран в качестве средства автоматизации, потому что он удобен для поставленной задачи и в нашем случае есть практически везде. Но должен заметить, что он ни в коем случае не является необходимостью.

Раскладывать crontab для бэкапов вы можете привычным для себя средством автоматизации или вообще вручную (на маленьких проектах или домашних инсталляциях).

Итак, вот что понадобится для простой автоматизации:

1. GitLab и репозиторий, в котором для начала будет два файла:

• schedule — расписание бэкапов,
• borg_backup_files.sh — простой скрипт бэкапа файлов (как в примере выше).

Пример schedule:

# WARNING! CRONTAB MANAGED FROM GITLAB CI RUNNER IN ${CI_PROJECT_URL}
# CI_COMMIT_SHA: ${CI_COMMIT_SHA}
# Branch/tag: ${CI_COMMIT_REF_NAME}
# Timestamp: ${TIMESTAMP}
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# MyRemoteHost
0 0 * * * ${CI_PROJECT_DIR}/borg_backup_files.sh 'SYSTEM /etc,/opt'

Переменные CI используются для того, чтобы проверить успешность обновления crontab’а, а CI_PROJECT_DIR — каталог, в котором окажется репозиторий после клонирования runner’ом. Последняя строка указывает на то, что бэкап выполняется каждый день в полночь.

Пример borg_backup_files.sh:

#!/bin/bash
BORG_SERVER="borg@10.100.1.1"
NAMEOFBACKUP=${1}
DIRS=${2}
REPOSITORY="${BORG_SERVER}:$(hostname)-${NAMEOFBACKUP}"

borg create --list -v --stats \
  $REPOSITORY::"files-{now:%Y-%m-%d_%H:%M:%S}" \
  $(echo $DIRS | tr ',' ' ') || \
   echo "borg create failed"

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

2. GitLab Runner, запущенный на машине, которую необходимо бэкапить, и заблокированный только на выполнение job’ов этого репозитория.

3. Сам CI-сценарий, реализуемый файлом .gitlab-ci.yml:

stages:
  - deploy
Deploy:
  stage: deploy
  script:
    - export TIMESTAMP=$(date '+%Y.%m.%d %H:%M:%S')
    - cat schedule | envsubst | crontab -
  tags:
    - borg-backup

4. SSH-ключ у пользователя gitlab-runner c доступом к серверу бэкапов (в примере это 10.100.1.1). По умолчанию он должен лежать в .ssh/id_rsa домашнего каталога пользователя (gitlab-runner).

5. Пользователь borg на том же 10.100.1.1 с доступом только к команде borg serve:

$ cat .ssh/authorized_keys
command="/usr/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAA...

Теперь при коммите в репозиторий Runner заполнит содержимое crontab’а. А при наступлении времени срабатывания cron’а выполнится бэкап каталогов /etc и /opt, который окажется на сервере бэкапов в каталоге MyHostname-SYSTEM сервера 10.100.1.1.

Картинка с сайта: habr.com

Вместо заключения: что можно ещё?

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

• Добавить универсальные скрипты для разных бэкапов, которые по окончанию выполнения запускают borg_backup_files.sh, направленный на каталог с результатом своей работы. Например, так можно бэкапить PostgreSQL (pg_basebackup), MySQL (innobackupex), GitLab (встроенный rake job, создающий архив).
• Центральный хост со schedule для бэкапа. Не настраивать же на каждом хосте GitLab Runner? Пусть он будет один на сервере бэкапов, а crontab при запуске передаёт скрипт бэкапа на машину и запускает его там. Для этого, конечно, понадобится пользователь borg на машине клиенте и ssh-agent, чтобы не раскладывать ключ к серверу бэкапов на каждой машине.
• Мониторинг. Куда же без него! Алерты о некорректно завершённом бэкапе обязательно должны быть.
• Очистка borg repository от старых архивов. Несмотря на хорошую дедупликацию, старые бэкапы всё равно приходится чистить. Для этого можно сделать вызов borg prune по окончанию работы скрипта бэкапа.
• Веб-интерфейс к расписанию. Пригодится, если правка crontab руками или в web-интерфейсе для вас выглядит не солидно/неудобно.
• Pie charts. Немного графиков для наглядного представления процента успешно выполненных бэкапов, времени их выполнения, ширины «съеденного» канала. Не зря я уже писал, что не хватает WebUI, как в Bareos…
• Простые действия, которые хотелось бы получать по кнопке: запуск бэкапа по требованию, восстановление на машину и т.п.

И в самом конце хотелось бы добавить пример эффективности дедупликации на реальном рабочем бэкапе WAL-файлов PostgreSQL в production-среде:

borg@backup ~ $ borg info PROJECT-PG-WAL
Repository ID: 177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6
Location: /mnt/borg/PROJECT-PG-WAL
Encrypted: No
Cache: /mnt/borg/.cache/borg/177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6
Security dir: /mnt/borg/.config/borg/security/177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:                6.68 TB              6.70 TB             19.74 GB

                       Unique chunks         Total chunks
Chunk index:                   11708              3230099

Это 65 дней бэкапа WAL-файлов, которые делались каждый час. При использовании Bacula/Bareos, т.е. без дедупликации, мы получили бы 6,7 Тб данных. Только подумайте: можем позволить себе хранить почти 7 терабайт данных, прошедших через PostgreSQL, всего в 20 Гб фактически занимаемого места.

P.S.

Читайте также в нашем блоге:

• «Теория и практика unattended upgrades в Ubuntu»;
• «Junior, который в первый день работы удалил базу данных с production»;
• «Ускоряем bootstrap больших баз данных с помощью Kubernetes».

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

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

Почему именно Borg Backup? Во многом выбор системы резервного копирования определяется личными предпочтениями, благо выбирать есть из чего, но каждый из нас имеет собственные критерии, которым такая система должна удовлетворять. Поэтому коротко изложим наши предпочтения, которые привели к такому выбору.

Начнем с того, что Borg прост, несмотря на то что это клиент-серверная система, всего лишь один пакет или один бинарные. Тем не менее он может быть как клиентом, так и сервером, при этом превратить клиент в сервер абсолютно не сложно, а на сервере и вовсе ничего делать не нужно. Такая универсальность — очень большой плюс.

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

Клиент-серверная архитектура позволяет реализовать инкрементное копирование, т.е. реально по каналам связи будут передаваться только изменения, что позволяет существенно сократить время резервного копирования и объем передаваемых данных, вторым фактором здесь выступает эффективное сжатие, начиная с версии 1.1.4 Borg поддерживает алгоритм Zstandard.

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

И последний плюс — Borg присутствует в репозиториях большинства актуальных Linux дистрибутивов.

Установка сервера Borg Backup

Мы будем выполнять установку в среде Debian / Ubuntu, если вы используете другие дистрибутивы — обратитесь к справке по своему пакетному менеджеру. Все указанные ниже команды, если не оговорено отдельно следует выполнять с правами суперпользователя.

Прежде всего обновим список пакетов и выполним установку:

apt update
apt install borgbackup

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

Самый простой способ создать пользователя со стандартным размещением домашнего каталога в /home выполните:

useradd -m borg

Если вы хотите создать домашний каталог в другом расположении, скажем на дополнительном массиве, который смонтирован в /storage1, то команда должна выглядеть так:

useradd -m -b /storage1 borg

В этом случае будет создана домашняя директория /storage1/borg.

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

usermod -dm /storage2/borg borg

В нашем примере новой домашней директорией станет /storage2/borg, куда будет скопировано все ее содержимое, обратите внимание, что на момент выполнения команды директория уже должна существовать.

Для аутентификации удаленных клиентов мы будем использовать SSH-ключи, поэтому сразу создадим нужную структуру папок и файлов и назначим им владельца:

mkdir ~borg/.ssh
touch ~borg/.ssh/authorized_keys
chown -R borg:borg ~borg/.ssh

На этом настройка сервера закончена, он готов к работе.

Установка и использование клиента Borg Backup

Установка клиента ничем не отличается от сервера, и одна и та же инсталляция может быть и сервером, и клиентом одновременно:

apt update
apt install borgbackup

Для доступа к серверу необходимо сгенерировать SSH-ключ, так как регламентные задания выполняются от имени суперпользователя, то ключи должны быть созданы именно для него. Поэтому повысим себе права до root, в Debain, если вы не включали sudo, выполните:

su -

В Ubuntu:

sudo -s

В первом случае вам потребуется ввести пароль суперпользователя, во втором — текущего пользователя.

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

ssh-keygen

После чего у вас в директории /root/.ssh появятся файлы открытого и закрытого ключей: id_rsa.pub и id_rsa. Файл закрытого ключа id_rsa является секретным и в случае его компрометации или утери ключевую пару потребуется незамедлительно пересоздать.

Внимание! Перед выполнением этой команды убедитесь, что ключевая пара не была создана ранее! Если в директории /root/.ssh уже присутствуют файлы id_rsa и id_rsa.pub, то следует использовать их и новую ключевую пару создавать не нужно!

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

Картинка с сайта: interface31.ru

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

echo 'command="/usr/bin/borg serve" ssh-rsa public_key' >> ~borg/.ssh/authorized_keys

Где public_key — содержимое вашего открытого ключа (то, что выделено желтым на скриншоте выше). Данная запись указывает, что при логине владельца открытого ключа запускать для него серверный процесс Borg, интерактивный вход в консоль для него невозможен.

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

echo 'command="/usr/bin/borg serve --restrict-to-path ~borg/my_repo",restrict ssh-rsa public_key' >> ~borg/.ssh/authorized_keys

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

Вернемся на клиент и создадим новый репозиторий, для примера в качестве публичного IP-адреса сервера резервного копирования будем использовать 203.0.113.112:

borg init -e none borg@203.0.113.112:my_repo

В данном случае мы не используем шифрование, поэтому указываем опцию -e как none. Если вы все сделали правильно, то команда выполнится без ошибок, а на сервере в домашней директории Borg будет создан каталог с именем репозитория.

Теперь попробуем выполнить резервное копирование, например, мы хотим сделать копию сайта example.com:

borg create -C zstd borg@203.0.113.112:my_repo::example-`date +%Y%m%d_%H%M%S` /var/www/example.com

Ключ -С указывает на используемый алгоритм сжатия, наш выбор — быстрый и эффективный Zstandard. После указания сервера через двоеточие указывается имя репозитория — my_repo, а через два двоеточия от него — имя бекапа, запомните этот синтаксис. Конструкция example-`date +%Y%m%d_%H%M%S` позволяет добавить к имени архива текущие дату-время в указанном формате. Т.е. полное имя архива будет example-20220128-171235. Если вы хотите видеть ход и результат выполнения команды — добавьте к ней ключ —list.

Список архивов, хранящихся в репозитории, можно получить командой:

borg list borg@203.0.113.112:my_repo

Картинка с сайта: interface31.ru

Для получения информации о репозитории выполните:

borg info borg@203.0.113.112:my_repo

Картинка с сайта: interface31.ru

Информации немного, но вполне достаточно, чтобы оценить эффективность хранения копий.

Аналогичную информацию можно получить и по отдельному архиву, например, команда:

 borg list borg@203.0.113.112:my_repo::example-20220128-171235

покажет все содержимое архива, если количество хранимых файлов велико, то сразу советуем использовать эту команду в связке с less или more.

Статистику по архиву можно получить следующим образом:

 borg info borg@203.0.113.112:my_repo::example-20220128-171235

Картинка с сайта: interface31.ru

Здесь цифры уже интереснее. Во-первых, обратите внимание на время работы задания. Всего за 7 с небольшим секунд Borg проанализировал почти 52 тысячи файлов, общим размеров в 1,25 ГБ, нашел 64 кБ разницы с предыдущим бекапом и отправил ее на сервер. При этом мы всегда можем получить полный бекап на эту дату, Borg достанет дедуплицированные данные, добавит измененные и выдаст нам полный набор информации. Это гораздо удобнее, чем самостоятельно восстанавливать данные из инкрементальных или дифференциальных архивов.

Borg прост, поэтому он сам не выполняет никаких действий, кроме тех, о которых его попросит пользователь. Но созданные архивы нужно время от времени проверять. Мы можем проверить как отдельный архив, так и весь репозиторий целиком:

borg check -v borg@203.0.113.112:my_repo::example-20220128-171235

или

borg check -v borg@203.0.113.112:my_repo

Картинка с сайта: interface31.ru

Еще одной важной задачей резервного копирования является очистка хранилища от старых копий. И хотя дедупликация позволяет нам иметь хорошую глубину резервного копирования, злоупотреблять этим тоже не стоит, да и ценность резервных копии с прошествуем времени только падает. Borg Backup позволяет гибко задавать условия очистки, например, мы можем использовать следующие ключи:

• —keep-within INTERVAL — хранить все архивы за указанный промежуток времени, для его указания используйте «H», «d», «w», «m», «y» для указания часов, дней, недель, месяцев и лет.
• —keep-last, —keep-secondly — хранить указанное количество последних копий.
• —keep-minutely — количество копий в течении последнего часа.
• -H, —keep-hourly — количество последних часовых копий.
• -d, —keep-daily — количество последних дневных копий.
• -w, —keep-weekly — количество последних недельных копий.
• -m, —keep-monthly — количество последних месячных копий.
• -y, —keep-yearly — количество последних годовых копий.

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

Для выполнения очистки используйте следующую команду, вы также можете дополнить ее ключами —list для вывода информации на экран и —dry-run, для оценки результата без реального выполнения команды:

borg prune --list --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --dry-run borg@203.0.113.112:my_repo

Указанная команда выполнит тестирование и покажет предполагаемый результат для следующих условий: храним копии за последний 14 дней, 8 недель и 12 месяцев. При этом каждый последующий период начинает отсчитываться от последнего архива, попадающего под предыдущее условие. Т.е. 8 недель начнут отсчитываться через 14 дней, а 12 месяцев только после 8 недель. Условия применяются в том порядке, в котором они перечислены выше.

Картинка с сайта: interface31.ru

Готовых рекомендаций по схеме хранения мы давать не будем, все это очень индивидуально и зависит от многих факторов. В общем — исходите из собственных потребностей и доступных объемов хранилища, но не забывайте про здравый смысл. Копии многолетней давности вряд-ли пригодятся вам в каком-либо ином качестве, нежели архив, информация из которого может быть использована как срез на определенный момент времени, для оперативного восстановления она вряд-ли пригодится.

Но, будьте внимательны, Borg не анализирует архивы и если вы делаете в один репозиторий разные копии, то храниться будет только самая последняя, чтобы этого избежать используйте префикс имени архива. Допустим вы создаете архивы с именами example- и wordpress-, в этом случае для очистки от старых копий вам потребуется запускать две команды:

borg prune --prefix example --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --dry-run borg@203.0.113.112:my_repo
borg prune --prefix wordpress --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --dry-run borg@203.0.113.112:my_repo

Потому наш совет: всегда используйте сначала тестовый запуск с —dry-run, в этом случае вы сразу увидите если что пошло не так и сможете принять меры, не рискуя уже существующими архивами.

Автоматизируем создание резервных копий при помощи cron

Основные команды мы освоили, самое время автоматизировать процесс. Начнем с классики — скриптов, для этого создадим пустой файл:

touch /etc/borg-backup.sh

Откроем его и внесем следующее содержимое:

#!/bin/sh
borg create -C zstd borg@203.0.113.112:my_repo::example-`date +%Y%m%d_%H%M%S` /var/www/example.com
borg prune --keep-daily 14 --keep-weekly 8 --keep-monthly 12 borg@203.0.113.112:my_repo

Это самый простой вариант, все тоже самое, что мы делали интерактивно, в реальных сценариях скрипты могут быть сложнее. Например, создание резервной копии SQL-базы сайта:

#!/bin/shmysqldump --add-drop-table --allow-keywords -q -c -u mysqluser -pmysqlpassword example > /backup/example.sql
borg create -C zstd borg@203.0.113.112:my_repo::example-sql-'date +%Y%m%d_%H%M%SI example.sql
borg prune --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prefix example-sql --list borg@203.0.113.112:my_repo
rm -rf /backup/example.sql

Первой командой мы выгружаем дамп SQL-базы, для этого указываем имя базы — example, пользователя MySQL и его пароль — mysqluser и mysqlpassword, обратите внимание, что пароль пишется после ключа без пробела. После чего бекапим дамп, выполняем очистку. Последней командой удаляем созданный дамп на локальной машине.

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

chmod +x /etc/borg-backup.sh

Теперь можно проверить его работу, запустив интерактивно, если все отработало как надо — то добавим его в планировщик.

Традиционно для этого используют cron, для этого откройте файл /etc/crontab и добавьте туда запись:

45 0 * * * root /etc/borg-backup.sh

Указанная запись будет запускать наш скрипт каждый день в 00:45 от учетной записи root. Более подробно об использовании cron вы можете прочитать в нашей статье: Cron — точно по расписанию.

Автоматизируем создание резервных копий при помощи таймеров systemd

Современные системы построены с использованием systemd, который предлагает использовать вместо cron гораздо более удобный и функциональный инструмент — таймеры.

Для этого нам потребуется создать два файла: юнит службы и юнит таймера, главное условие — они должны называться одинаково.

touch /etc/systemd/system/borg-backup.service
touch /etc/systemd/system/borg-backup.timer

Самый простой способ — использовать скрипт, созданный нами на предыдущем этапе. Для этого откроем /etc/systemd/system/borg-backup.service и внесем в него следующее содержимое:

[Unit]
Description=Automated Borg Backup
After=network.target
[Service]
Type=oneshot
ExecStart=/etc/borg-backup.sh
[Install]
WantedBy=multi-user.target

Но если ваш скрипт прост, то можно все команды перенести в юнит службы, чтобы не плодить лишние сущности:

[Unit]
Description=Automated Borg Backup
After=network.target
[Service]
Type=oneshot
ExecStart=/bin/bash -c "borg create -C zstd borg@203.0.113.112:my_repo::example-$(date +%%Y%%m%%d_%%H%%M%%S) /var/www/example.com"
ExecStart=borg prune --keep-daily 14 --keep-weekly 8 --keep-monthly 12 borg@203.0.113.112:my_repo
[Install]
WantedBy=multi-user.target

Для служб с типом запуска oneshot мы можем указать несколько действий ExecStart и они будут исполнены последовательно. Также обратите внимание, что первое действие мы выполняем как команду bash, почему? Потому что функция date — это функция командного интерпретатора bash и в ином случае она не отработает.

В файл таймера /etc/systemd/system/borg-backup.timer добавим:

[Unit]
Description=Automated Borg Backup Timer[Timer]
OnCalendar=*-*-* 00:35[Install]
WantedBy=timers.target

Данный таймер настроен на срабатывание в 00:35 каждого дня, подробнее об использовании таймеров читайте в нашей статье: Настраиваем таймеры systemd вместо заданий cron.

После того, как вы внесли изменения в файлы юнитов выполните:

systemctl daemon-reload

Теперь можно попробовать запустить юнит службы:

systemctl start borg-backup

Результат его выполнения можно посмотреть командой:

systemctl status borg-backup

Если все выполнилось нормально, то активируем таймер и включаем его в автозагрузку:

systemctl start borg-backup.timer
systemctl enable borg-backup.timer

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

Warning: Attempting to access a previously unknown unencrypted repository!

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

export BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=yes

Для юнита службы systemd добавим в секцию [Service]:

Environment="BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=yes"

После чего запустим скрипт или юнит еще раз, ошибка должна уйти.

Восстановление данных при помощи Borg Backup

Конечно, хорошо, если этот пункт вам никогда не пригодится, но восстанавливать данные все такие бывает нужно. Borg Backup предлагает нам несколько вариантов восстановления. Начнем с простого. Можно просто получить содержимое копии в текущую папку, теоретически можно даже сразу извлечь данные в место назначения, но мы не советуем так делать. Лучше всего восстановить копию в отдельную директорию, а потом уже скопировать данные. Создадим новую папку в домашней директории и перейдем в нее:

mkdir ~/restore
cd ~/restore

Теперь извлечем в нее содержимое нужного архива:

borg extract borg@203.0.113.112:my_repo::example-20220128-171235

Также можно извлечь только часть архива или отдельный файл, например, следующая команда извлечет из резервной копии только папку upload:

borg extract borg@203.0.113.112:my_repo::example-20220128-171235 var/www/example.com/upload

Обратите внимание на указание пути, он должен соответствовать пути к нужному элементу копии в архиве, уточнить их всегда можно командой list:

borg list borg@203.0.113.112:my_repo::example-20220128-171235

Альтернативной извлечению содержимого архива может быть его монтирование, Borg позволяет смонтировать архив в любое место файловой системы и работать с ним как с обычной папкой:

borg mount borg@203.0.113.112:my_repo::example-20220128-171235 ~/restore

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

Закончив работу не забудьте отмонтировать указанную резервную копию.

borg umount ~/restore

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

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