The OpenNET Project / Index page

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

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

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

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

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


Установка

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

Для CentOS

   sudo yum install borgbackup

Для Debian/Ubuntu

   sudo apt install borgbackup

Или можно скачать исполняемый файл и установить его в систему. Скачиваем его со этой
страницы и выполняем

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

Подробнее об установке на другие дистрибутивы

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 [email protected]: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.

Подробнее эта особенность обсуждается здесь.

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

Настройка сервера. Часть 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 Подробнее всё это описано здесь Извлечение и монтирование бекапов Вы можете добавить добавить свой ssh-ключ для пользователя borg без опций --restrict-to-repository и --append-only, для управления репозиториями со своего рабочего места. В этом случае команды будут выглядеть так. Получить список бекапов в репозитории borg list [email protected]:<репозиторий> Получить список файлов в бекапе borg list [email protected]:<репозиторий>::<имя бекапа> Извлекаем весь бекап или его часть в текущий каталог borg extract [email protected]:<репозиторий>::<имя бекапа> [что извлекаем] Монтируем бекап с помощью механизма FUSE borg mount -o users [email protected]:<репозиторий>::<имя бекапа> <точка монтирования> При монтировании могут возникнуть проблемы с правами доступа к файлам. В этом случае можно смонтировать через sudo, переопределив команду ssh. В этом случае ходить по смонтированному бекапу также придется с помощью sudo sudo borg mount -o users --rsh "ssh -i <ваш ключ>" [email protected]:<репозиторий>::<имя бекапа> <точка монтирования> Отмонтируем командой borg umount <точка монтирования> При извлечении и монтировании можно исключить файлы по шаблону ключом --exclude. Заключение На этом всё. Я надеюсь, что эта статья станет хорошей отправной точкой при проектировании или модернизации вашей схемы резервного копирования. Borg старается следовать философии unix и хорошо занимается одним делом - управляет архивами. Используя этот инструмент вы сможете создать схему резервного копирования подходящую именно вам.
  •  
    10.04.2021 , Автор: Александр
    Ключи: borg, backup / Лицензия: CC-BY
    Раздел:    Корень / Администратору / Система / Диски и файлы / Резервное копирование

    Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, sabitov (ok), 17:43, 11/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не то чтобы я был против, но зачем оно нужно если есть bacula/bareos, если надо "по настоящему", или fsbackup, если надо "просто"?

     
     
  • 2.2, Vitto74 (ok), 07:26, 12/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    bacula/bareos довольно тяжелой решение - если нужно только копирование с нескольких хостов на один, то оно через чур сложное + высокие требования к БД. Fsbackup я не применял, но не нашел в документации пояснений на счет того как удалять старые бекапы, не подходящие под заданные критерии. Кроме того, проблема защиты созданных копий от удаления, при компрометации сервера, решается не самым очевидным образом и в документации ничего об это не сказано.
     
  • 2.3, Аноним (3), 07:52, 12/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Хорошо бэкапить что-то типа репозиториев, отлично дедуплицируются. И подобные шары.
    А вот на активно изменяемой шаре стоит только подерево файлов просто переместить в каталог-сиблинг, дедупликация работать перестаёт, к сожалению.
    Да, хотелось бы ещё и системные тома копировать с расширенными атрибутами, типа клонов виртуалок, там основная-то часть везде одинаковая, но и это не получилось, даже с применением ChunkFS.

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

     

  • 1.4, Помышляющий о бекапе (?), 04:01, 15/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А пока я настраиваю borgbackup, разворачиваю сервера, репозитории, настраиваю учетные записи, чем мне бэкапить систему если во время моей настройки бэкапа что-то пойдет не так? Ведь очень легко что-то сломать или недоделать и в итоге плохо настроенный бекап не решит свою задачу. Хотел бы какое-нибудь простое предложение, в идеале - чтобы бэкап делался в команду 'backup_tool директория1 директория2 файл3', и чтобы в качестве вывода эта команда написала, куда она это всё сохранила (полный путь к архиву) и что бекап завершен успешно. Если будет нужно шифрование или еще какие изыски, использую что-нибудь на базе FUSE.
     
     
  • 2.5, Vitto74 (ok), 09:01, 15/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Если только так.

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

     
  • 2.8, Аноним (8), 08:45, 16/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > чем мне бэкапить систему если во время моей настройки бэкапа что-то пойдет не так? Ведь очень легко что-то сломать или недоделать

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

     

  • 1.6, pansa3 (?), 15:02, 01/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    не нужно, питонячья свистопляска. Чуть обнвится питон или какая-то либа, и каюк бэкапу.
    Есть restic , всё.
     
     
  • 2.7, askh (ok), 09:55, 03/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть restic , всё.

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

     
     
  • 3.10, OpenEcho (?), 21:46, 10/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    restic умеет compression ?
     
  • 2.9, hex (??), 14:20, 02/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    "обнвится питон или какая-то либа" - самопроизвольно ничего не обновится
    "каюк бэкапу" - бекапы нужно проверять!
    "Есть restic" - хорошо когда есть альтернативы
     

  • 1.11, OpenEcho (?), 22:15, 10/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    borg - очеь хорошее решение для бэкапа, но работает только под ограниченными платформами.
    restic - все бы хорошо, но вот копрессию так и не одолели.
    dubplicati & dublicacy - стремно, теряли бэкапы

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

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




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

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