Comments 46
У меня вопрос, а можно ли считать бэкапом обычное пофайловое копирование? А как же консистентность данных? Интеграция с сервисами, например с базами данных? Вы сами пишите про копирование больших файлов. Могу предположить, что копирование такого файла занимает N-ое количество времени. А если в процессе копирования кто-то меняет часть данных в этом файле, да еще не однократно? А если этот файл относиться к базе данных или виртуальной машине? Вы уверены, что в конце такого копирования вы не получите "бэкап шредингера"? Который как бы есть, но вот получиться ли с него что-то восстановить?
По мне так что Borg, что Bacula это надстройка над неким аналогом rsync и бэкапом это называть не совсем честно.
Всегда считал, что главное у любых бэкапов — это что бы из них в любой ситуации можно было оперативно восстановиться. Но видимо серьезно ошибался.
P.s. пошел посыпать голову пеплом.
Восстановиться после логической ошибки, ошибки системы, выхода из строя HDD, сервера, молнии в проводку, пожара, природного катаклизма и т.п.
Гарантия что бекап окажется точно рабочий 50%, 99%, 99.99%.
Вообще сейчас использую bareos. Чтобы запустить пришлось патчить, понять как это работает потратил неделю. При этом не могу победить баг по которому забирает архивы с папки full бекапом, вместо increment. Причем если запустить в ручном режиме — работает все корректно… А так логика системы интересная и гибкая, но как она себя поведет в критической ситуации для меня неизвестно. Сейчас смотрю в сторону резервного бекапа над бекапом — чтобы совсем у разбитого корыта не остаться в случае багов бареоса.
Под "оперативно" я понимаю восстановиться за разумное время и на состояние последней резервной копии, а не тратить на это день-другой или неделю. Сколько данных будет при этом потеряно 10 минут, сутки или неделя на момент возникновения проблемы и необходимости начать восстановление — это другой вопрос. И тут, о чудо, мы плавно переходим к пониманию что такое RPO и RТO, не разобравшись с которыми не построить хороший (для конкретной ситуации) бэкап. :)
borg весьма быстрый, однако абсолютную консистентность можно обеспечить используя снапшоты фс (например с zfs).
Естественно, если бекапить боргом бинарные файлы БД или образов виртуалок без предварительного снапшота фс/суспенда софта — можно получить что-то не очень целостное.
Снэпшоты это хорошо, но в случае БД и виртуалок нужно сказать еще этой самой БД и софту в виртуалке, что нужно сбросить все кэши из оперативки на диски. Иначе будет просто снэпшот FS с неконсистентными и невосстановимыми данными. Но про это нет ни слова в данной статье про "отличный софт резервного копирования".
За все БД не знаю, но например мускль отлично бекапится через mysqldump. Причем он это может делать очень быстро.
Согласен. Но где в этом процессе тот же Borg? :). Копировать готовые бэкапы по расписанию можно чем угодно, как и хранить их с той же дедупликацией на FS, которые это умеют. Про сжатие уже молчу просто.
Борг умеет пайпы )
killer feature :)
Цель ведь не сделать бэкап, на чем почему то все зацикливаются. А иметь 100% возможность восстановиться из бэкапа. А то в интернете потом болтается куча вот таких вопросов без ответа:
https://sysadmins.ru/topic426315.html
http://bacula.10910.n7.nabble.com/error-bpipe-closing-stream-when-run-a-restore-of-a-VM-with-bacula-and-ghetto-td86029.html
https://github.com/Rblp/Rblpapi/issues/168
По мне так что Borg, что Bacula это надстройка над неким аналогом rsync и бэкапом это называть не совсем честно.когда пользовался бакулой, то при запуске бекапа там была возможность запускать команды перед самим бекапом, в случае mysql, я запускал обычный mysqldump, так что проблем с консистентностью не было. Естевенно бекап запускался ночью на слейве, когда нагрузки практиечски не было.
Ну то есть вы бакулой копировали готовый mysqldump куда то в другое место, на другой сервер. Я правильно понимаю? Т.е. по факту делали бэкап встроенными средствами data base, а бакула — это что бы rsync или scp не настраивать?
Или я все не правильно понял?
Когда дошел до GitLab немного был озадачен, зачем вы используете его вместо скажем Ansible… Но да ладно… Каждый сходит с ума по свойму.
Спасибо за статью, о Borg ранее не знал. Буду изучать и пользоваться, судя по сайту и всему что нашел в инете достаточно прогрессивный, молодой и быстро развивающийся инструмент.
И действительно, ему GUI немного не хватает для полноценного бекапа, но пока что он с лихвой окупает своими другими возможностями отсутствие централизованного GUI.
Нашелся вот такой проект http://www.borgbackupserver.com/ и видео от него. https://www.youtube.com/watch?v=DkS9AWG1S5A.
Видео ролику скоро будет год, но проекта всё еще нет. Надеюсь что проект не умер не успев родится...
Тоже столкнулся с тем, что на удливление мало статей о Borg. Но оказалось, он весьма прост и вполне хватает официального мануала.
У нас есть самописный
То есть я говорю, что вот это докер сервер, а это kubernetes и он там сам ищет уже что надо сохранять, ну и простые файлы с серверов можно тоже сохранять (линукс и виндовс). Ну и там ещё некоторое количество плюшек есть.
Про сам борг могу сказать, что работает он быстро и самое главное у него все бэкапы считаются полными. У меня на востановление 2,1Тб (1gb/s) ушло 9 часов (много мелких файлов)
снапшоты толком работают только в виндовс
взаимоотношение… ну идея о том, что сервер находит клиентов бродкастом и все в одной L2, а остальное все (доступ через нат и тд) больше бонус чем функционал, мне не зашла. но каждому свое.
Говоря о бэкапах многие учитывают, только то КАК снять образ… а что с ним делать дальше?
данные надо хранить и управлять ими. Это и дедупликация и инкерментные и дифф бэкапы и проверка и восстановление в виде ВМ и удаление старых образов.
Обычно скриптописатели за полчаса все это опускают.
Один скрипт конфигурации и в крон пишется одна команда «borgmatic». Пользуюсь для всех своих машин уже несколько лет, полёт нормальный.
А то немного смутило вот это
borg@b3e51b9ed2c2:~$ ll etc/hostname
-rw-r--r-- 1 borg borg 13 Aug 4 16:27 etc/hostname
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 ничего не знает о правах т.к. «не смотрел» весь архив и его метаданные.
В случае восстановления всего архива — права восстанавливаются.
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
Я так понимаю, это проблема всех решений, кто хранит бэкап в виде снимков.
Изначально выбрал Borg из-за теоретической скорости создания инкрементного бэкапа и дедупликации, но есть вариант, что решения на rsync без хранения бэкапов в виде бинарных архивов могут быть удобнее :)
Дедупликация на уровне хардлинков на fs. Если файлы бинарные (картинки, аудио) вполне неплохой вариант, так как они редко изменяются «частично», и полное хранение измененного бинарного файла никак не скажется на объеме бэкапа в случае хранения диффа. Ну и терабайты текста/кода редко когда нужно бэкапить (обычно десятки, ну край сотни мегабайт), а вот у фото, видео, аудио и прочей бинарной информации объемы могут быть солидные.
Из минусов rsnapshot — нельзя по простому посмотреть разницу между, например, вчерашним и сегодняшним бэкапами. Есть просто 2 каталога/папки, их нужно сравнивать какими нибудь сторонними программами. Но если мы говорим о бэкапе — то версионность это не его задача. Это просто слепок на конкретный момент времени, который, по возможности, занимает наименьший объем места.
Насчет бэкапов базы данных — это вообще отдельная история и тут надо смотреть в каждом конкретном случае, как лучше. Начиная от mysqldump >backup.sql и не исключая вариантов с «тупым копированием rsync» файлов БД на временно остановленной реплике (неплохо бы еще таблицы иметь партиционированные, а не просто огромный блоб, если объем базы большой)
Единственный минус — rsnapshot создает структуру <время><сервер> и бэкапит директории\сервера из одного конфига последовательно. Пришлось городить по отдельному конфигу для каждого сервера, чтобы иметь возможность запускать их параллельно и гибко настраивать время для каждого. Для поиска измененных файлов подходит diff -qr и все прочее :)
Базы так и бекапятся: mysqldump > gzip > rsync раз в сутки + find для удаления версий старше n дней
Теория и практика бэкапов с Borg