Назад | Перейти на главную страницу

инкрементное резервное копирование tar выполняет резервное копирование всего, каждый раз, когда используется в каталоге Dropbox

Около 10 месяцев назад (27 января 2013 г.) я сделал инкрементную резервную копию, создав файл метаданных .snar. Теперь, когда я пытаюсь сделать инкрементную резервную копию, используя

tar --create --file=dropbox_incremental_1.tar --listed-incremental=dropbox_0.snar Dropbox

команда просто выполняет повторное резервное копирование всего.

Я не являюсь экспертом в области временных меток Unix, но я заметил, что практически все мои временные метки в моем каталоге намного старше, чем когда они менялись в последний раз. Для моих настоящих файлов они выглядят так:

Access: 2013-03-12 19:04:51.000000000 -0500
Modify: 2012-09-30 15:10:47.000000000 -0500
Change: 2013-03-12 19:04:51.306209672 -0500

Временная метка «Изменить» кажется правильной, но файлы определенно не были изменены (по крайней мере, я не делал ничего, о чем я знаю) в то время, когда они утверждали, что это было. Эти файлы все еще попадают в инкрементный архив.

Что тут происходит? Есть ли способ сказать tar, чтобы он смотрел на временную метку «изменить»? Разве это не то, что он должен делать?

В конечном итоге я не смог найти способ получить инкрементальную работу с Dropbox. Я предполагаю, как сказал Вениамин, tar смотрит и на ctime, и на mtime. Dropbox должен делать что-то, что касается ctime, поэтому он просто вызывает резервное копирование всего архива при каждом запуске.

Вместо этого я просто сделал tar --create --file mybackup.tar --newer-mtime = "26 января 2013 г." Dropbox

Хотя это не так гладко, как инкрементное резервное копирование, я доволен им, поскольку он должен получить все файлы, которые были изменены (на основе mtime) с момента моего последнего резервного копирования. В этом случае эта резервная копия является третьей резервной копией, поэтому, если что-то случится там, где я доберусь до этой, я буду счастлив просто иметь файлы, и работа с не совсем гладкой системой будет в порядке.

Спасибо за ответы.

Тар действительно выглядит mtime. Но он также должен выглядеть ctime, поскольку он обрабатывает метаданные файла (например, разрешения).

Я предполагаю, что ваше приложение Dropbox использует ctime для своих собственных целей, и вы ничего не можете с ним поделать.

UPD:

Вы можете использовать опцию обновления -u вместо инкрементного режима. Кажется, что все равно ctime.

Вы не упомянули тип файловой системы / устройства, но можете попробовать:

$ tar --create --no-check-device --file=dropbox_incremental_1.tar --listed-incremental=dropbox_0.snar Dropbox

Также см Исправление файлов снимков.