The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Раздел полезных советов: Резервное копирование с Borg"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Резервное копирование с Borg"  +/
Сообщение от auto_tips (ok), 11-Апр-21, 17:43 
Borg решает задачи хранения, передачи, очистки, сжатия, шифрования, дедупликации и защиты резервных копий, а также разграничивает доступ к различным репозиториям с резервными копиями. В этой статье мы рассмотрим использование инструмента borgbackup для упрощения построения системы резервного копирования. Единственный аспект, который я опущу в этой статье — шифрование. Если для вас принципиально шифровать свои бекапы, то в этом нет никакой проблемы — в официальной документации описано как использовать шифрование и вы легко сможете использовать шифрование с предложенными мной решениями.

Также borg не занимается подготовкой данных для резервирования и  их восстановлением. На входе и выходе вы получаете только файлы, а что и как с ними делать — решать вам. Если скомандуете "положи в бекап каталог с файлами баз mysql", то borg это сделает, но на выходе вы получите кашу вместо данных. Консистентность — это ваша задача и её обсуждение выходит за рамки этой статьи. Для решения этой задачи используется множество инструментов, зависящих от службы, данные которой вы собираетесь копировать — будь то mysqldump, снапшоты lvm, zfs или виртуальных машин.

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

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


++ Установка

В большинстве дистрибутивов уже есть пакет borgbackup и  можно просто установить этот пакет.

Для CentOS

   sudo yum install borgbackup

Для Debian/Ubuntu

   sudo apt install borgbackup

Или можно скачать исполняемый файл и установить его в систему. Скачиваем его со этой [[https://github.com/borgbackup/borg/releases страницы]] и выполняем

   sudo cp borg-linux64 /usr/local/bin/borg
   sudo chown root:root /usr/local/bin/borg
   sudo chmod 755 /usr/local/bin/borg

[[https://borgbackup.readthedocs.io/en/stable/installation.html Подробнее]] об установке на другие дистрибутивы

Borg необходимо установить как на сервере так и на клиентах.

++ Настройка сервера. Часть 1

Подготовив пространство для хранения бекапов, создадим пользователя с домашним каталогом в этом пространстве. В моё случае это пользователь borg с домашним каталогом /backup/borg

   adduser --home /backup/borg --disabled-password borg

Доступ к пользователю borg сделаем только по ключам, поэтому вход с пустым паролем по ssh должен быть отключён. Во всех известных мне дистрибутивах это сделано по умолчанию.

Поправим две опции в конфиге ssh-сервера /etc/ssh/sshd_config

   ClientAliveInterval 10
   ClientAliveCountMax 30

Перезапустим ssh-сервер

   sudo systemctl restart sshd

Зайдем в сеанс пользователя borg

   sudo -i -u borg

Подготовим ssh

   mkdir .ssh
   touch .ssh/authorized_keys
   chmod 700 .ssh
   chmod 600 .ssh/authorized_keys

Теперь создадим репозиторий

   borg init -e none MyRepo

В домашнем каталоге появится каталог репозитория MyRepo. На этом первоначальная настройка сервера закончена.

В качестве имени сервера будем использовать backup.foo.

++ Настройка клиента

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

   ssh-keygen

Теперь нужно настроить отправку файлов бекапа на сервер. Как уже говорилось выше, borg занимается только хранением файлов — их подготовка ваша задача. Создадим скрипт /usr/local/bin/backup.sh, который будет готовить данные и отправлять их в бекап.

   #!/bin/bash
  
   ####
   #Готовим данные и копируем их в каталог /var/backup
   #Если данные не нуждаются в подготовке, то этот этап пропускаем
   #и вместо /var/backup указываем каталог с данными
   ####
  
   borg create -C lz4 borg@backup.foo:MyRepo::`date +%Y%m%d_%H%M%S` /var/backup

Последняя команда отправит файлы из каталога /var/backup на сервер backup.foo, в репозиторий MyRepo, в бекап с названием в виде текущей даты/времени, сжатый алгоритмом lz4.

Настраиваем cron на выполнение этого скрипта от имени нужного вам пользователя по расписанию на ваше усмотрение.

Забираем с клиента файл id_rsa.pub и продолжаем настраивать сервер.

++ Настройка сервера. Часть 2

Снова заходим в сеанс пользователя borg

   sudo -i -u borg

На этот раз редактируем файл .ssh/authorized_keys. Добавляем строку

   command="/usr/bin/borg serve --restrict-to-repository /backup/borg/MyRepo --append-only",restrict <user key>

Теперь обладатель ключа, зайдя на сервер backup.foo под логином borg, получит возможность создавать и просматривать бекапы только в репозитории MyRepo и ни в каком более. Также обладатель этого ключа не сможет получить shell пользователя, а значит взлом клиента не даст злоумышленнику испортить ваши бекапы или даже заглянуть в другие репозитории. Это существенно поднимает безопасность реализованной схемы. Но в данном решении есть не очевидный нюанс, о котором ниже.

++ Опция --append-only

Механизм --append-only реализован не совсем интуитивно. Дело в том, что при использовании borg с этим ключом, разрешено добавлять данные, а команды на удаление пишутся в журнал транзакций, но не применяются по настоящему. По команде delete или prune, с опцией --append-only, borg сделает вид, что бекапы удалены, но на самом деле записывает команды в журнал и перестает отображать бекапы в списке. Изменения будут применены в момент выполнения любой команды, подразумевающей внесение изменений в репозиторий, без ключа  --append-only, например create, delete или prune.

Подробнее эта особенность обсуждается [[https://github.com/borgbackup/borg/issues/3504 здесь]].

Как мы обошли эту проблему при автоматизации удаления старых бекапов я покажу ниже.

++ Настройка сервера. Часть 3

Теперь мы автоматизируем удаление старых бекапов, чтобы не занять всё место на сервере. Настроим всё так, чтобы хранить последние 14 копий с интервалом в день, 8 копий с интервалом в неделю и 12 копий с интервалом в месяц. Также мы обойдем проблему с неочевидным поведением опции --append-only.

Заходим в сеанс пользователя borg

   sudo -i -u borg

Поместим список имеющихся репозиториев в файл repo.list

   echo MyRepo > repo.list

Создадим пустой файл backup.list в каталоге репозитория

   touch MyRepo/backup.list

Создадим настройку политики хранения копий, описанную выше

   echo "--keep-daily 14 --keep-weekly 8 --keep-monthly 12" > MyRepo/trim.conf

Подготовим скрипт /usr/local/bin/trim.sh

   #!/bin/bash

  
   HOME_DIR="/backup/borg/"
   REPO_LIST=`cat ${HOME_DIR}/repo.list`
  
   alarm(){
       ####
       #Тут нужно предусмотреть отправку оповещения
       ####
   }

   trim_repo(){
       #Получаем путь до репозитория и настройку сохранения бекапов
       REPO_DIR="${HOME_DIR}${1}"
       TRIM_CONF=`cat ${REPO_DIR}/trim.conf`
  
       #Получаем список бекапов в репозитории
       borg list --format '{id}{NL}' "${REPO_DIR}" > ${REPO_DIR}/backup_new.list
  
       #Ищем каждый ID из старого списка в новом. Если не нашли хотябы один бекап,
       #то код возврата будет 1. Если всё хорошо, то 0.
       cat ${REPO_DIR}/backup.list \\
       | awk -v dir=${REPO_DIR} '{print "grep -q " $0 " " dir "/backup_new.list || exit 1" }' \\
       | bash
       exit_code=$?
  
       if [[ $exit_code -gt 0 ]]; then
           #Если хотябы один ID не найден, то оповещаем ответственного за бекап человека
           alarm "В бекапе ${1} не хватает копий. Trim остановлен."
       else
           #Если старые бекапы на месте, то делаем trim, сохраняем новый список бекапов и удаляем старый
           borg prune ${TRIM_CONF} ${REPO_DIR}
           borg list --format '{id}{NL}' ${REPO_DIR} > ${REPO_DIR}/backup.list
           rm ${REPO_DIR}/backup_new.list
       fi
   }
  
   for REPO in ${REPO_LIST}; do
       trim_repo ${REPO}
   done

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

++ Политика хранения копий

Для настройки того сколько и каких копий будет хранить borg мы использовали опции, с которыми вызывалась команда prune, записанные в файле trim.conf. Рассмотрим возможные опции подробнее

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

Команда prune удалит архивы, которые не попали под указанные опции.
Опция --keep-within принимает аргумент вида "<int><char>", где char-это "H", "d", "w", "m", "y". Например, --keep-within 2d означает, что все архивы, созданные за последние 48 часов удалять нельзя. "1m" означает "31d". Архивы, попадающие под этот шаблон, не учитываются в других опциях при построении списка сохраняемых архивов.

++ Откат команд удаления

Для возврата бекапов, удалённых в режиме --append-only, нужно понять в какой момент произошло удаление и удалить транзакции, содержащие команды на удаление. Список транзакций находится в файле transactions, в каталоге репозитория. Поняв когда произошли вредоносные изменения, нужно удалить файлы транзакций с номерами вредоносной и всех последующих. Например если мы видим вот такой лог

   transaction 1, UTC time 2016-03-31T15:53:27.383532
   transaction 5, UTC time 2016-03-31T15:53:52.588922
   transaction 11, UTC time 2016-03-31T15:54:23.887256
   transaction 12, UTC time 2016-03-31T15:55:54.022540
   transaction 13, UTC time 2016-03-31T15:55:55.472564

И выяснили, что последняя легитимная транзакция имеет номер 5, то нужно удалить все транзакции после 5. Для этого в каталоге с репозиторием выполняем

   rm data/**/{6..13}
   borg delete --cache-only <имя репозитория>

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

   rm ~/.config/borg/security/REPOID/manifest-timestamp

Подробнее всё это описано [[https://borgbackup.readthedocs.io/en/stable/usage/notes.html... здесь]]

++ Извлечение и монтирование бекапов

Вы можете добавить добавить свой ssh-ключ для пользователя borg без опций --restrict-to-repository и --append-only, для управления репозиториями со своего рабочего места. В этом случае команды будут выглядеть так.

Получить список бекапов в репозитории

   borg list borg@backup.foo:<репозиторий>

Получить список файлов в бекапе

   borg list borg@backup.foo:<репозиторий>::<имя бекапа>

Извлекаем весь бекап или его часть в текущий каталог

   borg extract borg@backup.foo:<репозиторий>::<имя бекапа> [что извлекаем]

Монтируем бекап с помощью механизма FUSE

   borg mount -o users borg@backup.foo:<репозиторий>::<имя бекапа> <точка монтирования>

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

   sudo borg mount -o users --rsh "ssh -i <ваш ключ>" borg@backup.foo:<репозиторий>::<имя бекапа> <точка монтирования>

Отмонтируем командой

   borg umount <точка монтирования>

При извлечении и монтировании можно исключить файлы по шаблону ключом --exclude.

++ Заключение

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

URL:
Обсуждается: http://www.opennet.dev/tips/info/3180.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от sabitov (ok), 11-Апр-21, 17:43   +1 +/
Не то чтобы я был против, но зачем оно нужно если есть bacula/bareos, если надо "по настоящему", или fsbackup, если надо "просто"?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3

2. Сообщение от Vitto74 (ok), 12-Апр-21, 07:26   +/
bacula/bareos довольно тяжелой решение - если нужно только копирование с нескольких хостов на один, то оно через чур сложное + высокие требования к БД. Fsbackup я не применял, но не нашел в документации пояснений на счет того как удалять старые бекапы, не подходящие под заданные критерии. Кроме того, проблема защиты созданных копий от удаления, при компрометации сервера, решается не самым очевидным образом и в документации ничего об это не сказано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от Аноним (3), 12-Апр-21, 07:52   +/
Хорошо бэкапить что-то типа репозиториев, отлично дедуплицируются. И подобные шары.
А вот на активно изменяемой шаре стоит только подерево файлов просто переместить в каталог-сиблинг, дедупликация работать перестаёт, к сожалению.
Да, хотелось бы ещё и системные тома копировать с расширенными атрибутами, типа клонов виртуалок, там основная-то часть везде одинаковая, но и это не получилось, даже с применением ChunkFS.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

4. Сообщение от Помышляющий о бекапе (?), 15-Апр-21, 04:01   +/
А пока я настраиваю borgbackup, разворачиваю сервера, репозитории, настраиваю учетные записи, чем мне бэкапить систему если во время моей настройки бэкапа что-то пойдет не так? Ведь очень легко что-то сломать или недоделать и в итоге плохо настроенный бекап не решит свою задачу. Хотел бы какое-нибудь простое предложение, в идеале - чтобы бэкап делался в команду `backup_tool директория1 директория2 файл3`, и чтобы в качестве вывода эта команда написала, куда она это всё сохранила (полный путь к архиву) и что бекап завершен успешно. Если будет нужно шифрование или еще какие изыски, использую что-нибудь на базе FUSE.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #8

5. Сообщение от Vitto74 (ok), 15-Апр-21, 09:01   +/
Если только так.

apt install borgbackup
borg -e init /var/backup/borg
borg create -C lz4 /var/backup:borg::`date +%Y%m%d_%H%M%S` директория1 директория2 файл3

Или еще проще так.

tar -cjf /var/backup/`date +%Y%m%d_%H%M%S`.tar.bz2 директория1 директория2 файл3

За вас никто не будет решать куда и как складывать бекапы - в unix вы можете сконфигурировать всё и вам придется конфигурировать всё. Если хотите, чтобы решали за вас, то есть MacOS )
Конечно при настройке бекапа есть шанс накосячить и всё сломать - от этого страховки нет. Тут ни один инструмент голову не заменит - даже если вы консистентный снапшот виртуалки сделали, то не факт, что все нужные вам данные лежат на диске. Были случаи, что redis не скидывал кеш на диск и в базе было пусто.
Ни одна система бекапа не решит озвученную вами проблему - тесты и эксперименты в тестовых средах могут помочь, но не какой то отдельный инструмент.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

6. Сообщение от pansa3 (?), 01-Май-21, 15:02   +/
не нужно, питонячья свистопляска. Чуть обнвится питон или какая-то либа, и каюк бэкапу.
Есть restic , всё.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #9

7. Сообщение от askh (ok), 03-Май-21, 09:55   +/
> Есть restic , всё.

А он позволяет защититься от повреждения резервной копии системы, если она будет взломана?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #10

8. Сообщение от Аноним (8), 16-Май-21, 08:45   +/
> чем мне бэкапить систему если во время моей настройки бэкапа что-то пойдет не так? Ведь очень легко что-то сломать или недоделать

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

9. Сообщение от hex (??), 02-Дек-21, 14:20   +/
"обнвится питон или какая-то либа" - самопроизвольно ничего не обновится
"каюк бэкапу" - бекапы нужно проверять!
"Есть restic" - хорошо когда есть альтернативы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

10. Сообщение от OpenEcho (?), 10-Апр-22, 21:46   +/
restic умеет compression ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

11. Сообщение от OpenEcho (?), 10-Апр-22, 22:15   +/
borg - очеь хорошее решение для бэкапа, но работает только под ограниченными платформами.
restic - все бы хорошо, но вот копрессию так и не одолели.
dubplicati & dublicacy - стремно, теряли бэкапы

Пару лет назад перешли на kopia и не жалеем. По сравнению с borg-ом делает тоже самое - дедупликация, шифрование, компрессия, но в отличие от борга, работает практически на любой платформе и имеет кучу популярных бэкендов в отличие от борга который подерживает только SFTP.
И самое главное, написано толковым инженером где продумана архитектура далеко вперед, концептуально стораджи разбиты на репозитории (которые можно между собой синхронизировать) и в которые можно сливать с разных машин и с разных платформ и получить профит от дедуплекации и при этом разграничивая доступ к блобам по юзерам. Написанно все на Го, т.е. один единственный статически нативно скомпилированный файл, который не сломается при переходе между мажорными апдейтами. Есть UI обертка для популярных платформ, сам по себе файл подерживает тот же интерфейс через встроенный веб сервер для ленивых рыться с командной строкой. Очень гибкая система полиси и настройка доступа для каждого заведенного юзера (компьютера) т.е. тот же самый файл может работать как сервер репозитория или клиент на удаленных машинах и в тоже время может работать просто соло, для одиночной машины сливая бэкапы или локально или на удаленные стораджи, но с сервером репозитория значительно надежней, так как можно запретить клиентам удалять предыдущие снэпшаты (append only mode) которая эффективно поможет противостоять от смартных ransomware, которые шифруют потихоньку и портят бэкапы.

Ну вот как то так, хотел на пару слов но получилось много букв...

Ответить | Правка | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру