Блог компании Флант
Настройка Linux
Резервное копирование
Серверное администрирование
Системное администрирование
Комментарии 40
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
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.