Restic: Медленно, хотя просто проверяет временные метки

Созданный на 17 февр. 2016 · 5Комментарии · Источник: restic/restic

У меня есть 164809 файлов для регулярного резервного копирования (около 60 ГБ) ... Каждый раз, когда я запускаю «restic backup», отчет не выходит за пределы 33 МБ / с, и при проверке с помощью strace он выполняет только вызовы lstat ().

Это составляет около 20 минут на резервную копию. Интересно, что делает restic, потому что, поскольку почти все файлы не изменены, он показывает стабильные 33 МБ/с, и я понимаю, что ему нужно только их lstat(), что именно то, что restic уже делает на первом этапе резервного копирования, просто чтобы показать общий размер за 6 или 7 секунд.

Это просто время процессора, затраченное на проверку содержимого того же файла/временной метки, уже присутствует в предыдущем снимке?

feature enhancement

Источник

viric

Самый полезный комментарий

Да, скорее всего, это и будет причиной. Для этого конкретного случая использования есть обходной путь: используйте опцию -f ( --force ) для команды backup , которая снова будет читать все файлы локально и не будет загружать метаданные из репозитория. . Это должно быть быстро.

fd0 13 авг. 2016

👍2

Все 5 Комментарий

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

fd0 19 февр. 2016

👍2

Привет

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

Я только что сделал резервную копию папки с более чем 9000 файлами и 250 МБ на удаленном сервере s3. Оба компьютера подключены к асимметричному интернет-соединению со скоростью 50/5 Мбит/с.

Первоначальная резервная копия заняла около 5 минут и казалась довольно разумной. Но вторая резервная копия вскоре после этого заняла почти вдвое больше времени! Папка с меньшим количеством файлов кажется намного быстрее.