бэкапы через снапшоты

rsnapshot?

Спасибо, интересная штука. А применялась ли оно на больших массивах данных? Террабайты, миллионы файлов...

Если я правильно понял задачу, то rdiff-backup.
>rdiff-backup stores incremental rdiff deltas with the backup, with which it is possible to recreate any backup point.

Не, инкремент это не то. Со временем всё равно придётся полный делать т.к. инкрементов будет слишком много.

А LVM снапшот это разве не тот же самый diff на уровне блоков?

да, типа того. Есть какие-либо идеи? Сразу скажу что инкрементальные бэкапы отстой(потому как со временем всё равно придётся делать новый фулл или же хранить все инкременты).

Интересуют именно "декрементальные" бэкапы когда самые старые "декременты"(слово-то какое) можно удалить без ущерба самым новым бэкапам.

rsnapshot пока работает нормально, буду скоро в продакшене пробывать. В сочетании с xfs_fsr(дефрагментатор), надеюсь, разберусь со всеми бэкапами раз и навсегда :).

Нашёл интересный доклад на тему LVM-а http://mbroz.fedorapeople.org/talks/LinuxWeek2007/lvm-openweek2007.pdf

Помимо прочего упоминаются multiple и writable снапшоты. Внимательно не читал, но может поможет чем-то. На днях сам попробую сабж исполнить =)

Спасибо, почитал. В общем, от lvm в итоге отказался. Нет времени проверять исправили ли "multiple snapshots of the same LV = huge performance loss" и очень не хочется всё переформатировать и переразбивать.

>Нет времени проверять исправили ли "multiple snapshots of the same LV = huge performance loss"

А как это исправить? По сути, это те же самые инкрементные бекапы.
Много инкрементов ⇒ много времени собрать из них нормальный файл или каталог.

> А как это исправить?

https://www.redhat.com/archives/dm-devel/2006-October/msg00034.html

>When origin gets modified, instead of copying the chunk to all snapshots, it gets copied to the most recent snapshot's cow device only

Ндааа. Есть что исправлять.
Но это касается тормозов при записи. Полагаю, при изначально нормальной архитектуре таких косяков вообще бы не было.

Что касается скорости чтения, на нее это никак повлиять не должно — все та же сборка файл = оригинал + инкремент1 + инкремент2 + ... Я об этом говорил.

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

лень выковыривать и в граф редактор ставить, просто скажи - в твоём аватаре есть водяные знаки? :)

>Кроме того место под снапшот статически аллоцируется.

Вот это — действительно серьезный аргумент.

лень выковыривать и в граф редактор ставить, просто скажи - в твоём аватаре есть водяные знаки? :)

Не знаю. Все в вопросы — к автору.

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

В общем, вместо всяких бакул теперь буду использовать ЭТО :)

ЭТО == rsnapshot?

А чтобы можно было достать бэкапы за предыдущие дни каждый день тупо делать по снапшоту.

Быкапы на основе снапшотов имеет смысл делать только если файловая система находится в непротиворечивом состоянии в_любой_момент_времени.

LVM2 не может гарантировать непротиворечивость ФС в любой момент времени (в отличие от GEOM/UFS2 и ZFS), так как не умеет работать с барьерами при записи на нескольких физических томах.

Да. На самом деле это обёртка над rsync.

iZEN, спасибо что заглянул на огонёк :). xfs_freeze -f надо вызвать перед тем как снапшот делать. Потом -u для unfreeze. Только это не решает проблему консистентности БД. Тут уже приходится использовать локи или же (постргрес умеет) встроенные фичи БД.

А ещё xfs дефрагментацию умеет делать. Только почему-то это у меня не работало для уже открытых файлов. Оно что-то делает-делает а толку ноль.