cron + unison?

как я понимаю от rsync он ничем особым не отличается. Хотелось бы что-нибудь более продвинутое.

TimeMachine

А чем rsync не угодил?

использую flexbackup. Штука не самая лучшая/удобная, но вполне простая и достаточно (при должной аккуратности) надёжная. Не скажу, что рекомендую всем, но, возможно, кому-то понравится.

Особенность в том, что она НЕ использует каких-то специальных средств/форматов. Вместо этого делает find + стандартный архиватор (tar/cpio/etc) + стандартный компрессор (none/zip/bzip/lzop/etc).

В результате - плюсы и минусы.

Плюсы:

1. Можно гибко настроить, что надо архивировать, а что - нет (т.к. пользуется find'ом). Поддерживает "наборы" (sets) для архивации (скажем, можно сделать что-то типа system, home, media).

2. Распаковка из архива будет делаться именно теми средствами, которые ты выберешь для бакапа (я выбрал cpio + lzop). Если выбираешь tar + zip - то вообще не нужно ничего сверх того, что есть на стандартном линуксовом liveCD.

3. Все баги вполне предсказуемы ;-)

Минусы:

1. Хотя полный (full) бакап работает замечательно, бакапы типов incremental и differential (когда бакапится только то, что изменилось с предыдущего бакапа) работают не совсем так, как, вероятно, хотелось бы. А именно, сохраняются только новые и изменённые файлы. Если файл был удалён, то в incremental бакапе это никак не отразится (find не умеет находить, а tar - архивировать удалённые файлы), и при доставании из такого бакапа удалённый файл снова появится. Сам автор это комментирует примерно так: "лишние данные - не потеря данных, так что это не так страшно".

2. Я пользуюсь cpio, а в нём пока ещё есть один неприятный баг. Впрочем, workaround существует, и даже если ты о нём забудешь, данные из архива всё равно можно будет восстановить полностью. С tar тоже не всё замечательно.

3. Программа не обновляется уже лет 5, популярность у неё невелика.

4. (Уж не знаю, минус это или плюс) старые бакапы приходится удалять вручную.

К слову, мои 2 последних переезда на новые HDD были сделаны просто распаковкой системы из бакапа + настройкой fstab.

ЗЫ. Если я не ошибаюсь, rsync не умеет архивировать, а это не очень удобно.

Использую тулзу с опеннета. Вроде как fsbackup или что то в том духе. Очень приятная штука, и простая как угол дома.

Думаю, в твоём случае есть два базовых варианта.

1. полностью автономный. Копия часто/постоянно синхронизуется с основным диском. Почти ноль забот (не считая частых сканирований диска). При удалении файла (в т.ч. нечаянном) он автоматом вычищается из бакапа, и пиши пропало.

Вероятно, тут хорошо подойдёт что-то типа упомянутого выше rsync ежечасно по крону.

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

Это более "бакапоподобный" подход. Упомянутые выше flexbackup, fsbackup, но уже не ежечасно, а ежедневно, но так, чтобы была гарантия, что комп в это время не будет выключен (скажем, что-то типа cron.daily).

> Упомянутые выше flexbackup, fsbackup, но уже не ежечасно, а ежедневно, но так, чтобы была гарантия, что комп в это время не будет выключен (скажем, что-то типа cron.daily).

Use anacron, Luke!

> ЗЫ. Если я не ошибаюсь, rsync не умеет архивировать, а это не очень удобно.

Архив, IMHO, крайне неудобная штука. Ни grep -r, ни find на него не натравишь.
Так что это в некотором роде фича.

>но тогда всего одна копия остаётся без истории

rsync -a --link-dest=$DST-1 $SRC $DST-0
rm -rf $DST-$PARANOIA
for i in `seq $PARANOIA -1`
do
  mv $((i+1)) $i
done

PS: rsync -a --link-dest=

При желании можно использовать экспоненциальную паранойю, и/или удалять из устаревших бекапов только файлы с nlink > 1, а оставшиеся - на вшешние носители.

> Архив, IMHO, крайне неудобная штука. Ни grep -r, ни find на него не натравишь.

Не думаю, что в бакапах это надо делать часто. Если всё хорошо, то большинство бакапов вообще никогда не распаковываются. А если надо, никто не запрещает распаковать. Да и простой tar t |grep ещё никто не отменял.

Главное - не пытаться сжимать архив bzip'ом. Используй что-нибудь побыстрее. Например, lzop. Тогда в результате компресии обработка будет ускоряться (за счёт сокращения объёма ввода-вывода), а не замедляться.

Наконец, есть промежуточные варианты, типа squashfs :-) Почему-то о них никто всерьёз не написал.

Посмотри в сторону BackupPC, очень простая в настройке и использовании тулза... для руления веб-интерфейс...

использую сам на работе, проблем не было ниразу.

Поговорил со своей паранойей и если договорюсь с жабой, то склоняюсь покупке ещё одного диска и организации RAID-1 :)

anacron + GNU tar (ключик -g очень помогает).

> При желании можно использовать экспоненциальную паранойю, и/или удалять
> из устаревших бекапов только файлы с nlink > 1, а оставшиеся - на вшешние
> носители.

Лично я делаю копию каждый день и никогда не стираю их.

> Поговорил со своей паранойей и если договорюсь с жабой, то склоняюсь покупке
> ещё одного диска и организации RAID-1

IMHO, backup для личной машины всё же полезнее, чем RAID. Хотя если есть 2 RAID1
массива, тогда да. Но это сильно долго с жабой надо договариваться.

> IMHO, backup для личной машины всё же полезнее, чем RAID. Хотя если есть 2 RAID1 массива, тогда да. Но это сильно долго с жабой надо договариваться.

По поводу ленточного магнитофона и сейфа в другом конце города договариваться гораздо дольше придётся :)

> Не думаю, что в бакапах это надо делать часто.

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

> Да и простой tar t |grep ещё никто не отменял.

Интересно содержимое файлов, а не то, как они называются. Потому для того,
чтоб grep'нуть, всё равно придётся архив(ы) распаковать. Отсюда вопрос -- а
зачем вообще сжимать-то было?

http://www.jwz.org/doc/backups.html пути поправить по вкусу

RBackup http://rbackup.lescigales.org/ , RSnapshot http://www.rsnapshot.org/

Кнут использует backupfs http://sourceforge.net/projects/backupfs, судя по интервью http://www.webplanet.ru/interview/soft/2008/05/06/knuth.html Утилита в духе Plan9 venti/dumpfs, но она пару лет не развивается

> Отсюда вопрос -- а зачем вообще сжимать-то было?

Дык... места меньше занимает... У меня / занимает 10 Гб, а бакап на болванку влазит.

Делать grep по содержимому уже удалённых файлов мне как-то пока не приходилось. В таких случаях вполне можно распаковать нужную ветвь дерева.

Нынче рулят танковые клинья и ковровые бомбардировки. (C)

> Дык... места меньше занимает... У меня / занимает 10 Гб, а бакап на
> болванку влазит.

Нынче рулит disk 2 disk backup, потому это достоинство (IMHO) весьма
сомнительное.

Болванки

1. Легко (и быстро) портятся, теряются.
2. Процедура резервного копирования медленная и требует участия человека
(или дорогущего дополнительного оборудования для автоматической смены
болванок).
3. Поиск (нужной версии) нужного файла -- тот ещё геморрой, несмотря на
наличие разного вида софтин-каталогизаторов.

Вдобавок, цена (в рассчёте на Gb) не сильно-то и меньше, чем у жёстких дисков.
А у перезаписываемых болванок -- так ещё и больше.

> http://sourceforge.net/projects/backupfs

Тот же rsync с --link-dest.

hammerfs с миррорингом