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

http://www.google.ru/search?q=rsync+incremental+backup

хотелось бы конкретные решения услышать, кто что использовал.

сам я сейчас использую rdiff-backup но как-то он мне поднадоел :)

лет 8 лет назад юзал самописный перловый скрипт, который посредством find && tar и прочего делал бэкапы и по scp загонял их на удаленный сервак. сейчас бы, если бы возникла необходимость, смотрел бы в сторону rsync.

Говорят, bacula крайне неплоха.

http://ru.wikipedia.org/wiki/Bacula

Для десктопа али сервера? Если для десктопа, то sbackup.

для сервера.

Из личного опыта - bontmia + небольшие правки (вместо иерархии одни уровень).

http://www.linux.org.ru/wiki/en/bacula

http://www.opennet.ru/dev/fsbackup/

Не?

Внезапно! IBM Tivoli, HP Data Protector, Bacula.. Не? Самописных решений так и вовсе вагоны..

ZFS incremental snapshots send/recieve?

Я бэкаплю с помощью немного заскриптованного rdiff-backup целыми блочными устройствами, но на уровне ФС, с созданием LVM-снэпшотов, где это возможно. http://blogs.ungrund.org/xio/2009/02/21/rdiff-backup-automation/

rsync же

cron + tar + bash

Git

=)

>сам я сейчас использую rdiff-backup но как-то он мне поднадоел :)

а чем именно поднадоел? а то я тоже озадачился этим вопросом и собирался использовать именно rdiff-backup :)

Периодически (версионно) бэкаплю боевой сервер через unison/sshfs. Объём бэкапа что-то под 50Гб и тысяч 200 файлов.

Здоровская аватара, mate.

> лет 8 лет назад юзал самописный перловый скрипт, который посредством find && tar и прочего делал бэкапы и по scp загонял их на удаленный сервак.

Gnu tar умеет делать инкрементальные бакапы. У него в документации написано как.

> сейчас бы, если бы возникла необходимость, смотрел бы в сторону rsync.

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

Делал GNU tar (полный + инкрементальный бакап) + ssh. Причем авторизация по ключам. Т.е сервер бакапа инициирует процесс, заходя с нужным ключем (для полного или инкрементального бакапа). На сервере, который бакапиться для соответствующего ключа прописана команда, которая запуститься (соответствующий tar полный или инкрементальный). Этот пользователь UID=0, но авторизоваться можно только по ключам, а для них прописаны конкретные команды (т.е. shell не получишь). Таким образом что тарить, а что исключать из бакапа прописано на сервере, который бакапим. Восстановление делается вручную.

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

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

кстати, а как насчет использования VCS для бэкапа? :)

Я никогда не использовал VCS для бэкапа.

А из нее получиться удалить данные старше недели, например?

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

> А из нее получиться удалить данные старше недели, например?

я думаю можно.

> Иначе сложно сделать так, чтобы после взлома рабочей машины еще и бакапы не испортили

ну можно же откатить изменения :) хотя таки да, VCS - это довольно избыточно для бэкапа будет.

>> Недостатки - восстановление из бакапа

А ведь основная цель с которой делается бэкап - это безгеморно восстановить данные в случае если что. Причём практика показывает, что это 'если что' таки случается.

А ты восстанавливал данные из своего бэкапа??!

Доставал. Раз в месяц можно и руками растарить данные из бакапа и передать по scp.

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