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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
