[Uneex] Средство " интеллегентного бэкапа "

[Yuri Ryazantsev]

Nikita V. Youshchenko wrote:

>>- ведение backup и логов;
> 
> 
> Ну раз уж всплыла тема, спрошу :).
> Не знает ли кто *готового решения* для такой задачи.
> 
> Есть сервер, на котором работают пользователи (через графические терминалы, 
> удалённо по ssh и т.п.). Наш zigzag.
> На сервере лежат домашние каталоги. Сейчас раздел на 200G, возможно вскоре 
> будет увеличено в 2-3 раза.
> У пользователей в домашних каталогах - помойка: не стёртая вовремя 
> мультимудия, развёрнутые архивы исходников крупных проектов, да ещё с 
> объектниками, и т.п.
> Но среди этого встречаются и нужные вещи (текущая работа по проектам и 
> т.п.). Т.е. нечто, что нужно бэкапить.
> 
> Бэкапить всё не представляется возможным из-за объёмов. Да и глупо это 
> как-то, так как 90% объёма - помойка.
> Заставить пользователей явно отметить, что надо бэкапить, тоже в общем 
> случае проблематично, т.к. это пользователи :).
> 
> Требуется система, которая с (как-то организованной) минимальной помощью 
> админа обеспечивала incremental backup ценной информации из домашних 
> каталогов, и возможности восстановления некоторого количества прошлых 
> версий (речь идёт не о полном хранении истории ala cvs, а что-то вроде 
> вчерашний, недельной давности, месячной давности)
> Я думал на эту тему, получается примерно следующее.
> Нужна процедура, которая будет определять, что есть "ценное".
> - некоторый разумный критерий по содержимому файлов (по magic естественно, 
> не по имени)
> - эти правила перекрываются на уровне отдельных каталогов продвинутыми 
> пользователями
> - чтобы в бэкап не попадал очередной развёрнутый пользователем архив 
> исходников linux, система должна находить каталоги размера /с учётом 
> exclude-ов/ больше критического, которых "вчера не было", и автоматически 
> исключать их из обработки, с уведомлением админа, который сможет 
> просмотреть, что это за каталог появился, и вручную задать, что с ним 
> делать. Админ соответственно утром получает письмо с результатом ночного 
> прогона, и заносит новые правила. Раз в день несколько минут - по-моему 
> совсем не страшно.
> - "растолстевшие за день" каталоги - аналогично
> - ещё наверное что-то
> На основании этих правил создаётся список для бэкапа, и осуществляется 
> бэкап (на другой раздел, по сети, ...). К этому добавляются какие-то 
> средства устаревания бэкапов, ну и естественно просмотра доступных бэкапов 
> и восстановления на уровне отдельных каталогов и файлов.
> 
> Т.е. представление о том, что надо - есть. Ясное дело, что это эвристика, 
> когда-то будет и лишнее бэкапить, и нужное не находить; но тем не менее 
> мне кажется что в среднем должно работать неплохо.
> 
> Но писать всё это - целая история. Пытался в прошлом полугодии студента 
> посадить, но как-то у нас с ним не наладилось взаимодействие, и ничего не 
> вышло :(.
> 
> Готовое решение когда-то искал, неудачно. Создалось впечатления, что в 
> такой постановке задачу никто никогда не решал.
> 
> Может, кто-нибудь меня во что-нибудь ткнёт?

Раздели на две задачи:
- составление списка файлов для backup$
- собственно backup;

С второй задачей успешно и cpio справится, а для первой слишком 
много эвристики и "надуманности", что проще делать через набор 
скриптов отсекая каждым последующим лишнее.

Про ведение backup'ов есть множество алгоритмов. Для начала можно 
посмотреть на книжку ( хоть и старая но может помочь): 
http://www.oreilly.com/catalog/unixbr/index.html

Но IMHO, это пример поощрения оставления непродуманной организации 
работы в виде "как есть" и прикрытия себя в случае проблем с 
потерей данных. :-)) Особенно вдохновило: 200 Гб -> 90% помойка -> 
"возможно вскоре будет увеличено в 2-3 раза"

-- 
Yuri Ryazantsev <yuri на unix.ru>    | RIPE: YR1-RIPE
UNIX System Network Administrator | RIPN: YAR1-RIPN