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

Question

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, чтобы он посмотрел на временную метку 'modify'? Разве это не то, что он должен делать?

4

backup tar incremental-backup dropbox

Источник

Cyclic 08 ноя '13 в 03:48

3 ответа

Другие вопросы по тегам backup tar incremental-backup dropbox

rickhg12hs 08 ноя '13 в 08:55 2013-11-08 08:55 · Answer 1 · 2013-11-08 08:55

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

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

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

0

Источник

rickhg12hs 08 ноя '13 в 08:55

Veniamin 08 ноя '13 в 09:46 2013-11-08 09:46 · Answer 2 · 2013-11-08 09:46

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

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

UPD:

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

Cyclic 09 ноя '13 в 23:16 2013-11-09 23:16 · Answer 3 · 2013-11-09 23:16

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

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

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

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