бэкап домашней системы

[nadge]

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

Есть домашний комп. На нем среди прочего есть два тома lvm - монтируются в / и /home. Их (или их содержимое) надо (по отдельности) бэкапить. Бэкап / должен быть таким, чтобы удобно было восстановить систему после ее смерти. Бэкап /home - чтобы удобно было достать оттуда отдельный каталог.
Сам бэкап планируется хранить на другом (тоже lvm) разделе диска, а так же на другом компе. Возможно, еще и на флешке.
Очень желательно, чтобы бэкап хранился в сжатом виде.
Бэкапиться должны только изменившиеся файлы. Т.е. новая версия файла должна заменять в бэкапе старую (как в rsync, но про него ниже). Т.е. tar не подойдет.
Работать это должно быстро и чтобы у меня не создавалось ощущения, что утилита целенаправлено изнашивает мой диск.

Пробовал rsync + fusecompress, но это не работает. Он почему-то копирует некоторые (довольно много) файлы, которые точно не изменялись. Если же использовать --checksum, то все нормально, но очень уж долго. Да и обычные способ тоже долгий. Т.к. rsync сравнивает рекурсивно оба каталога (оригинальный и бэкап), а ведь можно инфу хранить в базе, что, похоже, было бы намного быстрее.


Вобщем, чето посоветуете?

[neol]

Использую для сабжа backupninja. Делает инкрементные копии средствами rdiff-backup. Получается компактненько, быстренько и удобненько (:

Кстати от системы сохраняется только содержимое /etc, ибо остальное не представляет совершенно никакой ценности, ИМХО.

[serzh-z]

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

[nadge]

Использую для сабжа backupninja. Делает инкрементные копии средствами rdiff-backup. Получается компактненько, быстренько и удобненько (:

Попробую.

Кстати от системы сохраняется только содержимое /etc, ибо остальное не представляет совершенно никакой ценности, ИМХО.

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

Но главное - не это, а каталог /home. Вот его регулярный бэкап необходим.

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

Ну, я в даный момент его использую...

[rm_]

Мне понравился для резервных разделов BTRFS со снапшотами. Делаю бэкап с помощью простого зеркалирования текущего состояния с помощью mirrordir, после чего создаю на разделе с бэкапом btrfs-снапшот того, что получилось. Удобство работы непревзойдённое, скорость создания бэкапа тоже на уровне (mirrordir пробегает все каталоги и устраняет в "слейве" любые несоответствия, btrfs-снапшоты делаются мгновенно). Снапшоты состояний каталога с бэкапом на разные даты выглядят как простые каталоги в ФС, можно ходить по ним, работать с любыми файлами без необходимости их предварительно распаковывать, или что-то подобное. Кстати, сжатие на уровне ФС поддерживается, и тоже - полностью прозрачно.

[serzh-z]

rm_
Увы-увы, баттерфс, надо полагать, уже никогда не оживёт. Если только кто-нибудь когда-нибудь не решит использовать некие идеи Btrfs в своей ФС...

[rm_]

serzh-z
а в котором месте по-вашему она "не жива"? УМ, как говорится, ВР.
btrfs давно в mainline, последние изменения - "Linux 2.6.37 released (January 2011) On-disk free space cache, asynchronous snapshots, unprivileged subvolume deletion, extent buffer switches from a rbtree with spinlocks to a radix tree with RCU. "
С рейзером4 не путаете?

[nadge]

Мне понравился для резервных разделов BTRFS со снапшотами.

Сам только что отформатировал в нее раздел под бэкап. Монтирую с -o compress (и парой еще для успорения) и делаю туда rsync с разделов / и /home (оба ext4). Скорость вроде как приемлемая. Возможно, на этом варианте остановлюсь.

Однако делать / и /home на нее как-то стремно пока... Но, тем не менее, если не трудно, раскажите подробнее, как и что Вы делаете.

[rm_]

Мне понравился для резервных разделов BTRFS со снапшотами.

Сам только что отформатировал в нее раздел под бэкап. Монтирую с -o compress (и парой еще для успорения) и делаю туда rsync с разделов / и /home (оба ext4). Скорость вроде как приемлемая. Возможно, на этом варианте остановлюсь.

Однако делать / и /home на нее как-то стремно пока... Но, тем не менее, если не трудно, раскажите подробнее, как и что Вы делаете.

Я не спорю - без работающего fsck (исправляющего ошибки, а не просто сжирающего всю память и печатающего разный забавный debug output) пользовать эту ФС для критичных данных страшновато. Но вот для бэкапов этих самых данных - то, что доктор прописал.

По поводу самого процесса.
На btrfs у меня есть subvolume под названием /backup/home/ (он нужен, т.к. снапшотить можно только subvolume'ы, а не любые папки).
Делаю примерно так:
1) монтируется btrfs
2) mirrordir /home/ /mnt/btrfs/backup/home/ (или в вашем варианте - rsync)
3) btrfs subvolume snapshot /mnt/btrfs/backup/home/ /mnt/btrfs/backup-ss/home-`date +тутдлинныйформатдатывремени`/
4) размонтируется btrfs.
В результате имеем на BTRFS-разделе в /backup/home/ состояние на момент окончания последнего бэкапа, а в /backup-ss/* - много снапшотов названных по дате-времени, с такими состояниями на моменты предыдущих бэкапов.
До кучи написан самодельный скрипт по вычищению старых снапшотов (с помощью btrfs subvolume delete <путь>).

[Nazyvaemykh]

если так нрвятся все преимущества нормальной файловой системы, может быть, стоит поставить на ту машику, что хранит бекапы, FreeBSD + ZFS?
Или трбования к ней использовать FreeBSD не позволяют?

[rm_]

Nazyvaemykh
*BSD меня не интересует в принципе (не в последнюю очередь из-за лицензии), я её не знаю и не хочу знать.
btrfs для обозначенного сценария использования более чем "нормальна".

[nadge]

Я не спорю - без работающего fsck (исправляющего ошибки, а не просто сжирающего всю память и печатающего разный забавный debug output) пользовать эту ФС для критичных данных страшновато. Но вот для бэкапов этих самых данных - то, что доктор прописал.

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

По поводу самого процесса.

Благодарю за пояснение.

Или трбования к ней использовать FreeBSD не позволяют?

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


Вобщем, остановился на варианте с разделом btrfs с компрессией, на который делается rsync. Скорость маловата, но в остальном устраивает.

[serzh-z]

btrfs давно в mainline, последние изменения - "Linux 2.6.37 released (January 2011)

Как интересно... Может я и не прав. Но вообще, ФС, которая до сих пор ещё не зарелизена, которая не имеет fsck и не умеет выполнять _базовые_ операции, в адрес которой разработчики ядра (в том числе один из разработчиков reiserfs4) пишут в LKML очень критические замечания (навроде "ребята, разрабатывающие btrfs, некомпетентны в теории построения файловых систем"), сложно назвать живой.

[neol]

Вот это серьезно. Вот это по-мужски! Заюзать под резервные копии полудохлую ФС без инструментов проверки и восстановления, чтобы в самый неподходящий момент выковыривать из нее данные с помощью бубна и энтой матери. Да сам Чак Норрис не отважится на такое!

[Ленивая Бестолочь]

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

[rm_]

Как интересно... Может я и не прав. Но вообще, ФС, которая до сих пор ещё не зарелизена

В том-то и дело, что "ещё" незарелизена, в отличие от упомянутых вами рейзеров, которые вполне возможно уже незарелизены.

не умеет выполнять _базовые_ операции

А это какие например?

один из разработчиков reiserfs4) пишут в LKML очень критические замечания (навроде "ребята, разрабатывающие btrfs, некомпетентны в теории построения файловых систем")

Угу, а тем временем кто-то уже в майнлайне, а кто-то сидит и злобно грызёт локти, поплёвывая ядом в LKML. :P

на который делается rsync. Скорость маловата, но в остальном устраивает.

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

[drBatty]

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

ИМХО это потому, что для сабжа достаточно простого скрипта.

Т.е. tar не подойдет.

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

[nadge]

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

rsync по дефолту так же делает... Но попробую mirrordir, спасибо.