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

В связи с этим разыскивается какая-то другая система бэкапов. Нужно:

• Уметь полные и incremental бэкапы.
• Удалять старые инкременты (старее N дней, либо хранить M последних инкрементов)
• Очень жалательно, чтобы последний бэкап был в виде обычной копии FS (как в rdiff-backup), чтобы в случае чего осталось хоть последний снэпшот.
• Желательно что-то не enterprise-уровня, т.е. без (или с выключаемыми) вебмордами, dedicated демонами и подобным. Короче чем проще тем лучше.
• Нужно наличие какого-то fsck или другой тулзы для проверки целостности и желательно восстановления (хотя бы удалить покоцаный по каким-то причинам снапшот).
• GUI нафиг не нужен.

Типичный workflow: воткнул сторедж по E-SATA/USB, запустил на ночь, утром всё забэкаплено. Бэкапится около 200 гигов инфы (включая фотки и достаточно большие мувики), инкремент раз в неделю, хранится 6 бэкапов.

Есть сейчас что подобное?

Сегодня утром врубил ноут после ношения его в рюкзаке. BIOS выдал стандартную ошибку, типа не с чего грузиться, вставьте что-то загрузочное и нажмите клавишу. Залез в Setup, винта оттуда не видно. Только сидюк.

Первая мысль — бэкап слава богу есть, даже относительно свежей.

Раскрутил отсек для винта. А винт там лежит с зазором пол сантиметра от края. И вот как раз на эти пол сантиметра он выскочил из разъемов. Аккуратно задвинул его на место, впихнул в зазор пенопласта. Включил — полет нормальный.

Я тут подумал, чем лучше всего архивировать файлы для бэкапов.. Труъ UNIX way в виде tar.(gz|bz2) мне не очень нравится, потому что, в случае повреждения архива, вытянуть что-то за местом повреждения практически нереально. Архиватор должен обязательно уметь сохранять UNIX права доступа, поддерживать симлинки.

aufs — «наследник» unionfs. Позволяет на лету обьединять несколько файловых систем в одну. Я уже достаточно давно подумываю применить это к созданию инкрементальных бэкапов.

Идея заключается в том, что можно создать первый (полный) бэкап всего раздела. Затем можно тем же LVM-ом заблокировать раздел от дальнейших изменений. Дальше монтируется aufs с двумя бранчами:

• read-only — содержит уже забэкапленные данные;
• read-write — сюда будут сохраняться новые данные

Таким образом для создания первого инкрементального бэкапа достаточно забэкапить «read-write» бранч. Дальше нужно как-то обьеденить эти два бранча.. Все изменения нужно как-то перенести в «read-only» бранч, чтобы не бэкапить их еще раз. Вот как это сделать простым методом я пока что не совсем себе представляю..

Для созданных/измененных файлов достаточно просто передвинуть эти файлы с заменой. А вот удаленные файлы нужно обрабатывать как-то сложней. В read-write бранче уделение файла «somefile.txt» сохраняется в виде создания файла «.wh.somefile.txt». По идее можно поискать все файлы, которые начинаются с префикса «.wh.» и удалить соответствующие им файлы в read-only бранче… Но не хотелось бы пользоваться такими вот грязными хаками. Плюс не факт, что такой способ хранения останется в следующих версиях aufs.

Спросил в рассылке aufs-users@. Может что посоветуют.

Сам aufs должен быть достаточно ровным. Куча всяких LiveCD его используют. Я попробовал положить в read-only бранч исходник linux-2.6.26 и собрать его на read-write бранче. Ядр собралось (make -j 4) и даже загружается…

Хочется иметь нормальный способ создания бэкапов. В частности под нормальным способом я понимаю:

• Создание полных бэкапов и инкрементальных;
• CD/DVD в качестве носителей;
• Как можно проще. Клиент-серверное не нужно. Command-line или в крайнем случае ncurses. Запустил скрипт (руками или из крона), в определенный каталог положился файл (файлы). На почту прислалось уведомледние, что нужно записать файлы на носители;
• Возможность посмотреть, что будет забэкаплено в инкрементальном бэкапе и влиять на это, например сказать, а вот этот файл засовывать в инкрементальный бэкап не нужно, потому что он весит 10 гиг и потерять в принципе не жалко;
• Сохранять информацию про удаление файлов. То есть, например, если на в полном бэкапе файл был, а к следующему инкрементальному бэкапу этот файл удалили, то распаковывание полного бэкапа и накатывание поверх него инкрементального, файл должен удалиться;
• Стандартный формат файлов бэкапа, например tar.gz/tar.bz2. И, как минимум, в случае потери одного из инкрементальных бэкапов (например не читается болванка), нужно иметь возможность востанавливать данные из последующих;
• Желательно уметь делать xdelta для некоторых достаточно больших файлов (например образы HDD VirtualBox-а);
• Желательно иметь возможность обьяснить, что определенные файлы нужно бэкапить не так часто, как остальные.

Сейчас я периодически руками запускаю tar с ключем —after-date, но это не совсем удобно. По apt-cache search incremental backup ничего подходящего не вижу.