Bacula - резервное копирование данных настроить

Думаю стоит начать с прочтения документации на сайте разработчика. А вот если прочтение ничего не дало, тогда попросить гугл помочь: ок, гугл, настройка Bacula на CentOS. Думаю даст гораздо больше информации чем вы сможете получить тут. А если и это не помогло, почитайте о rsync, tar, cron думаю что за полчаса можно набросать bash скрипт который будет делать все что вам нужно без лишних телодвижений.

https://google.gik-team.com/?q=bacula centos 7 установка

Извините если не дал полного и ожидаемого ответа.

Начать с чтения документации, гуглится без проблем даже на русском.

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

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

Задача у меня стоит следующая: есть определённое количество директорий на серваке с геофизическими материалами, которые нужно бэкапить постоянно (по расписанию), т.к. в них находятся ОЧЕНЬ ВАЖНЫЕ МАТЕРИАЛЫ.

Присоединяюсь к советам о чтении документации :).

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

Я бы посоветовал Вам начать именно с продумывания общей архитектуры - куда именно Вы будете сливать данные (NAS, ленты, ленточная библиотека, раздел на СХД, что-то еще). Где будет размещаться база данных Bacula, как она будет резервироваться (кластер, репликация, просто сохранения дампа данных)? Нельзя размещать базу данных, управляющий модуль и хранилище на той машине, чьи данные резервируются.

Ну и так далее. Когда продумаете общую архитектуру бэкапного комплекса, смотрите документацию по поводу конфигурации каждого модуля. Там, в принципе, все довольно просто...

Да, и еще один немаловажный момент - когда определитесь с архитектурой, оцените время, которое Вам потребуется на восстановление системы, и сравните его с допустимым. Говорю потому, что у меня восстановление некоторых машин занимало десятки часов (c NAS по каналу в 100 Mb).

Бакула теперь за деньги. Смотри в сторону bareos.

Нельзя размещать базу данных, управляющий модуль и хранилище на той машине, чьи данные резервируются.

Можно, у меня именно так и сделано. Конечно, если свободных машин у тебя завались, то лучше так не делать.

Из тех кто еще не восстанавливал?

Восстанавливал, не понял а какие проблемы? У меня есть разработанный план дизастер рековери, я же не совсем лох.

Можно

Технически, конечно, можно. Только вот что будет, если именно эта машина и накроется? Например, блок питания, помирая, утащит за собой диски? С чего восстанавливать будете? Да и даже в том случае, если сам бекап у Вас на лентах, восстанавливать без базы данных - то еще удовольствие...

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

Так сам каталог тоже пишут на ленты. Короче учи матчасть как сделать сидюк для восстановление на bare metal. И как достать каталог с ленты.

Восстанавливали видимо при еще рабочем серваке. Впрочем вам выше более развернуто уже ответили.

Так сам каталог тоже пишут на ленты. Короче учи матчасть как сделать сидюк для восстановление на bare metal. И как достать каталог с ленты.

Я в курсе, как это делается ;). И в курсе насколько это усложняет процесс восстановления по сравнению с рабочей базой и директором ;). Не говоря уж о том, что я не зря в прошлом сообщении написал про пожар (потоп)/землетрясение - не знаю, как у Вас, а у меня был печальный опыт восстановления залитой стойки с серверами... Хорошо, бекап шел на машину в 40 км от пострадавшего дата-центра...

Я восстанавливал на голое железо, естественно сами данные были на лентах. Я же написал, что если есть возможность - на разные машины. Только кто такой богатый выделять по несколько серверов под бекап? Или у тебя дешевые писюки в качестве серверов?

естественно сами данные были на лентах.

А ленты как в безопасное место (за пределы дата-центра) доставляете? Руками?

Только кто такой богатый выделять по несколько серверов под бекап?

Есть очень эффективный и простой способ - договориться с дружественной организацией ;). Разворачиваем две бакулы - у себя и у них. И настраиваем перекрестный бекап - наша бакула резервирует их данные, их бакула - наши. Очень надежная и эффективная схема получается...

Или у тебя дешевые писюки в качестве серверов?

Вы знаете, схема с отдельным PC под бакулу будет куда надежнее Вашего решения «все в одном». Особенно, если этот PC вынесен за пределы дата-центра...

наша бакула резервирует их данные, их бакула - наши

Смешной ты какой-то. Кто тебе разрешит сливать коммерческую инфу на ленту чужому дяде?

PC не проработает и 5 лет. А у на есть сервера, которые работают с 2005 года.

PC не проработает и 5 лет.

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

Кто тебе разрешит сливать коммерческую инфу на ленту чужому дяде?

Я вроде написал про дружественную организацию? Это во-первых. А во-вторых, никто не мешает использовать шифрование при бекапе...

В бизнесе нет друзей. И тем более, что местный админчек вполне может все скопировать.

Я тоже думал над вопросом, что надежнее 2-3 пк или сервер с дублированными питанием, вентиляторами, дисками в массиве и прочими серверными примочками. Решил, что сервер надежнее.

В бизнесе нет друзей.

Ok, есть деловые партнеры. А еще есть конторы, объединенные в одну структуру (группы, холдинги и т. п.). Обычно такие конторы называют дружественными ;).

что местный админчек вполне может все скопировать.

Эх, не в том месте Ваша паранойя работает ;). С таким же успехом все может скопировать и Ваш местный админ... Надо уметь доверять людям, с которыми работаете. Ну и конечно, грамотно команду формировать...

Впрочем, см. выше про шифрование...

Я тоже думал над вопросом, что надежнее 2-3 пк или сервер с дублированными питанием, вентиляторами, дисками в массиве и прочими серверными примочками. Решил, что сервер надежнее.

Вы неправильно ставите вопрос. Отсюда и ошибка в результате. Сравнивать надо не надежность сервера с несколькими PC, а надежность системы в целом. В обсуждаемом случае это сравнение одного боевого сервера (система «все в одном», включая и бекап) и пары из того же сервера, и отдельного PC под бекап. В первом случае для возникновения серьезных проблем достаточно повреждения боевого сервера. Во втором случае должны одновременно произойти два события - сгореть и сервер, и PC. Очевидно, что вероятность такого исхода меньше, чем в первом варианте...

Надо уметь доверять людям, с которыми работаете. Ну и конечно, грамотно команду формировать...

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

просто отвезти кассеты в другое место и закрыть в сейф.

И делать это регулярно и ежедневно?

Понимаете, в любой системе человеческий фактор всегда является самым ненадежным.

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

Собственно говоря, вся автоматизация и придумана для того, чтобы сводить к минимуму человеческое участие в процессах.

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

размер файло-помойки колеблется от 300 - 500 Гб! Бэкапить думаю на другой жёсткий диск, который будет установлен на этом же сервере!!!! В случае выхода из строя СentOS либо самого железа (невозможно будет восстановить), я тупо переустанавливаю ось, на любой свободный в конторе комп (сервер) и подключаю диск с бэкапами и расшариваю через Samba, нужные директории! P/S: Я вот такую схему задумал!!!!!

думаю, что для этой цели тебе нахрен не надо никакой бакулы и достаточно простого rsync

подключаю диск с бэкапами и расшариваю через Samba

Что-то упущено в этой схеме

Бэкапы не будут простой копией файлов на файлопомойке, бакула пакует файлы в свои тома, которые расшаривать бесполезно.

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

А если честно, то я не понял откуда и куда должны бэкапиться файлы. Компьютеров два?

Дурацкая затея. А что будет если файл во время бекапа меняется? Бекап надо делать только с снапшота.

Надо уметь доверять

Надо уметь не доверять

Я решил остановиться на Bacule

Лучше пройди ещё чуть-чуть и остановись на нормальном решении. А не на говне мамонта, архитектура которого заточена на ленты. К тому же еще и конфигурация через жопная, там где в нормальной проге будут три строчки конфигурационных, в бакуле/бареосе поимеешь гемор.

Юзай современный софт короч.

Я вот такую схему задумал!!!!!

Схема крайне неудачная. Прежде всего потому, что выход из строя сервера может утянуть с собой и диск с бекапами (например, выход из строя блока питания, который перед тем как сдохнуть, подаст соответствующее напряжение на все компоненты сервера)...

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

Лучше пройди ещё чуть-чуть и остановись на нормальном решении. А не на говне мамонта, архитектура которого заточена на ленты.

Извините, но Вы полную чушь пишете. Бакула чрезвычайно гибкий инструмент и позволяет бекапить на самые разные носители, лентами там дело не ограничивается.

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

Бакула малость сложная, а случай у тебя простой. Поэтому советую посмотреть на rdiff-backup и rsnapshot или даже просто на rsync. С этими инструментами минимум проблем с восстановлением из бекапа.

rsync просто эффективно копирует данные, этого часто достаточно. Формат хранения - любая файловая система, включая виндовые. Восстановление тривиально.

rsnapshot делает снимки за разные даты, экономя место за счёт хранения неизменных файлов в виде хардлинков, а не копий. Формат хранения - юниксовая ФС. Восстановление тривиально.

rdiff-backup хранит снимки в виде сжатых файлов разницы, ещё сильнее экономя место. Формат хранения последнего снимка - любая фс, более старые снимки в своём формате.

Бэкапить думаю на другой жёсткий диск, который будет установлен на этом же сервере

Ну это вас спасет только от того случая, когда сдохнет диск с основной шарой. Даже если у вас там умерла ОС то можно тот же диск примонтировать в другую ОС и раздавать данные. В общем то, что вы планируете, это бэкап «для галочки». Как минимум выносите резервную копию на другой сервер (а с учетом того что в случае проблем вы и так переезжаете на другую машину - так разверните ее сразу, лейте туда бэкапы, и в случае проблем время переключения будет зависеть только от того, на сколько быстро вы доберетесь до консоли или патч-панели, ну или как вы там переключаетесь).

Алсо, у вас реально 500 гигов данных, к которым постоянно обращаются? Может стоит вообще пересмотреть сам принцип хранения и отдачи этой инфы?

Можно вместо bacula попробовать backuppc.

Она попроще бакулы, можно разместить её на одном сервере (веб-морда, БД, хранилище).

Работает через rsync,smb,scp,ftp.

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