Привет. Что обычно используют для бэкапа серверов?

bash, cron, скотч… (:

Хотел запилить бакулу, по почитав его описание ужаснулся и решил что будет проще навелосипедить своей велосипед. Штука получилась сомнительная, но вроде ездит.

Подписался на тему, может будут какие-то интересные варианты.

Хотел запилить бакулу, по почитав его описание ужаснулся и решил что будет проще навелосипедить своей велосипед.

Вроде еще какая-то webacula есть (веб-морда). Сам не смотрел, интересно может ли она как-то упростить жизнь.

Мда, в похожих висит почти такой же недавний тред без решения. Пусть тогда это будет тред негодования :)

Нонче принято бэкапить образы виртуалок естественными для гипервизора методами.

webacula годна как мониторилка и просмотр статистики. Остальное всё равно ручками делать.

Хотел запилить бакулу

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

Какие методы есть у KVM? У Docker? Виртуалки это хорошо, но на локальную файлопомойку и git сервер полноценную виртуалку нет смысла ставить (кстати там docker используется). На продакшн под достаточно нагруженный сайтик тоже не хотелось бы — необоснованные потери производительности.

ИМХО, ересью попахивает. Бекапится много лишнего и вообще как-то не аккуратно.

В тот момент мне показалось что это оверкил.

Bacula педалит в случае если нужна гибкая настройка, зависит от того что вы собираетесь бекапить, как, и как часто. При первой настройке можно себе мозг вынести конкретно особенно в случае если до того не было опыта общения с ленточными библиотеками. Но оно того стоит если требуется бекапить много машин. В качестве более простой альтернативы см. BackupPC.

Bacula/Bareos

К сожалению альтернатив Bacul'е/Bareos'у нет. И таки все действия по добавлению нового клиента в достаточной степени можно автоматизировать.

Свой велосипед тоже плохой вариант.

Почему? rsync и хардлинков достаточно. Скрипт на 10 строк будет.

Почему? rsync и хардлинков достаточно. Скрипт на 10 строк будет.

Не хочу чтобы этот велосипед сломался в самый неподходящий момент. Можно неплохо огрести в случае чего.

И таки все действия по добавлению нового клиента в достаточной степени можно автоматизировать.

Клиентов пока немного и добавлять новые вроде не планируется. По идее один раз настроил и забыл, но этот первый раз это просто незабываемый трах мозга.

Ну как сказать. В общем случае, чем проще софт, тем менее вероятно, что он сломается :) Вот бакула, в отличие от своего велосипеда, меня подводила.. Хотя конечно дело скорее всего в моих кривых руках при настройке, но.

Чем сложнее софт, тем больше шанса накосячить в настройке.

Какие методы есть у KVM? У Docker?

zfs? :-D

Ну нет уж, спасибо :-)

Кстати, а чем потом диффы по сети передавать?

Rsnapshot + nagios check

diffы по сети..? Да оно нативно умеет. А так - хоть чем. Хоть через ssh, можешь за одно и скорость порезать, чтобы не мешалось...

zfs

Ну нет уж, спасибо :-)

обоснуй.

zfs send -R -i zpool1/fs@-2015-02-13 zpool1/fs@-2015-02-14 | ssh 192.0.0.x zfs receive zpool2/backup/fs

обоснуй

Допустим система уже работает и менять ФС не вариант. Допустим это дедик, нужно брать платный KVM, патчить ядро, ставить и т.д. В итоге гемороя сильно больше чем с бакулой. При обновлении пропатченного ядра может не загрузиться — опять брать KVM. В принципе ставить какие-то левые патчи на продакшн сервер это плохая идея. И опять же нужно велосипедить скрипт, который будет сливать бэкапы и мониторить все это дело.

Все тоже самое я могу сделать с помощью rsync и cron и ZFS тут вообще не нужна. Тем более это просто ФС, а не система бэкапа.

Допустим система уже работает и менять ФС не вариант.

Я бы в таком случае взял бы ansible и объяснил чего и куда ему rsyncать. :) А на другом конце я бы всё это добро складывал бы на zfs, и делал бы там снепшоты.

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

система уже работает и менять ФС не вариант.
это дедик, нужно брать платный KVM, патчить ядро, ставить и т.д.

в таком раскладе не подойдет.

могу сделать с помощью rsync и cron и ZFS тут вообще не нужна

http://habrahabr.ru/post/239513/

тред не читал, но у меня rsync и zfs. полет нормальный.

но мне бы что-то посерьезнее.

bacula.

Какие методы есть у KVM?

ZFS и точка.

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

если с другого компа с zfs разворачивать на новый комп, то 1Т меньше/быстрее не станет. И именно поэтому я тебе советовал отдельные маленькие диски, чтобы не ждать день восстановления

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

Копия на дисках на соседнем сервере это не совсем бэкап, а горячее резервирование. Прыгнет электричество или взбрыкнет УПС и оба сервера увидят свет в конце туннеля. И что ты будешь делать?

Ну у меня в качестве альтернативы - в разных зданиях. + ИБП. В S3, тоже можно, но долго, и дорого. :) Хотя у них там была штука для бекапов, куда заливать можно за дёшего, а вот доставать за дорого, забыл как называется... :)

Ты все понял, делай как хочешь. Ты ведь не думаешь, что тут кого-то интересует что и как у тебя будет на самом деле. ЛОР он такой — ЧСВ почесать, вон даже vxz не выдержал под чужим ником, никто не узнает :-)

Дык этот топик не мой, про бекап серверов. :) Я так... Да я же вменяемый, и адекватный, и понимаю что приватные облака и сервисы - мертвы, админы не нужны, и всем давно пора в паблик облака. Но реальность пока тормозит всё это дело, ибо Интернеты не очень у нас быстрые, облака далеко и дорого стоят. Вон, тот же амазон - в РФ не собирается похоже. А какие нафиг у него конкуренты..? Да никаких. Ну ажуре разве. Так что я понимаю, что в одно лицо, не возможно создать надёжную, и простую инфраструктуру... Да чтобы ещё и за дёшего. Нет. Не бывает так. :)

и всем давно пора в паблик облака.

С чего ты взял? Это хорошо для стартапа, когда они еще не знают взлетят или нет, тогда не надо вкладываться в свое, а так-то лучше свое под боком.

Так что я понимаю, что в одно лицо, не возможно создать надёжную, и простую инфраструктуру... Да чтобы ещё и за дёшего.

Ставь ближние цели. Поднять и работать сейчас. Предупреди что из-за ограниченности бюджета могут быть простои и задержки развертывания и будешь защищен от нападок экономного руководства.

админы не нужны, и всем давно пора в паблик облака.

Облака умерли, они больше никому не нужны, кто пробовал те наелись этого дерьма по самые гланды и больше к ним не вернутся.

Своё под боком - дорого. Вот в чём проблема. Нам просчитывали, получилось более 10миллионов (полки, архив, блейды, ПО, сеть). Просто нерентабельно для бизнеса. А прикинь мы бы взяли это в 2010 году бы всё..? Там бы нам тогда продали бы 4ую вмварь... Чего бы сейчас мы с ней делали бы..? Думали бы об апгрейде..? Тоже сомнительное удовольствие в общем.

Ставь ближние цели. Поднять и работать сейчас. Предупреди что из-за ограниченности бюджета могут быть простои и задержки развертывания и будешь защищен от нападок экономного руководства.

Да, я всё так и говорю, как есть. Без прекрас. Пока в общем то справляюсь, и за много лет, особых факапов не было. Но... К примеру у нас нету домена виндового, разворачиваем нужное нам ПО ручками - долго... Уже негодуют все, но в целом терпят, и понимают, ибо цена вопроса - кусачая...

Что там у вас за проект что для него нужен ЦОД на десять лямов и виндовый домен?

Облака умерли, они больше никому не нужны, кто пробовал те наелись этого дерьма по самые гланды и больше к ним не вернутся.

По-моему, стоимость содержания IaaS в облаке существенно ниже, чем содержать своё. При грамотном подходе. Это считай, тебе не серверные не нужны, ничего не нужно. Но это мечты. На практике - очень сильно зависит от задач. К примеру нам облака в принципе не подходят... - Мы 7 месяцев из одного Подмосковья, в другое, ходили через Франкфурт, с неслабым пингом... - Провайдеры там между собой посрались какие-то... И поменяли маршруты. И всё. Хоть обосрись, ничего не сделаешь. Но если паблик сервис, или сервис, где требуется широкая георгафия покрытия - то облака конечно это очень большой бонус.

rsync и хардлинков достаточно. Скрипт на 10 строк будет

Это же не бэкап. Как спасёшься от повреждения файла?

Боженька правый, умолять тебя начну голышом сейчас... Проект... Блин, там пол суммы из этой стоимости было ПО, от VMWare. Ну мы интерсовались VDI. Без VDI, там было бы 5-6. Блин, да знаешь как всё дорого..? Посмотри, сейчас один сраный жёсткий диск серверный на терабайт, стоит под 50к. Чего уже говорить: файбер чанеле, корзине, об бекапе, и архиве - именно такая архитектура рассматривалась. Ибо полагаться на одну корзину - тоже дело такое... Глюк какой-нибудь случись, или обновить ПО надо скажем ... И кирдык. Тоже короче дело такое, эти приватные клауды... + Файбер свитчи с резервированием. - Ибо навернётся так один свитч... И капец, считай всё встанет. Вот и набежала сумма. + работа, обучение. Никто за так этого делать не будет, ничего ставить и настраивать не будут.

чета никто про backupninja и не вспомнил

Это же не бэкап

Почему?

Как спасёшься от повреждения файла?

Не совсем понял вопроса. От повреждения файла где? Если на сервере, который бекапится - достану файл из бекапа. Если на сервере, на который бекапится, то возьму бекап за вчера или, в худшем случае, потеряю бекап :) Но какая система бекапа может спасти от повреждения файла на сервере с бекапом?

Если на сервере, который бекапится

А при чём тут хардлинки тогда?

А при чём тут хардлинки тогда?

Примерно такой алгоритм:
1. На сервере есть директория srv:/data
2. Копируем её рсинком на бекапный сервер в backup:/data
3. Потом на бекапном сервере cp -al /data /data_20150216 (при желании можно добавить суффиксы _weekly, _daily и т.д.)
4. На следующий день опять рсинкаем srv:/data в backup:/data (но копируются только те файлы, которые изменились)
5. cp -al /data /data_20150217

В итоге получается костыльный, но рабочий инкрементальный файловый бекап :)

4. На следующий день опять рсинкаем srv:/data в backup:/data

Ага, ясно. Я думал, что rsync не рвёт хардлинки. Проверил — рвёт. Так что сработает :)