В сообщении от [Пн 2018-02-19 12:58 +0200] Dmitry Nezhevenko <d...@dion.org.ua> пишет:
> Оно очень сильно кушает RAM на клиенте. При чем потребление > пропорционально общему размеру репозитория. Для моих 1.5TB данных это > около 4GB RAM при бэкапе. Спасибо, хороший обзор. Вопрос: а может это Page Cache? Посмотрите вывод команды free, если память потребляется за счет buff/cache, то всё в порядке. У меня на виртуалке крутится Minio (прога схожая по функциональности с restic и также написана Go), почти вся память уходит в Page Cache. > Ключи шифрования одни на все хосты (в общем случае любой хост может > прочитать бэкапы 'соседей'). Можно сделать репозиторий под каждый хост, но тогда теряются преимущества дедупликации. С точки зрения S3 и Minio, репозиторий это просто bucket, мне кажется здесь нужно найти компромисс между безопасностью и удобством. > Удаление ненужных бэкапов (точнее prune, освобождение места после них) > -- штука медленная... Восстановление с помощью 'restic restore' очень > медленное. На сайте restic сказано [1], что он хранит временные файлы и кэш в директориях по умолчанию, но их можно переназначить. Было бы интересно заменить их на SSD-диск и посмотреть насколько улучшилась производительность (конечно если у вас есть такая возможность). [1]: https://restic.readthedocs.io/en/stable/manual_rest.html -- Коротаев Руслан https://blog.kr.pp.ru
smime.p7s
Description: S/MIME cryptographic signature
