Re: Backup system
On Sun, Jan 23, 2005 at 11:26:15PM +0300, Artem Chuprina wrote:
> DVI> Маленькое замечание по поводу инкрементальных backup (что-то вроде теста
> DVI> для системы отбора файлов). Допустим, что корень нашего backup ==
> DVI> /dir/root, и также допустим, что у нас есть два каталога
> DVI> /dir/root/testdir и /some/other/dir/testdir. Предположим, что мы сделали
> DVI> полный backup с /dir/root, после чего был удален /dir/root/testdir и на
> DVI> его место перемещен /some/other/dir/testdir. Все указываемые каталоги
> DVI> находятся по условию задачки конечно в пределах одной fs. Backup с
> DVI> нормальным алгоритмом должен сделать полную копию /dir/root/testdir со
> DVI> всеми подкаталогами (я думаю понятно почему).
>
> Стоп. Бэкап _файловой системы_ (с дополнительным требованием сохранять
> иноды) - да. Бэкап _данных_ имеет полное право (и я бы настаивал, чтобы
> он при возможности так и делал) отследить действительную разницу в
> _данных_, и если данные одинаковые, не тащить их. Он на то и
> incremental.
Тут понимаете какая штука: нужно ведь не только данные сохранять, но и
структуру тоже. И к тому же еще и старый хлам уметь удалять (то, что
пользователь стер с момента предыдущего backup-а). К тому же никто не
говорил, что данные в /dir/root/testdir и /some/other/dir/testdir
одинаковые. В этом-то и фокус, что это разные каталоги просто с
одинаковым названием.
>
> А условия "данные с прошлого бэкапа недоступны" ты не ставил... И
> правильно делал - slbackup, насколько я могу понять, работает именно в
> режиме доступа к данным прошлого бэкапа (он rdiff использует).
С прошлого backup-а нам понадобятся данные по каталогам (они в snapshoot
file пишутся у GNU tar например). Точно нужны inode number и полное имя.
Насчет ctime и mtime с ходу не помню (и так задержал с ответом, прошу
прощения), попробую пожалуй описать своё видение задачи позже (надо
сформулировать как-то попонятнее, давно я уже этим интересовался).
WBR
Dmitri Ivanov
Reply to: