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

Интересный момент, спасибо. Пока не знаю, как судить, что лучше. Для удаленных бэкэндов мы также могли бы (после нескольких изменений в интерфейсе бэкенда) просто передать io.Reader , а затем, возможно, stdlib сможет использовать sendfile для потоковой передачи файла прямо с диска. хм.

Просто к вашему сведению, мне было интересно, почему вы не используете GCM, поэтому я провел тесты. AES-CTR + Poly1305 работает довольно быстро, если в процессоре нет AES-NI (на 50% быстрее, чем встроенный в Go GCM). С AES-NI оптимизированный ассемблерный код Go для GCM, вероятно, непобедим.

Intel Xeon E312xx

restic:
BenchmarkEncrypt-4        50      32470322 ns/op     258.35 MB/s

stupidgcm:
Benchmark4kEncStupidGCM-4     200000         10620 ns/op     385.67 MB/s
Benchmark4kEncGoGCM-4         300000          5540 ns/op     739.22 MB/s

Intel Pentium G630 (без AES-NI)

restic:
BenchmarkEncrypt-2            10     108468078 ns/op      77.34 MB/s

stupidgcm:
Benchmark4kEncStupidGCM-2          50000         24182 ns/op     169.38 MB/s
Benchmark4kEncGoGCM-2              20000         96391 ns/op      42.49 MB/s

Это не относится к этому вопросу, но я все равно отвечу:

Я думаю, что в то время, когда я начинал restic, в Go не было оптимизированной версии GCM. Кроме того, мне было неудобно использовать GCM, потому что я не понимал его, тогда как документ Poly1305 было намного легче читать и понимать.

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

Понимаю. Да, оптимизированный GCM совсем недавно, я думаю, Cloudflare пожертвовал его для Go 1.5.

Что касается размера блока, то в тесте restic используется 8 МБ , а в глупом gcm — 4 КБ . Я повторил попытку с размером блока 8 МБ для глупого gcm, но результаты практически идентичны.

Так что не будем тратить на это время, я думаю, что CTR+Poly1305 достаточно быстр.

Важно ли иметь несжатый размер в индексном файле или нижнем колонтитуле пакета? Я думаю, было бы нормально знать это только внутри блоба, тогда в рестике требуется меньше изменений. Позволяет ли он каким-либо новым функциям быть известным в этом дополнительном месте?

На мой взгляд, формат репозитория 2 == первый байт данных блоба указывает формат сжатия, это все, что нужно. Возможно, одним из 255 возможных форматов может быть {64-битная несжатая длина} {сжатые данные}.

Я думаю, что исправление ошибок - хорошая идея для резервного копирования. Но я думаю, что это ответственность файловой системы. Вы также хотите реализовать RAID внутри restic?

Важно ли иметь несжатый размер в индексном файле или нижнем колонтитуле пакета?

Да: заголовок пакета описывает, что находится в пакете, и это сообщает процессу извлечения, чего ожидать (с точки зрения алгоритма сжатия, размера несжатого файла, а затем и других атрибутов, таких как ключ, который использовался для шифрования). То же самое должно быть представлено в индексе, который был введен, чтобы restic не нужно было искать каждый большой двоичный объект в заголовке пакета. Так что там должна быть та же информация.

На мой взгляд, формат репозитория 2 == первый байт данных блоба указывает формат сжатия, это все, что нужно. Возможно, одним из 255 возможных форматов может быть {64-битная несжатая длина} {сжатые данные}.

Мне не нравится эта идея, она усложняет формат файла: у нас будет управляющая информация в двух разных местах: в начале блоба и в заголовке. Заголовок — это именно то место, которое содержит управляющую информацию.

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

В принципе я согласен, но файловые системы очень сложные вещи, и распространение ошибок (например, ошибок чтения/записи носителя) часто неоптимально. Для значительно сокращенных (с точки зрения избыточности, например, дедуплицированных) данных резервного копирования я по-прежнему считаю хорошей идеей добавить (или предложить добавить) еще один уровень исправления ошибок.

Для кодов Рида-Соломона есть чистая реализация Go по адресу https://github.com/klauspost/reedsolomon с некоторыми данными о производительности.

Согласно https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank_html/ ZFEC должен быть быстрее. Реализация находится в https://gitlab.com/zfec/go-zfec , которая, похоже, основана на https://pypi.python.org/pypi/zfec.

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

В бинарных группах Usenet используются отдельные файлы (см. https://en.wikipedia.org/wiki/Parchive), которые содержат информацию ECC. Это добавит еще один подкаталог к ​​макету репозитория, и применение ECC к информации управления репо (конфигурация, индекс, ...) также будет простым. Но я не уверен, что это ослабит схему ECC (возможно, снижается устойчивость к ошибкам кластера в информации ECC).

Спасибо за подсказки. Я нашел PDF-версию документа здесь: https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank.pdf

Реализация ZFEC Go — это всего лишь оболочка библиотеки C.

Для ZFEC есть порт Go с дополнениями (использование горутин) под названием jfec на [https://github.com/korvus81/jfec].

Я добавил «проект» (недавнее дополнение к GitHub), чтобы отслеживать реализацию нового формата репозитория: https://github.com/restic/restic/projects/3 .

Некоторые идеи, на которые можно обратить внимание при нарушении обратной совместимости:

• Переход с ша256 на ша512

Приведет ли использование sha512 (или sha512/256) вместо sha256 к увеличению скорости резервного копирования? Насколько я вижу, это верно для большинства платформ, кроме ARM.

Обсуждение Syncthing (https://github.com/syncthing/syncthing/issues/582)

Обсуждение Борга (https://github.com/jborg/attic/issues/209)

Статья по sha512/256 (https://eprint.iacr.org/2010/548.pdf)

• Использование шифрования с открытым ключом вместо простого пароля

В настоящее время каждый, у кого есть доступ для записи в репозиторий, имеет доступ к чтению из него. Шифрование с открытым ключом устранит это и по-прежнему позволит дедупликацию на основе хэшей.

Применение шифрования с открытым ключом к большим двоичным объектам данных будет работать, но я недостаточно знаком с тем, как restic обрабатывает древовидную структуру, чтобы знать, можно ли его успешно реализовать и для этого. Возможно, это может привести к большим сложностям. Если только блоки данных скрыты, в деревьях по-прежнему много информации.

NaCl — https://godoc.org/golang.org/x/crypto/nacl/box

• Идентификация репозитория

В настоящее время нет никакого способа узнать, что вы просматриваете репозиторий restic, когда вы натыкаетесь на репозиторий. В настоящее время происходит утечка "created":"TIMESTAMP","username":"XXXXX","hostname":"XXXXX" в файлах ключей. Я бы предложил скрыть эту информацию и вместо этого включить некоторую информацию о restic, например, restic repository version X . Может быть так же просто, как README.

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

@oysols Спасибо, что добавили свои идеи!

Я добавлю свои мысли ниже:

Меняем с sha256 на sha512 (для скорости)

На данный момент скорость меня не волнует (рестик и так очень быстрый), так что по крайней мере для меня этот пункт имеет низкий приоритет. Существует даже оптимизированная версия SHA256 для процессоров с поддержкой SIMD, на которую мы можем просто переключиться. С другой стороны, когда мы решим ускорить restic и будет обсуждаться хэш, я, вероятно, предпочту Keccak (SHA3) или Blake2, это (насколько я знаю, я еще не делал никаких тестов) намного быстрее.

Так что, с моей точки зрения, этот пункт пока отложен.

Использование шифрования с открытым ключом вместо простого пароля

Эта функция запланирована (см. № 187), но она сложна и требует много размышлений и внесения нескольких серьезных изменений в инфраструктуру. Я также хотел бы отложить это и делать небольшие добавочные обновления вместо одного, в котором мы меняем все -> отложено.

Идентификация репозитория (добавьте файл README в репозиторий)

Очень хороший момент, мы можем даже добавить это сейчас, ничего не нарушая.

Репозиторий "утечка информации" (удаление имени пользователя, имени хоста и созданной метки времени из ключевых файлов)

Это тоже хороший момент. В настоящее время мы используем эту информацию только для отображения вместе с идентификатором ключа в команде key list . Мы можем легко отбросить username и host , отметка времени не дает много информации, в большинстве случаев она будет такой же, как дата создания файла.

Я хотел бы добавить username и host и оставить созданную временную метку. Есть мысли?

Сегодня я поиграл с https://github.com/klauspost/reedsolomon и думаю, что мы можем довольно легко добавить коды исправления ошибок в конец файла пакета (как только мы переместим заголовок пакета в начало файла ). Но есть два минуса:

• Размер файла увеличится примерно на 14-30%, в зависимости от параметров, которые мы выбираем для reed-solomon.
• Нам нужно будет хранить контрольные суммы (не обязательно криптографические хэши) разделов файла пакета в самом файле пакета, они необходимы для реконструкции, потому что алгоритму реконструкции необходимо знать, какие части файла были повреждены. Таким образом, для вычисления требуется немного больше времени, хотя мы можем использовать быструю контрольную сумму (например, CRC или что-то в этом роде).

Мысли?

Может ли тогда защита стержня данных быть необязательной? Я считаю увеличение размера более чем незначительным (хотя я считаю, что это отличная функция для других людей!)

Позвольте мне немного поиграть с этим, чтобы я мог почувствовать, насколько больше (или меньше?) будет репо, когда ECC сочетается со сжатием. Возможно, мы добавим два вида кодов: один для заголовка пакета и один (возможно, необязательный) для данных.

удалить имя пользователя и хост

Звучит как хорошая идея. Если мы хотим сохранить информацию, ее можно добавить в отдельное зашифрованное поле так же, как мастер-ключ.

ECC: размер файла увеличится примерно на 14-30%,

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

Я предлагаю разместить данные о четности в отдельном каталоге:

repo/data/1e/1ef7267...
repo/parity/1e/1ef7267...

• Контроль четности будет совершенно необязательным и может быть создан после резервного копирования.
• Нет замедления операций восстановления. Для восстановления не требуется дополнительная пропускная способность.
• Идентичные имена файлов облегчают определение правильных данных четности. Это будет означать, что данные четности не будут названы в честь собственного хэша sha256, но никакого дополнительного индекса не потребуется. (Проверка данных четности в любом случае должна выполняться путем проверки файлов пакета.)
• Пользователь получает представление о количестве данных четности.

Независимо от того, как это реализовано; Я думаю, что со многими уровнями сжатия и шифрования необходим какой-то ECC. Один неверный бит может вызвать много проблем.

Спасибо за ваши комментарии, давайте перенесем обсуждение в отдельную тему, которую я только что создал: #804.

У меня не может не сложиться впечатление, что две группы обсуждают друг с другом коды прямого исправления ошибок в restic. Одна группа хочет (просто) защитить репозиторий от битрота, потому что даже один битфлип может создать огромную проблему в дедуплицированном репо. Другая группа хочет использовать коды стирания для распространения репозитория на несколько отказоустойчивых доменов (например, диски без RAID). Коды Рида-Соломона могут служить обеим целям, но они требуют разных параметров и разных схем хранения.

Я быстро проверил репозиторий с помощью скрипта Python (https://github.com/oysols/restic-python).

header_length:        8688549
tree_length:         53898054
data_length:     146443506727
treeblobs:               8466
datablobs:             200975
packfiles:              29351
---- repo size by dir ----
            155   config
146 510 470 574   data
     27 538 629   index
          4 545   keys
          4 243   locks
         14 041   snapshots
          4 096   tmp
-----
Currently 116071 original files contained in the backup.

Из резервной копии размером 146 ГБ древовидные BLOB-объекты занимают всего 54 МБ и будут хорошо сжаты примерно до трети исходного пространства, когда мы реализуем сжатие.

Будет ли улучшение производительности путем отделения больших двоичных объектов дерева от больших двоичных объектов данных?

Кажется, что большинство операций, выполняемых во время восстановления, выполняются на основе больших двоичных объектов дерева до фактического восстановления данных. Разделение их на отдельные пакетные файлы сведет к минимуму объем данных, которые необходимо загрузить для анализа дерева резервной копии. Учитывая небольшой размер больших двоичных объектов дерева, может быть даже быстрее загрузить все большие двоичные объекты дерева перед началом процесса восстановления.

Конечно; Это распределение может быть не одинаковым для всех репозиториев.

Как вы думаете, стоит ли это изучать дальше?

Будет ли улучшение производительности путем отделения больших двоичных объектов дерева от больших двоичных объектов данных?

Возможно, это одна из оптимизаций, которые я имею в виду на будущее.

Помимо этого, я также хотел бы добавить локальный кеш для метаданных, чтобы их вообще не нужно было извлекать из репо. Это должно значительно повысить скорость многих операций.

Будет ли улучшение производительности путем отделения больших двоичных объектов дерева от больших двоичных объектов данных?

Теоретически это может улучшить работу prune , поскольку потребуется меньше повторной упаковки, если большие двоичные объекты деревьев и большие двоичные объекты данных будут находиться в отдельных пакетных файлах (может стать возможным полное удаление старого пакетного файла вместо его повторной упаковки).

Я уже смотрю на это во время #842

gcm против ctr: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html

sym против asym: идея состоит в том, чтобы зашифровать «сессионный» ключ с помощью публичного ключа, верно?

Не будем обсуждать крипту в этом выпуске, так как он пока отложен. Актуальная проблема для обсуждения асимметричной криптографии — № 187. Кроме того, я хотел бы поддерживать обсуждение на высоком уровне, пока мы не определим вариант использования. Тогда мы можем говорить о низкоуровневой криптографии.

Удалите имя пользователя и имя хоста из файлов ключей.

Огромная утечка метаданных!
Например, "username":"WorldBank\\JimYongKim" явно указывает на высокопоставленного владельца .

Ожидание того, что это будет _удалено_ (или _зашифровано_), так как первый двоичный файл Windows был скомпилирован в январе 2017 года.
К счастью, я изучил резервную копию, прежде чем загружать или рекомендовать Restic людям, заботящимся о конфиденциальности.

Редактировать: часовой пояс пользователя также упоминается в виде простого текста, что также противоречит принципу конфиденциальности .

Re: SHA3 -- вот одно мнение о том, почему его не стоит принимать (пока?): https://www.imperialviolet.org/2017/05/31/skipsha3.html

Таким образом, я считаю, что SHA-3, вероятно, не следует использовать. Он не дает убедительных преимуществ по сравнению с SHA-2 и сопряжен с большими затратами. Единственный аргумент, которому я могу доверять, заключается в том, что хорошо иметь резервную хэш-функцию, но как SHA-256, так и SHA-512 обычно поддерживаются и имеют разные ядра. Итак, у нас уже развернуты две защищенные хэш-функции, и я не думаю, что нам нужна еще одна.

Я прочитал пост и понял аргументы agl. Для остальных это не так актуально: мы используем хеш-функцию для (уникальной) идентификации больших двоичных объектов, а не в качестве строительного блока криптографического протокола. Моя идея взглянуть на другие хеш-функции заключалась главным образом в том, что SHA-256 медленно вычисляется, особенно на слабых системах. Другие хеш-функции намного быстрее (например, blake2).

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

@mschiff См. # 1018 для этого обсуждения. ;)

Как насчет того, чтобы сделать размер детали опцией?
В настоящее время у меня есть 4-6 МБ на файл. С меньшим количеством файлов, но большим, удаленное резервное копирование будет намного быстрее.

@fd0 написал:

На данный момент скорость меня не волнует (рестик и так очень быстрый), так что по крайней мере для меня этот пункт имеет низкий приоритет. Существует даже оптимизированная версия SHA256 для процессоров с поддержкой SIMD, на которую мы можем просто переключиться. С другой стороны, когда мы решим ускорить restic и будет обсуждаться хэш, я, вероятно, предпочту Keccak (SHA3) или Blake2, это (насколько я знаю, я еще не делал никаких тестов) намного быстрее.

Еще одним соображением для более быстрого алгоритма хеширования с меньшей нагрузкой на ЦП (например, Blake2) будет снижение использования батареи на ноутбуках при создании резервных копий, когда они не подключены к источнику питания.

Отвечая на первый пост:

Удалите имя пользователя и имя хоста из файлов ключей.

Будет ли это заменено именем ключа или каким-то описанием? Я считаю, что какой-то способ различать разные ключи (без доступа к самому ключу, например, при отзыве доступа для какой-либо машины) полезен, чтобы сделать управление ключами полезным?

Одно новое предложение: как насчет использования другого ключа для больших двоичных объектов, деревьев и снимков? Это, AFAICS, позволит реализовать сценарий, при котором забывание и сокращение происходит на сервере хранилища резервных копий, а не на клиентах. Предоставляя серверу хранения доступ к дереву и объектам моментальных снимков, он должен иметь достаточно информации, чтобы определить, какие объекты нужны для каких моментальных снимков, а какие объекты больше не используются. Если сервер хранения скомпрометирован, доступ будет получен к метаданным дерева, но не к фактическому содержимому файла.

Это можно сделать немного сильнее, разрешив доступ только к списку идентификаторов объектов, на которые ссылается дерево, не разрешая доступ к остальным метаданным (но для этого потребуется дополнительная структура данных для каждого дерева).

Если вышеперечисленное станет возможным, это откроет путь для использования типа хранилища только для записи/добавления (где клиент резервной копии не может удалять резервные копии, см. #784), без необходимости жертвовать автоматической обрезкой или безопасность данных.

Что касается моего предыдущего комментария (обрезка без полного доступа к данным): это также относится (возможно, даже сильнее) к проверке резервной копии. Имеет смысл проверять репозиторий на сервере хранения из соображений эффективности (AFAICS для удаленной проверки репо требует передачи всего контента) или при реализации настоящей поддержки только для записи (см. https://github.com/ncw/rclone/issues). /2499).

Кроме того, для истинного подхода только для записи необходимы изменения в restic, чтобы ограничить, какие файлы необходимо читать (согласно https://github.com/ncw/rclone/issues/2499#issuecomment-418609301). Я не уверен, что для этого также нужны изменения формата репозитория, если да, то может быть полезно включить их здесь?

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

Я хотел бы обсудить некоторые (возможно, необязательные) дополнения к формату файла моментального снимка:

• Добавить список используемых индексных файлов (см. #1988)
• Добавить возможность для пользовательских данных (таких как описания дополнений и т. Д., Не нашел проблему прямо сейчас)
• Добавьте статистические данные, такие как количество файлов/BLOB-объектов, используемое пространство и т. д. Это может значительно ускорить отображение статистики, а также позволит выполнять дополнительные проверки.

По поводу формата файла пака хотелось бы спросить, почему бы не убрать полностью шапку.
Информация избыточно включена в индексные файлы. Было некоторое обсуждение добавления избыточности для исправления ошибок, но IMO это должно (и может) быть отделено от общего формата репо и может быть добавлено или не добавлено поверх этого.

Короче говоря: если вам не нужна дополнительная информация для исправления ошибок, нет необходимости дублировать информацию в файлах заголовка пакета и индексных файлах. Индексные файлы необходимы для производительной работы и используются повсеместно. Заголовки пакетов используются редко — и то только для перепроверки или исправления ошибок.

Еще одно предложение: добавить имя пользователя, имя хоста и содержимое файла конфигурации в раздел data файла ключей. Таким образом, полностью удалите файл конфигурации.

Как уже предлагалось, имя пользователя и хост должны присутствовать только в зашифрованном виде. Чтобы проверить, действителен ли полученный из KDF ключ, уже достаточно проверить MAC-адрес зашифрованного раздела data .
ИМО имеет смысл поместить туда всю информацию, необходимую для идентификации ключа. Добавление информации, хранящейся в файле config ATM, просто удаляет лишний файл из репо и упрощает инициализацию репо.

Извините за «тупой» вопрос, но предпринимаются ли какие-либо серьезные усилия по внедрению улучшенного формата в ближайшее время? Я следил за этой проблемой в течение многих лет. В настоящее время restic плохо работает с большими наборами данных или при наличии большого количества моментальных снимков и требует много памяти. Похоже, что отсутствие сжатия и большие накладные расходы на метаданные, закодированные в JSON, являются большими проблемами restic. Может быть, усилия зашли в тупик, потому что существует осознанная необходимость достичь «совершенства»?

Я также заинтересован в том, что будущее принесет restic. Особенно в асимметричном крипто и сжатии.
Кстати, для новой хэш-функции также есть blake3, очень новая и тоже очень быстрая: https://github.com/BLAKE3-team/BLAKE3 .
Если решение об изменении хеш-функции еще не принято, это может быть интересно.

Еще несколько идей для repo.v2:

• сохранять дерево и большие двоичные объекты данных в разные каталоги (в прошлом дерево и данные были смешаны, но это устарело с введением кеша).
• добавить информацию о «времени создания» в большие двоичные объекты данных.

Это должно упростить поддержку «холодного» хранилища с очень медленной или дорогой загрузкой, такой как amazon Glacier.

* save tree and data blobs to different directories (in the past tree and data was mixed, but this was deprecated with introduction of cache).

Мне не нравится эта идея .. Это значительно упрощает угадывание размеров файлов резервных копий, хотя я не вижу в этом пользы.

* add 'created time' info to data blobs.

Я не вижу смысла добавлять «созданное время». Можете ли вы привести пример использования?

Это должно упростить поддержку «холодного» хранилища с очень медленной или дорогой загрузкой, такой как amazon Glacier.

Я бы сказал, что поддержка «холодного хранения» уже может быть достигнута с помощью существующего формата репо путем добавления некоторых возможностей тонкой настройки к restic и двойного хранения тем не менее часто используемых файлов, например, в локальном кеше. См. также #2504

* save tree and data blobs to different directories (in the past tree and data was mixed, but this was deprecated with introduction of cache).

Мне не нравится эта идея .. Это значительно упрощает угадывание размеров файлов резервных копий, хотя я не вижу в этом пользы.

Преимущество хорошо изложено в более ранних комментариях по этому вопросу:
https://github.com/restic/restic/issues/628#issuecomment-280436633
https://github.com/restic/restic/issues/628#issuecomment-280833405
Результаты в первом комментарии также показывают, что смешивание этих двух типов больших двоичных объектов никоим образом не скрывает размеры файлов.

соответствующий пост на форуме:
https://forum.restic.net/t/feature-using-an-index-for-restic-find/1773

@cfbao Комментарии, на которые вы ссылаетесь, касаются смешивания дерева и большого двоичного объекта данных в одном файле данных (пакете). Разделение этого было полезно для включения обработки кэша. Это также уже изменено в restic.

Тем не менее, я все еще не вижу никакой пользы от сохранения дерева и больших двоичных объектов данных в разных каталогах . Можете ли вы привести пример использования? (ИМХО тема поиска форума не имеет отношения - я отвечу вам там)

Однако разделение записей деревьев и BLOB-объектов данных в отдельных индексных файлах (например, в каталогах «index-data» и «index-tree») позволило бы внести некоторые улучшения.

Блобы дерева уже хранятся в отдельных пакетных файлах (это было введено вместе с кешем).
Просто запись их в другой каталог откроет способ улучшить поддержку хранилищ с очень медленной загрузкой (3-5 часов для стандарта Amazon Glacier). Например, хранить все метаданные (индекс+снимки+дерево в обычном S3 и данные в Glacier).

2504 немного улучшает его, но мне не нравится идея полагаться на «локальный кеш» или долго ждать, чтобы заполнить кеш.

Мне гораздо больше нравится идея иметь какой-то обратный прокси, который будет хранить tree+index+snapshots на обычном S3 или любом другом месте, но помещать данные в глубокий архив.
В любом случае, безусловно, можно использовать restic как есть с некоторыми ограничениями. Но некоторые изменения формата могут улучшить/упростить ситуацию.

@cfbao насколько я вижу из кода restic find от этого не выиграет. Он уже ходит по снапшотам. В основном это то же самое, что и restic ls <all-snapshots> | grep something .

@дионоргуа
Мне нравится идея добавить произвольный репозиторий в качестве «дополнительного» кеша, где кешируются все, кроме пакетов данных. Это не требует изменения макета репозитория, и IMO гораздо более гибкая.
Я уже работаю над этим, см. также #2516, последний комментарий.

Может быть, это глупая идея, но как насчет формата, совместимого с borg или kopia?

@aawsome

Комментарии, на которые вы ссылаетесь, касаются смешивания дерева и большого двоичного объекта данных в одном файле данных (пакете).

Истинный. Виноват. Да, это единственное, что меня волнует.

Это также уже изменено в restic.

Вы знаете, в каком PR/версии это было изменено? В прошлый раз, когда я проверял свой репозиторий, я заметил сочетание больших двоичных объектов данных и дерева в одних и тех же пакетных файлах. В любом случае я могу (возможно, медленно) преобразовать свое репо, чтобы иметь лучшее разделение?

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

Не имею представления. Как уже было сказано, меня это не особо волнует.

@дионоргуа

насколько я вижу из кода, restic find от этого не выиграет. Он уже ходит по снапшотам. В основном это почти то же самое, что и restic ls| греть что-то.

Разве разделение больших двоичных объектов дерева от больших двоичных объектов данных не уменьшит количество вызовов API, необходимых для поиска? В случае концентрации количество пакетных файлов, содержащих древовидные BLOB-объекты, будет уменьшено, и restic может загружать меньшее количество целых файлов вместо того, чтобы извлекать множество сегментов из множества пакетных файлов. Это важно для бэкендов, которые относительно медленные и имеют более строгие ограничения скорости (например, Google Диск).

В любом случае я могу (возможно, медленно) преобразовать свое репо, чтобы оно было лучше
разлука?

С последней версией restic запуск 'prune' должен восстановить эти смешанные пакеты.
Обратите внимание, что фактическая реализация 'prune' генерирует много трафика для удаленных репозиториев. С экспериментальной реализацией в #2718 вы сможете переупаковывать только смешанные пакеты с минимальным трафиком.

Разве разделение больших двоичных объектов дерева от больших двоичных объектов данных не уменьшит количество API?
вызовы необходимые для поиска?

В последней версии и в репозитории, в котором нет смешанных пакетов, вся необходимая информация кэшируется локально.

Еще одна идея для улучшенного формата репозитория:

Как мы видели, удобно разделять файлы пакетов по типу больших двоичных объектов (большие двоичные объекты дерева и данных помещаются в разные файлы пакетов). Не было бы хорошей идеей также разделить индексные файлы по типу BLOB-объектов? Недавние PR индекса уже идут в направлении разделения записей индекса для дерева и больших двоичных объектов данных в представлении в памяти.
Также возможны оптимизации для загрузки только части индекса

Выполнение этого также в репозитории позволит получить более компактное представление, например

{
  "supersedes": [
    "ed54ae36197f4745ebc4b54d10e0f623eaaaedd03013eb7ae90df881b7781452"
  ],
  "type": "data",
  "packs": [
    {
      "id": "73d04e6125cf3c28a299cc2f3cca3b78ceac396e4fcf9575e34536b26782413c",
      "blobs": [
        {
          "id": "3ec79977ef0cf5de7b08cd12b874cd0f62bbaf7f07f3497a5b1bbcc8cb39b1ce",
          "offset": 0,
          "length": 25
        },{
          "id": "9ccb846e60d90d4eb915848add7aa7ea1e4bbabfc60e573db9f7bfb2789afbae",
          "offset": 38,
          "length": 100
        },
        {
          "id": "d3dc577b4ffd38cc4b32122cabf8655a0223ed22edfd93b353dc0c3f2b0fdf66",
          "offset": 150,
          "length": 123
        }
      ]
    }, [...]
  ]
}