Теория и практика бэкапов с Borg



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

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



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



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


    Применение 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.


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

    Флант

    340,00

    Специалисты по DevOps и высоким нагрузкам в вебе

    Поделиться публикацией
    Комментарии 41
      0
      Спасибо за статью. У меня вопрос: бэкапы на ленту нормально делает?
        0
        Вот да, искал вменяемое решение по бекапу на ленты, толком не нашел.
        Пока настроишь BareOS это же ппц.
        Под Windows довольно удобен оказался Veeam B&R, но под linux ничего похожего не нашел.
        +2

        У меня вопрос, а можно ли считать бэкапом обычное пофайловое копирование? А как же консистентность данных? Интеграция с сервисами, например с базами данных? Вы сами пишите про копирование больших файлов. Могу предположить, что копирование такого файла занимает N-ое количество времени. А если в процессе копирования кто-то меняет часть данных в этом файле, да еще не однократно? А если этот файл относиться к базе данных или виртуальной машине? Вы уверены, что в конце такого копирования вы не получите "бэкап шредингера"? Который как бы есть, но вот получиться ли с него что-то восстановить?


        По мне так что Borg, что Bacula это надстройка над неким аналогом rsync и бэкапом это называть не совсем честно.

          0
          Отчего ж нет. Резервная копия она и в африке резервная копия. Просто разные требования к консистентности. Современные энтерпрайз системы СРК имеют свои встроенные методы повышения консистентности бекапа (за это и тратят на них кучу денег). У бесплатных, ИМХО, главное требование: чтобы оно вовремя и без ошибок копировало файлы строго по расписанию.
            +1

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


            P.s. пошел посыпать голову пеплом.

              0
              Ну ситуации бывают разные. Ну что значит оперативно восстановиться? Оперативно восстановиться на 1 день назад, на 1 час, на 10 минут или вообще на период перед «something wrong».
              Восстановиться после логической ошибки, ошибки системы, выхода из строя HDD, сервера, молнии в проводку, пожара, природного катаклизма и т.п.
              Гарантия что бекап окажется точно рабочий 50%, 99%, 99.99%.

              Вообще сейчас использую bareos. Чтобы запустить пришлось патчить, понять как это работает потратил неделю. При этом не могу победить баг по которому забирает архивы с папки full бекапом, вместо increment. Причем если запустить в ручном режиме — работает все корректно… А так логика системы интересная и гибкая, но как она себя поведет в критической ситуации для меня неизвестно. Сейчас смотрю в сторону резервного бекапа над бекапом — чтобы совсем у разбитого корыта не остаться в случае багов бареоса.
                0

                Под "оперативно" я понимаю восстановиться за разумное время и на состояние последней резервной копии, а не тратить на это день-другой или неделю. Сколько данных будет при этом потеряно 10 минут, сутки или неделя на момент возникновения проблемы и необходимости начать восстановление — это другой вопрос. И тут, о чудо, мы плавно переходим к пониманию что такое RPO и RТO, не разобравшись с которыми не построить хороший (для конкретной ситуации) бэкап. :)

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

            borg весьма быстрый, однако абсолютную консистентность можно обеспечить используя снапшоты фс (например с zfs).


            Естественно, если бекапить боргом бинарные файлы БД или образов виртуалок без предварительного снапшота фс/суспенда софта — можно получить что-то не очень целостное.

              +1

              Снэпшоты это хорошо, но в случае БД и виртуалок нужно сказать еще этой самой БД и софту в виртуалке, что нужно сбросить все кэши из оперативки на диски. Иначе будет просто снэпшот FS с неконсистентными и невосстановимыми данными. Но про это нет ни слова в данной статье про "отличный софт резервного копирования".

                0

                За все БД не знаю, но например мускль отлично бекапится через mysqldump. Причем он это может делать очень быстро.

                  +1

                  Согласен. Но где в этом процессе тот же Borg? :). Копировать готовые бэкапы по расписанию можно чем угодно, как и хранить их с той же дедупликацией на FS, которые это умеют. Про сжатие уже молчу просто.

          0
          По мне так что Borg, что Bacula это надстройка над неким аналогом rsync и бэкапом это называть не совсем честно.
          когда пользовался бакулой, то при запуске бекапа там была возможность запускать команды перед самим бекапом, в случае mysql, я запускал обычный mysqldump, так что проблем с консистентностью не было. Естевенно бекап запускался ночью на слейве, когда нагрузки практиечски не было.
            +1

            Ну то есть вы бакулой копировали готовый mysqldump куда то в другое место, на другой сервер. Я правильно понимаю? Т.е. по факту делали бэкап встроенными средствами data base, а бакула — это что бы rsync или scp не настраивать?


            Или я все не правильно понял?

              0
              Все правильно, ибо чудес не бывает. Хотя насколько помню, например, для бекапа виртуалок у bacula был специальный плагин, вот только не помню в платной версии или бесплатной. Так вот плагин уже учитывал особенности виртуализации и не просто копировал файлы, тонкостей уже не помню, если интересно можете поискать.
                +1

                Чудес не бывает, я тут с вами полностью согласен. Хотя каждый из нас понимает это по своему :).

            0

            Когда дошел до GitLab немного был озадачен, зачем вы используете его вместо скажем Ansible… Но да ладно… Каждый сходит с ума по свойму.


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


            Нашелся вот такой проект http://www.borgbackupserver.com/ и видео от него. https://www.youtube.com/watch?v=DkS9AWG1S5A.
            Видео ролику скоро будет год, но проекта всё еще нет. Надеюсь что проект не умер не успев родится...

              0
              Кхм. Ансибл рекомендуют так же из гита рулить, например. Почему не через ансибл, который рулится из гита — так порог вхождения для настройки бэкапов будет пониже.
              +3
              Не упомянули убер фичу монтирование любых бэкапов через FUSE.
              Тоже столкнулся с тем, что на удливление мало статей о Borg. Но оказалось, он весьма прост и вполне хватает официального мануала.
                0
                а вот если, извиняюсь, винда?
                  0
                  openssh сервер? :)
                    0
                    а можно для чайников расшифровать?
                      0
                      а если винда — источник, тоже по ssh можно стягивать? или монтировать самбу…
                        +1
                        лучше монтировать самбу, так как много процессорного времени уходит на шифрование канала, так-же процессор нужен для создания бэкапа, поэтому для ssh его лучше экономить.
                    0
                    Хочу дополнить статью, вот этим постом, который я когда-то писал. К сожелению я тогда не очень хорошо описал, что там именно происходит и статья прошла мимо.
                    У нас есть самописный велосипед программа, которая может заглядывать в лайблы (докер) и аннотации (kubernetes) и если там находит строчку с «backup», выключает container/deploy и делает с volume's бэкапы (которые были указаны). Если это соединить со снапшотами (ceph или btrfs), то очень даже хорошо получается.
                    То есть я говорю, что вот это докер сервер, а это kubernetes и он там сам ищет уже что надо сохранять, ну и простые файлы с серверов можно тоже сохранять (линукс и виндовс). Ну и там ещё некоторое количество плюшек есть.

                    Про сам борг могу сказать, что работает он быстро и самое главное у него все бэкапы считаются полными. У меня на востановление 2,1Тб (1gb/s) ушло 9 часов (много мелких файлов)
                      0
                      С urbackup не пробовали сравнивать? Он хоть снапшоты умеет.
                        0
                        со стабильностью у него не очень, ну и сама логика взаимоотношений клиент-сервер немного странновата.
                        снапшоты толком работают только в виндовс
                          0
                          Какие конкретно проблемы со стабильностью? И что не так с логикой взаимоотношений?

                          Бекапить что-либо, кроме винды, в общем-то, и нет необходимости. На *никсах найти нормальный скрипт бекапа со снапшотом дело минут, а написать свой — полчаса.
                            +1
                            Проблема как раз в том, что образы не всегда снимаются ) и не всегда рабочие в итоге.
                            взаимоотношение… ну идея о том, что сервер находит клиентов бродкастом и все в одной L2, а остальное все (доступ через нат и тд) больше бонус чем функционал, мне не зашла. но каждому свое.

                            Говоря о бэкапах многие учитывают, только то КАК снять образ… а что с ним делать дальше?
                            данные надо хранить и управлять ими. Это и дедупликация и инкерментные и дифф бэкапы и проверка и восстановление в виде ВМ и удаление старых образов.
                            Обычно скриптописатели за полчаса все это опускают.
                              0
                              Проблема как раз в том, что образы не всегда снимаются

                              К разработчику с вопросом обращались?

                              взаимоотношение… ну идея о том, что сервер находит клиентов бродкастом и все в одной L2, а остальное все (доступ через нат и тд) больше бонус чем функционал, мне не зашла. но каждому свое.

                              То есть ничего конкретного, кроме того, что лично вам не зашло?

                              Говоря о бэкапах многие учитывают, только то КАК снять образ… а что с ним делать дальше?

                              Восстанавливать в случае необходимости. А есть ещё какие-то способы применения?

                              данные надо хранить и управлять ими. Это и дедупликация и инкерментные и дифф бэкапы и проверка и восстановление в виде ВМ и удаление старых образов.

                              Н-н-ну. Вы ставили urbackup? Инкрементальные и дифференциальные бекапы имиджей дисков он делает. Веб-интерфейс для управления имеется. Дедупликация лежит на плечах файловой системы — ну тут уж, простите, не тот уровень.

                              Обычно скриптописатели за полчаса все это опускают.

                              А каким боком к скриптописателям, которые легко и просто пишут свои скрипты для своих же *никсов, проблемы виндов?
                        0
                        Вместо cron'a лучше backupninja использовать. В репозиториях есть. Одно задание — один файл. Деплоить удобно. Уведомления о статусе легко прикрутить.
                          0
                          А ещё если отойти от серверов (там не пробовал) то хочу упомянуть borgmatic.
                          Один скрипт конфигурации и в крон пишется одна команда «borgmatic». Пользуюсь для всех своих машин уже несколько лет, полёт нормальный.
                            +1
                            А права на файлы он сохраняет?
                            А то немного смутило вот это
                            borg@b3e51b9ed2c2:~$ ll etc/hostname 
                            -rw-r--r-- 1 borg borg 13 Aug  4 16:27 etc/hostname
                            

                              +2
                              Вот что по этому поводу пишет разработчик в issue #1751:
                              OK, then see the attic issue I mentioned. The point is you told borg to only extract one file (not directories), so it had only the data of that one file. It created the directories on-the-fly without having metadata for them, except the names (which are stored with the file)

                              Т.е. если восстанавливаем отдельный файл — borg ничего не знает о правах т.к. «не смотрел» весь архив и его метаданные.
                              В случае восстановления всего архива — права восстанавливаются.
                              0
                              borg create --stats --list borg@172.17.0.3:MyBorgRepo::«MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}» /etc /root

                              Нужно изменить права в файле /etc/passwd
                              borg:x:0:0:borg:/borg:/bin/bash
                              0
                              Я тут «имел удовольствие» бэкапить 1.5 тб фотографий в 3-х уровневой структуре с помощью Borg — из-за того, что он хранит бэкап в бинарных файлах единым массивом, листинг потом мог занимать часы, а восстановление сотни файлов пару дней — столько же, сколько сам бэкап изначально совершался. Хуже того, сама обратная связь на ошибки или отсутствие файлов была такой же медленной.
                              Я так понимаю, это проблема всех решений, кто хранит бэкап в виде снимков.
                              Изначально выбрал Borg из-за теоретической скорости создания инкрементного бэкапа и дедупликации, но есть вариант, что решения на rsync без хранения бэкапов в виде бинарных архивов могут быть удобнее :)

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

                              Самое читаемое