LINUX.ORG.RU
ФорумAdmin

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

 


0

2

Интересует вопрос настройки резервного копирования на Linux-сервере под управлением CentOS. Сервак используется как файло-помойка юзверей, установлена Samba. Задача у меня стоит следующая: есть определённое количество директорий на серваке с геофизическими материалами, которые нужно бэкапить постоянно (по расписанию), т.к. в них находятся ОЧЕНЬ ВАЖНЫЕ МАТЕРИАЛЫ. Я решил остановиться на Bacule, для решения поставленной задачи, резервирования данных! Народ, может кто подскажет с чего начать, т.к. пока подробно не вникал в механизм рабыты БАКУЛЫ!?

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

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

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

yakunin ()

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

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

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

micronekodesu ★★ ()

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

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

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

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

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

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

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

Serge10 ★★★★★ ()

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

Bobby_ ()
Ответ на: комментарий от Serge10

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

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

Bobby_ ()
Ответ на: комментарий от anc

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

Bobby_ ()
Ответ на: комментарий от Bobby_

Можно

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

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

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

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

Bobby_ ()
Ответ на: комментарий от Bobby_

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

anc ★★★★★ ()
Ответ на: комментарий от Bobby_

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

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

Serge10 ★★★★★ ()
Ответ на: комментарий от anc

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

Bobby_ ()
Ответ на: комментарий от Bobby_

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

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

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

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

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

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

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

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

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

Bobby_ ()
Ответ на: комментарий от Bobby_

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

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

Serge10 ★★★★★ ()
Последнее исправление: Serge10 (всего исправлений: 1)
Ответ на: комментарий от Bobby_

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

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

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

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

Bobby_ ()
Ответ на: комментарий от Bobby_

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

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

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

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

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

Serge10 ★★★★★ ()
Ответ на: комментарий от Bobby_

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

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

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

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

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

Bobby_ ()
Ответ на: комментарий от Bobby_

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

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

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

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

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

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

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

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

crudos ()

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

targitaj ★★★★★ ()
Ответ на: комментарий от crudos

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

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

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

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

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

muon ★★★★ ()
Ответ на: комментарий от crudos

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

Bobby_ ()
Ответ на: комментарий от Serge10

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

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

af5 ★★★★★ ()

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

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

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

anonymous ()
Ответ на: комментарий от crudos

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

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

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

Serge10 ★★★★★ ()
Последнее исправление: Serge10 (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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

Serge10 ★★★★★ ()

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

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

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

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

legolegs ★★★★★ ()
Ответ на: комментарий от crudos

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

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

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

micronekodesu ★★ ()

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

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

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

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

Fess88 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.