Флант corporate blog
Configuring Linux
Backup
Server Administration
System administration
Comments 44
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
Bareos тоже умеет, я упоминал про bpipe. С автором этой статьи во многом соглашусь.
0

Цель ведь не сделать бэкап, на чем почему то все зацикливаются. А иметь 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

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
а если винда — источник, тоже по 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 без хранения бэкапов в виде бинарных архивов могут быть удобнее :)
+1
rsnapshot неплох для бэкапа/восстановления большого количества мелких файлов, и, что важно, быстрого восстановления любой их части. Листинг не отличается от листинга обычного каталога.
Дедупликация на уровне хардлинков на fs. Если файлы бинарные (картинки, аудио) вполне неплохой вариант, так как они редко изменяются «частично», и полное хранение измененного бинарного файла никак не скажется на объеме бэкапа в случае хранения диффа. Ну и терабайты текста/кода редко когда нужно бэкапить (обычно десятки, ну край сотни мегабайт), а вот у фото, видео, аудио и прочей бинарной информации объемы могут быть солидные.

Из минусов rsnapshot — нельзя по простому посмотреть разницу между, например, вчерашним и сегодняшним бэкапами. Есть просто 2 каталога/папки, их нужно сравнивать какими нибудь сторонними программами. Но если мы говорим о бэкапе — то версионность это не его задача. Это просто слепок на конкретный момент времени, который, по возможности, занимает наименьший объем места.

Насчет бэкапов базы данных — это вообще отдельная история и тут надо смотреть в каждом конкретном случае, как лучше. Начиная от mysqldump >backup.sql и не исключая вариантов с «тупым копированием rsync» файлов БД на временно остановленной реплике (неплохо бы еще таблицы иметь партиционированные, а не просто огромный блоб, если объем базы большой)
0
Как раз перешел на rsnapshot — на порядок быстрее и удобнее borgа!
Единственный минус — rsnapshot создает структуру <время><сервер> и бэкапит директории\сервера из одного конфига последовательно. Пришлось городить по отдельному конфигу для каждого сервера, чтобы иметь возможность запускать их параллельно и гибко настраивать время для каждого. Для поиска измененных файлов подходит diff -qr и все прочее :)

Базы так и бекапятся: mysqldump > gzip > rsync раз в сутки + find для удаления версий старше n дней
0
Из минусов rsnapshot — нельзя по простому посмотреть разницу между, например, вчерашним и сегодняшним бэкапами.

Вот же.
Only those users with full accounts are able to leave comments. , please.