Вывод restic version

restic 0.8.2

Как именно вы пробежали рестик?

% restic -r /tmp/restictest backup $SSHFSMOUNT/directory

Каталог резервных копий - это смонтированная файловая система sshfs.
Команда запускается несколько раз, чтобы сделать несколько снимков.
В большинстве случаев в удаленном каталоге хранится огромный объем данных (1 ТБ +).

Какой бэкэнд / сервер / сервис вы использовали для хранения репозитория?

Локальная файловая система ext4.

Ожидаемое поведение

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

Фактическое поведение

Все резервные копии занимают часы (если не дни), даже если файлы не изменились.

Шаги по воспроизведению поведения

• запустить резервную копию
• размонтировать файловую систему sshfs
• перемонтировать файловую систему sshfs
• запустить новую резервную копию

Он не воспроизводится на 100%, но даже с небольшим объемом данных я смог его воспроизвести.

Журналы сервера SFTP показывают, что файлы полностью извлекаются, даже если они не менялись.

Вы знаете, чем это могло быть вызвано?

Да: restic сравнивает индексные дескрипторы, чтобы дважды проверить, были ли файлы изменены (отладочное сообщение «временная метка, размер или индексный дескриптор изменен», restic/node.go:551restic.(*Node).IsNewer11node ).

Однако inodes могут изменяться при монтировании файловой системы с помощью sshfs (и, возможно, в некоторых других файловых системах).

Есть идеи, как решить проблему?

Комментирование проверки inode решило проблему для меня.

Я хотел бы иметь способ отключить эту проверку; может флаг командной строки?

Рестик помог тебе или сделал тебя счастливым?

Конечно, это хорошая программа! Я тем более доволен, так как нашел обходной путь ...
Продолжайте хорошую работу!