Тряси бюджет

А от чего хотите защититься? Есть сценарии? Отказ одного из НЖМД в массиве, случайное удаление файла, нужен файл годовой давности, маски-шоу с изъятием техники?

Из сценариев вытекают все требования, а из них решение и требуемый бюджет.

backup

для ext* - dump/restore, для даты zfs send/receive инкременты без проблем

Вот у меня бекап сервер с ext* fs

Я на него по сети кидаю dump с ext* в файл blahblah_ext3.dump

и файл с zfs send --- blahblah_zfs_sent.dump

Если надо восстановить один файл то из blahblah_ext3.dump можно и листинг содержимого получить командой restore и собственно любой файл достать.

А как с blahblah_zfs_sent.dump без машины с zfs работать?

Если никак, то это говно-blob'ы какие-то

Спасибо за ответы. Собственно фирма занимается в основном веб-разработкой, есть программисты на c#, бухгалтеры и менеджеры. Мне надо будет делать бекапы домашних директорий, потому как серверной частью я еще не занимаюсь. Стратегии нет, срок хранения - 1 месяц. Про дамп ext честно говоря не понял

Если сорцы и домашние папки, то не помешает SVN.

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

Надо плясать от технических возможностей. Смотри что тебе дадут для бекапа. Врядли ты как начинающий сможешь УСПЕШНО попросить/потребовать слишком много. Скорее всего получишь серверок с дисками и дальше крутись как можешь. Только зачем мне гадать? Пиши еще.

bareos. Всякие tar/rsync - для клиентов не очень. Ибо последние, часто бывают не всегда доступны, и т.д. - В общем следить надо, а чтобы следить - надо настроить уведомления, а чтобы их настроить, надо прикрутить более или менее удобное управление расписанием, e-mail и т.д. - в конечном счёте получится тот же bareos.

dd

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

А как с blahblah_zfs_sent.dump без машины с zfs работать?
Если никак, то это говно-blob'ы какие-то

А как с blahblah_ext3.dump без машины с ext* работать?

Если никак, то это говно-blob'ы какие-то

bareos. Всякие tar/rsync - для клиентов не очень. Ибо последние, часто бывают не всегда доступны

Me Округлил глаза, да шо ви говорите... tar «часто бывает не доступен» , это он вам сам рассказал?
А «bareos» ну просто на каждом углу валяется, это вам видимо уже «bareos» рассказал.

надо прикрутить более или менее удобное управление расписанием

Ну канечно, крон уже не канает, да? Это тоже «bareos» рассказал ?

e-mail

Крон и команда mail просто со страху попрятались перед «bareos»
Ерунду не пишите.

Me Округлил глаза, да шо ви говорите... tar «часто бывает не доступен»

Я имел ввиду клиентские компьютеры которые нужно резервировать а не сраный tar.

Ну канечно, крон уже не канает, да? Это тоже «bareos» рассказал ?

Если бы ты научился разувать глаза, то увидел бы, что про cron+mail, я уже писал. А потом написал, что связка из tar+cron+mail=bareos

man restore, клоун

я же написал при помощи restore можно получить и полный листинг файлов и вытащить любые файлы.

blahblah_ext3.dump не обязан лежать на ext*

Слился, сынок?

без машины с zfs работать?

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

Чтобы вытянуть файл из дампа надо развернуть zfs, выделить диск, накатит дамп, вытащить файл и все удалить? блоб он и есть блоб, работать с ним не удобно.

вместо одной команды restore ... ext3.dump ... filename_to_restore

ext4, zfs... Вы о чем, мужики? ТС нужно будет бекапить ntfs, почему то я уверен в этом, несмотря на

в основном центос/сузя на клиентах

ТС нужно будет бекапить ntfs

ТС нужно будет бекапить ФАЙЛЫ из хомяков юзеров --- куда-то (на ext4/xfs)

на zfs можно держать любую ФС поверх zvol

Это хорошее замечание. Но забей, я имел ввиду другое.

bacula/bareos

По выходным полный бекап, ежедневно инкрементный или диф.

Я имел ввиду клиентские компьютеры которые нужно резервировать а не сраный tar.

Простите, не так понял. С этим согласен.

А потом написал, что связка из tar+cron+mail=bareos

Нууу не совсем так. bareos в себя включает все-таки побольше чем tar+mail+cron. Я же говорил о том что зачастую обычной связки rsync,tar,mail,cron более чем достаточно и доп. инструментов не требуется.

Ну смотри, мало того, что с bareos, возможно получить вменяемый gui для руления backup. Ещё его можно скрестить с zabbix. Ещё им можно делать backup субд, и backup Windows машин при помощи vss. Так же, без особых заморочек можно получить очень, очень, очень гибкое расписание backup. Virtual full backup. Без особых костылей, можно сливать backup каждый день в разные места. Ну и весьма не плохая штука, когда клиент тебе не доверяет, и может подписать всю дату сливаемую к тебе приватным ключиком. И без оного, ничего не вытянуть с сервера baсkup обратно. А ещё, одним пинком, можно включить сжатие на стороне клиента. Я не утверждаю, что bareos нужен всем. Но я уже попробовал делать backup рабочих станций через tar,rdiff-backup и т.д. - всё это не то... То скрипт зависнет, то не отмонтируется чего-нибудь. То вообще встанет по не понятной причине - ведь даже простой скрипт нужно прологировать хорошенько. Или tar какой-нибудь как споткнётся на что-нибудь, так и забудет всё на свете...

Как-то так... Всё зависит от масштабов. Для двух рабочих мест, bareos, не имеет смысла, конечно. :)

Ну я как бэ о том же написал. «bareos в себя включает все-таки побольше чем tar+mail+cron» :)
Хотел только подвести к тому, что для разных задач есть разные «пушки», где-то и вполне «tar+mail+cron» а где-то нужно больше сервисов, которые можно или самому настраивать/костылить или «взять из каробки».
ЗЫ Вот пример перед глазами, сервер(лезвие один штук) субд+аппликухи на нем, заказчик предоставил только ресурс который можно смонтировать, ну и чего я буду выпендриваться, создали бэкап, залили, себе любимому отчет прислали, а уж чем он(заказчик) там дальше рулит мне все равно. Не буду же я ради такой задачи контейнер/виртуалку поднимать.

ЗЫ Вот пример перед глазами, сервер

в данной ситуации всё ок. ТС сказал про рабочие места... По сему, я и сказал, что tar и производные не всегда хороши для этого. Да чего уж греха таить: bareos, тоже не идеальна, но наверно лучше чем скрипты, особенно, если машин более чем 5.

Собственно фирма занимается в основном веб-разработкой

Загоняй прогеров в VCS. На своих машинах пусть творят что хотят, а девел/прод бэкапь полностью чем-нибудь типа бакулы.

Базы, если есть — предварительный дамп в текстовый вид, желательно в виде данные-в-csv+sql-схемы, а не тупо sql-via-insert.

извиняюсь народ, я думал никто больше не ответить, а тут вовсю идет дисскусия:) Спасибо всем за ответы. Честно говоря бакула шокировала своей настройкой, наверно несмотря на все хвалебные отзывы оставлю ее. Смотрю в сторону duplicity или вручную rsync - ищу хорошие примеры. Если на питоне писать - тоже наверняка тар или rsync. Для svn делается бекап сервера, мне это пока не надо. Всем спасибо за ответы