При реализации этого добавьте тесты и особенно посмотрите на использование памяти с помощью -benchmem и benchcmp!

lz4, lzo, lzma, нуль. bz2 довольно медленный.

snappy работает быстро с умеренным сжатием

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

По сути, это та же проблема, которую мы обсуждали в отношении снятия отпечатков пальцев с процесса дедупликации CDC:
С помощью «наивного» CDC можно проверить наличие файла с «известным открытым текстом» в резервной копии, если злоумышленник может наблюдать размер отдельных блоков, путем параллельного использования CDC для файла и сравнения полученного количества фрагментов и отдельных длины чанков.
Как обсуждалось ранее, это можно несколько смягчить, добавив в алгоритм CDC секретное значение, как это сделано на чердаке.

Я предполагаю, что с использованием соленого CDC сжатие будет происходить для каждого отдельного фрагмента после разделения проблемного файла на фрагменты. Остальные фрагменты находятся в диапазоне от 512 КБ до 8 МБ (но распределяются неравномерно, верно?).

• Злоумышленник знает, что алгоритм CDC использует секретную соль, поэтому злоумышленник генерирует ряд фрагментов, состоящих из первых 512–8 МБ файла, по одному на каждую допустимую длину фрагмента. Злоумышленник также может определять длину сжатых фрагментов.
• Затем злоумышленник сжимает этот фрагмент, используя алгоритм сжатия.
• Злоумышленник сравнивает длину полученных фрагментов с первым фрагментом в остальных наборах резервных копий.
• ЕСЛИ найдена подходящая длина блока, злоумышленник повторяет упражнение со следующим фрагментом, и следующим фрагментом, и следующим фрагментом, ... и следующим фрагментом.
• Я считаю, что при достаточно больших файлах и с учетом того факта, что алгоритм CDC «предвзято» (из-за отсутствия лучших слов) в сторону генерации блоков размером около 1 МБ, этого было бы достаточно, чтобы установить, действительно ли конкретный большой файл существует в резервной копии.

КАК всегда, параноидальный и в высшей степени ненаучный поток сознания.

Мысли?

Интересно. Я не понимаю, как описываемая вами атака зависит от того, используется ли сжатие, нужно ли оно вообще? Разве эта атака не работает со сжатием и без него?

В данный момент думаю, как реализовать №56. Что вы думаете об объединении нескольких BLOB-объектов в один файл?

Мне немного неясно, как работает реализация CDC:

• Вы разбиваете по точным границам байтов или блоки размером 512 КБ - 8 МБ «округляются» до кратного какого-либо числа?
• (Реальный вопрос: есть ли (15 * 512 * 1024) / (16 из-за AES-CTR) возможный размер блока или меньше?)
• Мне также любопытно, насколько возможно было бы восстановить семя при достаточном количестве кусков известного файла - я предполагаю, что это не очень возможно?

Чтобы ответить на ваш первый вопрос:
С начальным CDC «отпечаток пальца» зависит от (содержимого + секретного начального числа), но разница в том, что когда сжатие выполняется _после_ разбиения на фрагменты, и при условии, что вы можете отличить отдельные блоки друг от друга, у вас есть отпечаток / водяной знак (степень сжатия определенного блока), который зависит исключительно от содержимого, в этом сценарии это известный открытый текст.

Пример:
Если файл с водяными знаками содержит 64 МБ (8–128 фрагментов) AAAA, затем 64 МБ «ABCABCABCABC», затем 64 МБ случайных данных, первые 16–256 фрагментов будут очень маленькими (поскольку эти последовательности очень хорошо сжимаются. , где 8-128 фрагментов сжимаются довольно плохо).
Злоумышленник также сможет работать в обратном направлении, начиная с самого последнего (24–384-го) фрагмента, и сжимать 512–8 МБ до тех пор, пока злоумышленник не найдет размер, который сжимается до точно такого же размера фрагмента. Как только это будет найдено, «следующие» 512–8 МБ исходного открытого текста сжимаются, чтобы выяснить, какая длина сжимается до длины предпоследнего блока (23–383) и т. Д., Пока злоумышленник не встретит небольшие фрагменты, которые являются результатом строк «AAAA».
Это не позволяет злоумышленнику точно подтвердить, что файл с водяными знаками хранится в резервной копии, но я думаю, что статистически он может дать довольно четкие результаты при наличии достаточного количества данных.

Я вижу несколько потенциальных решений, возможно, у вас есть еще идеи:

• Разрешить отключение сжатия и / или дедупликации для определенных каталогов (вероятно, самый простой вариант)
• Произвести случайное использование словарей сжатия (еще не продумал этот вариант, но идея кажется интересной)
• Не позволяйте злоумышленникам узнавать длину отдельных сжатых фрагментов, например, путем заполнения (потенциально довольно дорого) или путем объединения нескольких небольших фрагментов и заполнения оставшихся (более сложная, но более эффективная)

Спасибо за объяснение, теперь я понимаю ваш сценарий.

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

Ваша третья идея будет реализована в # 56 (объединение нескольких фрагментов), я работаю над этим прямо сейчас. И я, вероятно, добавлю дополнительную документацию в doc/Design.md относительно того, как работает чанкер.

Еще раз спасибо за то, что подняли этот сценарий!

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

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

@klauspost : Имейте в виду, что мы обсуждаем сжатые размеры отдельных фрагментов, а не файлов. Файл размером 100 ГБ со средним размером фрагмента 1 МБ будет иметь примерно 100 x 1024 фрагментов, каждый из которых имеет степень сжатия для определенной части файла. Это приводит к гораздо большему количеству статистических данных, чем размер одного сжатого файла, что позволяет сравнивать известный открытый текст со сжатым и разбитым на части файлом, даже если соль CDC (и, следовательно, точные границы выравнивания фрагментов) неизвестны.

Однако 151 был объединен, так что сейчас это, вероятно, не проблема.

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

@klauspost Я обязательно посмотрю на вашу библиотеку, спасибо, что указали на нее!

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

@cfcs - хорошо - из вашего текста я подумал, что вы подразумеваете, что можете вывести данные. Поэтому, чтобы это имело какое-либо значение, вам потребуются исходные данные, что бывает редко.

Что касается несжимаемых файлов, именно по этой причине я упомянул режим «Только Хаффмана с постоянным временем», который я ввел в deflate, поскольку название подразумевает, что он сжимает все данные с одинаковой скоростью и имеет автоматический откат к хранению несжатых данных. Таким образом, максимальные накладные расходы составляют около 0,04%, если содержимое сжато.

Вот несколько тестов . Наиболее подходящим для резервного копирования, вероятно, является «Среднее сжатие», которое представляет собой смешанное содержимое 10 ГБ - сжимаемое и несжимаемое.

По умолчанию может иметь смысл использовать только gzip Huffman и возможность указать более интенсивный уровень сжатия.

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

Я посмотрел на некоторые «точки», где можно было бы вставить сжатие. Самое прозрачное и универсальное место будет где-то между репозиторием и бэкэндом.

Я вкратце рассмотрел изменение Repository.Encrypt и Repository.DecryptTo , но у нас нет типов, и различные размеры могут создать беспорядок.

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

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

репозиторий.

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

репозиторий.Config

Конфигурация не может быть сжата. Мы добавляем строку, которая указывает тип декомпрессии, который будет использоваться для всего. Пустой ("") не сжат. В противном случае это последняя часть имени пакета используемой библиотеки сжатия.

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

type Config struct {
    Version           uint        `json:"version"`
    ID                string      `json:"id"`
    ChunkerPolynomial chunker.Pol `json:"chunker_polynomial"`
+   Compression       string
}

Сжатие добавлено как параметр создания:

-func CreateConfig(r JSONUnpackedSaver) (Config, error) {
+func CreateConfig(r JSONUnpackedSaver, compression string) (Config, error) {

Бэкэнд заменяется после LoadConfig / CreateConfig. Вот пример того, как это могло бы выглядеть:

// SearchKey finds a key with the supplied password, afterwards the config is
// read and parsed.
func (r *Repository) SearchKey(password string) error {
    key, err := SearchKey(r, password)
    if err != nil {
        return err
    }

-   r.key = key.master
-   r.keyName = key.Name()
    r.Config, err = LoadConfig(r)
+   r.be, err = FindCompressor(r.Config.Compression, Encryption(key, r.be))
    return err
}

Реализация сжатия

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

Проблемы

HELPME / FIXME: «Упакованные» файлы кажутся проблемой, поскольку шифрование запускается заново для каждого файла. Если шифрование перенесено на бэкэнд, шифрование будет для всего большого двоичного объекта, а не для каждого файла. Я предполагаю, что это проблема, и у меня нет хорошего решения.

TODO: Найдите хороший способ отправки параметров / конфигурации в компрессор. Не требуется для первой реализации.

TODO: Мы заботимся о размерах на диске? Если это будет реализовано, репозиторий не узнает об этом.

Спасибо, что поделились своими мыслями, вот мои:

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

Кроме того, упакованные файлы сами по себе являются уровнем абстракции (например, материал можно переупаковывать), который не работает с абстрагированием криптографии.

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

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

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

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

просто как практический пример:

я делаю резервные копии с сервера моей компании на мой сервер резервного копирования дома. dsl uplink со скоростью ~ 700 кбит / с.
для этого мне нужно лучшее сжатие (например, lzma + high level). у процессора есть много свободного времени ночью в ожидании дрянного соединения, чтобы принять следующий пакет.

в тот же репозиторий я также делаю резервную копию своего ноутбука, когда нахожусь дома, там у меня есть беспроводное соединение "N". Конечно, я не хочу замедлять соединение, используя там lzma + high level, но мне нужно что-то очень быстрое, которое вообще не замедляется - например, lz4. Я все еще хочу сжатие, без использования lz4 потребуется примерно в 2 раза больше места.

Я хочу lzma здесь, но lz4 там (перефразировано :-))

Это все bikeshedding imho ... Давайте выберем разумное значение по умолчанию и не будем раскрывать слишком много конфигурации, это просто внесет много сложностей с небольшой выгодой, imho.

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

Справедливо. Я начал просматривать repository.go и нашел все места, где вы могли бы вставить этап сжатия / распаковки, и добавленная сложность не была хорошей вещью. Реализуя его как интерфейс backend , вы можете внезапно убрать все шифрование и сделать его частью бэкэнд-цепочки. Вы можете провести общий тест, который гарантирует симметрию внутренних частей, включая сжатие и шифрование.

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

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

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

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

Сжатые репозитории, очевидно, не будут, но мы можем изменить version на 2, только если репо сжато, это приведет к отказу старых клиентов. Затем, очевидно, следует изменить проверку на if cfg.Version > RepoVersion { , но это не вызывает проблем с совместимостью.

Это все bikeshedding imho ... Давайте выберем разумное значение по умолчанию и не будем раскрывать слишком много конфигурации, это просто внесет много сложностей с небольшой выгодой, imho.

Согласен. Большинство алгоритмов (lzma / deflate) обладают большой гибкостью в рамках одного и того же формата распаковки.

Для проверки сжимаемости есть DataSmoke: https://github.com/Bulat-Ziganshin/DataSmoke

Кроме того, pcompress выбирает хороший набор алгоритмов сжатия: https://github.com/moinakg/pcompress

Библиотека абстракции сжатия сквоша имеет хороший список алгоритмов и тестов: https://quixdb.github.io/squash/

Здесь есть тест сжатия текста: http://mattmahoney.net/dc/text.html

Простой подход - всегда фильтровать внутри функций crypto/crypto.go Encrypt / Decrypt.

gzip-сжатие-v1.patch.txt - это

Спасибо, что попробовали @mappu , но перед

• Когда применяется сжатие? (Данные? Метаданные / JSON?)
• Какой алгоритм мы должны реализовать? Думаю, у @klauspost есть для нас предложения :)
• Как сохранить это в репозитории, не нарушая работу клиентов?

Когда применяется сжатие? (Данные? Метаданные / JSON?)

Данные очевидно да.
Метаданные / json, возможно, это бессмысленно, но я думаю, что это может помочь для больших файлов метаданных, поскольку данные JSON в основном представляют собой ASCII и выиграют от арифметического кодирования / фазы Хаффмана (gzip имеет).

Поскольку данные / метаданные всегда зашифрованы, я думаю, что добавление к процедуре шифрования / дешифрования - простой способ уловить все случаи использования, без этого "Я начал просматривать repository.go и нашел все места, где вы бы вставили этап сжатия / распаковки, и дополнительная сложность не очень-то хорошо ". из @klauspost .
Кроме того, поскольку большие двоичные объекты хранятся с именем хэш (открытый текст), а не хэш (зашифрованный текст) {{очевидно, необходимо для дедупликации, иначе случайный IV уничтожит дедупликацию}}, это безопасно делать без ущерба для дедупликации.

Какой алгоритм мы должны реализовать? Думаю, у @klauspost есть для нас предложения :)

не волнует Хотя я согласен с @ThomasWaldmann, что это должно быть настраиваемым. По крайней мере, для случая использования --best и --fast .

Я бы предложил gzip только потому, что он чистый, он находится в стандартной библиотеке golang и привлекает внимание к производительности со стороны Google. xz намного сильнее медленного сжатия. lz4 намного слабее быстрого сжатия. gzip сбалансирован и легко настраивается, даже если он не достигает крайних значений.

Как сохранить это в репозитории, не нарушая работу клиентов?

Репозиторий должен быть совместим только в одном направлении. Я думаю, что это нормально, если старый restic не может читать новое репо, если новый restic может читать старое репо.

Возможно, вы могли бы добавить байт тега после MAC. Нет - компрессии нет (старый рестик). Затем байт также может указывать, какой алгоритм сжатия использовался. 0x01 gzip 0x02 lz4 или около того.

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

На чердаке (borg) мне повезло, так как старый формат был только gzip, а формат gzip можно определить по первым 2 байтам. Поэтому я сохранил gzip без дополнительных байтов (как в старых репозиториях) и добавил байты типа (для отсутствия или другого сжатия), которые никогда не будут неоднозначными с первыми двумя байтами gzip.

Очевидно, вы не можете этого сделать, если старый формат - это просто необработанные произвольные данные.

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

как это сделано с EXTENDEDPROTOCOL в квитировании nmdc lock.

О нет, мы не будем делать что-то безобразное, да и не нужно. Если мы решим реализовать это, в файлах пакета будет поле type для каждого большого двоичного объекта. Это uint8 , и на данный момент он определен только для data и tree , мы можем легко добавить compressed data и compressed tree . https://github.com/restic/restic/blob/master/doc/Design.md#pack -format

На данный момент я не считаю эту функцию приоритетной.

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

Важно, чтобы new-restic работал со старым репо, чтобы упростить обновление. Он должен быть либо бесшовным (предпочтительно), либо иметь инструмент restic upgrade-repo (не рекомендуется).

Так как насчет этого?

Все команды restic уже выполняют первую загрузку + расшифровывают config .

• если первый байт config равен { (это первый байт объекта json), то все репо имеет старый формат (несжатый)
• в противном случае первым байтом config будет {tag byte}, а все репо - это новый формат. {tag byte} в начале расшифрованных данных указывает формат сжатия. пример 0x00 без сжатия 0x01 gzip

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

Я только что нашел restic вчера, когда искал хорошее решение для резервного копирования. Одна из моих основных проблем - ограничение места, которое занимают мои данные. Особенно, если я отправляю данные в места, где плачу, например S3. Dedup определенно поможет, но я ожидал, что сжатие будет неотъемлемой частью решения для резервного копирования ... В https://github.com/restic/restic/issues/21#issuecomment -185920429 вы ( @ fd0 ) говорите это низкий приоритет, не могли бы вы объяснить почему? Есть ли дорожная карта, на которую я мог бы взглянуть где угодно?

Также +1. ;)

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

Мы реализуем сжатие (в конце концов, о чем идет речь), просто еще не сделано. restic - довольно новый проект, будьте терпеливы :)

Эта проблема связана с № 116. Из-за шифрования мы не можем сжать резервную копию с помощью других инструментов, не так ли? Какой у вас приоритет между сжатием и желанием сделать шифрование необязательным? (Ставлю сначала на сжатие!)
_Извините, что оказываете давление по этому поводу, вы правы, что формат репозитория нужно соблюдать осторожно! _

На это легко ответить: сначала будет реализовано сжатие.

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

@ fd0 Спасибо, что

Я полностью согласен с тем, что вам нужно убедиться, что сжатие выполняется «правильно и безопасно». Если это задержит, пусть будет так. :улыбка:

Я реализовал мгновенное сжатие в restic здесь: https://github.com/viric/restic/tree/snappy

Это просто предложение. По сути, я добавил мгновенное сжатие / распаковку для больших двоичных объектов в пакетах и ​​использовал в качестве метки немного байта типа blob. Я также добавил поле в индексах пакетов: PLength (длина открытого текста), которое до тех пор не сохранялось, а рассчитывалось как "bloblength - crypto.Extension".

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

Все рестик-тесты проходят нормально. Он может работать с предыдущими репозиториями restic, но обычный restic (репозиторий master) не может обрабатывать новые капли.

Я использовал snappy (https://github.com/golang/snappy), потому что думал, что это будет меньше влиять на скорость @ fd0.

Добавлена ​​награда в размере 50 долларов за компрессионную посадку на мастере.

Как упоминалось выше, должен быть автоматизированный, не настраиваемый способ избежать попыток сжатия несжимаемых файлов, таких как мультимедийные, зашифрованные или уже сжатые. Проблема усугубляется некоторыми форматами контейнеров, такими как PDF, содержимое которых иногда можно сжимать, а иногда нет.

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

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

Не уверен, насколько хорошо это будет отображаться на уровне фрагмента, а не на уровне файла.

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

@teknico

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

Мой модифицированный пакет deflate реализует пропуск уже сжатых данных и делает это со скоростью ~ 250 МБ / с на ядро. Go 1.7 deflate поддерживает это только при самых быстрых уровнях сжатия.

Snappy и LZ4 поддерживают аналогичную функцию пропуска.

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

Это обязательно должен быть вариант. В Go 1.7 (теперь называемом HuffmanOnly и моим эквивалентом) этот режим поддерживает ~ 200 МБ / с на ядро ​​независимо от входных данных. Однако сжатие сильно затруднено по сравнению с «лучшей скоростью», которая обычно составляет 80 МБ / с / ядро.

@cfcs

Я думаю, что это должно быть для каждого файла, даже если это делает его «менее приятным».

В целом согласен. Мне нужно будет прочитать о restic. Доступен ли двоичный размер каждого размера пакета в незашифрованном виде?

@klauspost Похоже, что некоторые из ваших улучшений были объединены в режим Go 1.7 DEFLATE "BestSpeed", это правильно? Может быть, это было бы разумным дефолтом.

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

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

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

Эвристика «сжимаемого» теста одновременно подвержена ошибкам и довольно дорога. Я бы сказал, что было бы трудно получить намного больше, чем 200 МБ / с / ядро ​​- это скорость поиска порядка 1 в пакете дедупликации на AMD64.

Кроме того, это будет во многом зависеть от используемого компрессора. Snappy не сможет сжимать случайные данные в базе 64, но deflate, например, может, поэтому я оставил бы эту часть компрессору - у нас это встроено для Snappy, LZ4 и deflate.

@ fd0 извините, я имел в виду для каждого BLOB-объекта, а не для каждого файла.
Если мы не выберем облегченный алгоритм, сжатие, которое несколько нагружает процессор, может стать узким местом (рядом с AES, о котором, надеюсь, в будущем позаботится AES-NI).

@ fd0 - Я сделал быструю «оценку сжимаемости»: https://play.golang.org/p/Ve5z3txkyz - она ​​оценивает предсказуемость и энтропию произвольных данных. Хотя, как я уже упоминал, решать, скорее, компрессору.

borg 1.1 будет иметь 2 "решателя сжатия":

1. выбрать файл на основе совпадения с шаблоном пути ( *.zip , *.mp3 , /htdocs/photos/* , ...)
2. если не определились, выберите для каждого фрагмента, используйте lz4 в качестве теста на сжимаемость - если это сжимает, сжимайте снова с желаемым сжатием (lz4, zlib, lzma), если нет, не сжимайте.

@klauspost хм, этот тест на моей машине не так уж и плох:

BenchmarkCompressibility-4           100      10345544 ns/op     810.84 MB/s

Код теста здесь: https://gist.github.com/908c23123dda275a479cf931f2784f5d

Lz4 не имеет энтропийного кодера, поэтому он будет много раз ложно отрицательным.
наверное?

Думаю, нам нужно три режима (глобально):

• Сжимайте все большие двоичные объекты данных с помощью линейного компрессора времени (по умолчанию)
• Без сжатия
• Максимальное сжатие (для людей с большой мощностью процессора, но с небольшой пропускной способностью)

Я хотел бы всегда сжимать древовидные объекты (JSON), поэтому мы должны выбрать правильный алгоритм для текста ASCII.

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

Мысли?

@klauspost хм, этот тест на моей машине не так уж и плох

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

Думаю, нам нужно три режима (глобально):

Deflate неплохо справляется со всеми тремя, хотя есть более эффективные компрессоры (в основном LZMA). Deflate без сжатия, конечно, не нужен, но он, конечно, быстрый и с минимальными накладными расходами, поэтому можно использовать общий подход deflate с возможностью указать другие позже.

Я начал искать другое ускорение , которое будет между уровнем 1 и Хаффманом как с точки зрения скорости, так и сжатия. Однако на данный момент время немного дорого, и мне все еще нужно протестировать бэкпорт некоторых из последних изменений Go 1.7, прежде чем я смогу перейти к новым вещам.

Если вам нужен только один алгоритм сжатия, вам следует взглянуть на новый конкурент zstd: https://github.com/facebook/zstd

Он был разработан тем же разработчиком, что и lz4, и имеет лучшую степень сжатия, чем gzip, но при этом более чем в 3 раза быстрее: https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with -zstandard /

zstd выглядит очень многообещающе, хотя мне не удалось найти реализации в Go.

Официальный сайт http://facebook.github.io/zstd/#other -languages ​​ссылается на эту реализацию Go: https://github.com/DataDog/zstd

Или вы имеете в виду чистую реализацию Go?

Да, имел ввиду чистую реализацию Go. На данный момент restic не зависит от какого-либо кода C, и в идеале я бы хотел оставить его таким.

Есть ли какие-то прогнозы по внедрению сжатия?

Реализация сжатия зависит от изменения формата репозитория (планирование / идеи находятся в # 628), что требует большой осторожности. Так что нет, точной даты, когда будет добавлено сжатие, нет;)

Что мы можем сделать или внести свой вклад, чтобы это произошло?

Я так не думаю, извините: wink:, просто нужно время.

Итак, я подумал, что могу еще раз использовать свой испытательный стенд из # 790. В моей сборке restic я удалил все шифрование, а затем снова сделал полную резервную копию. Он был того же размера, что и зашифрованный - никаких сюрпризов. Но затем я сжал репозиторий и обнаружил:

35G backup-unencrypted
6.4G    backup-unencrypted.tgz2

Какая разница! Для сравнения, вот размер одного сжатого дампа базы данных:

1.7G    single-backup.sql.gz

У меня 29 из них выше. Экономия примерно в 100 раз по сравнению с обычным резервным копированием!

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

(Я, вероятно, дам себе две недели вечеров, чтобы добиться успеха или неудачи.)

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

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

Самым важным во всем проекте является не код: это формат репозитория. Пользователи доверяют нам свои данные и зависят от возможности восстановления данных после длительного использования restic, поэтому стабильность формата репозитория имеет первостепенное значение. Итак, чтобы поддерживать сжатие, нам сначала нужно решить (и реализовать) следующую версию формата репозитория. Обсуждение здесь: https://github.com/restic/restic/issues/628

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

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

Поскольку мы используем json.Unmarshal мы можем добавить в конфигурацию столько новых ключей, сколько захотим. Если их нет в JSON, они просто сохранят свои значения по умолчанию.

Выбор алгоритма не главное, понял: но на всякий случай ,

Насколько я знаю, сжатие Brotli очень медленное (iirc 60 раз gzip), поэтому его рекомендуется использовать для данных, которые читаются очень часто, по сравнению с записью и сжатием, что, вероятно, не является обычным для резервных копий. Но да, пока не будем вдаваться в подробности :)

Это дает хороший обзор различных алгоритмов сжатия.

Brotli всегда быстрее или имеет лучшее сжатие. Зависит от степени сжатия.

@ibib Как вы пришли к такому выводу? Мне кажется, что brotli медленнее, чем большинство других (в смешанных наборах данных), при этом не достигая особенно удивительной степени сжатия. Может быть, это лучше для конкретных видов структурированных данных?

Как указано в сравнениях в тесте Squash, можно использовать три параметра:

• Достигнутая степень сжатия: насколько хорошо он сжимается, важно для экономии места на диске (и операций ввода-вывода для серверной части).

• Скорость сжатия: важна, потому что мы собираемся выполнять эту операцию каждый раз, когда добавляем блок, поэтому нам действительно нужно что-то, что может идти в ногу с AES-NI и общим вводом-выводом, чтобы не стать узким местом. Вероятно, мы не хотим выбирать алгоритм, который сжимает медленнее, чем распаковывает, поскольку у нас есть вариант использования веб-браузеров, противоположный этим новым алгоритмам (например, zstd , lz4 , brotli ) оптимизированы для (у нас есть «сжимать часто, распаковывать редко» вместо «сжимать один раз, распаковывать часто»).

• Скорость декомпрессии: скорость декомпрессии имеет значение только при восстановлении. Если нас устраивает медленное восстановление, мы можем принять медленную скорость декомпрессии. С другой стороны, у нас также есть метаданные, которые мы не хотим распаковывать медленно, так что это может даже оправдать использование двух разных алгоритмов.

Похоже, что density является одним из самых быстрых, хотя и не особенно эффективным с точки зрения степени сжатия. С точки зрения того, чтобы не быть узким местом, похоже, что он даст нам (в среднем) степень сжатия 2: 1 почти бесплатно. Если мы хотим 4: 1, нам придется выбрать другой алгоритм, но тогда мы будем сидеть и ждать его.

У нас также есть два (как минимум?) Разных типа данных: индексы; и фрагменты данных. Они используются по-разному, и я думаю, можно было бы обсудить, имеет ли смысл выбирать для них разные алгоритмы. Я лично считаю, что мы должны придерживаться одного алгоритма (какой бы мы ни выбрали), чтобы повторная реализация Restic (на новом языке или чем-то еще) не была чрезмерно сложной. И чтобы мы не подвергали себя ошибкам из двух захватывающих алгоритмов сжатия, поскольку их трудно проверить на крайние случаи.

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

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

Помните, что мои тесты с snappy дали следующие результаты: 1) меньший размер резервной копии (она сжимает, нормально) и 2) более быстрое резервное копирование и восстановление (меньше шифрования данных, HMAC и передачи). Используя очень дешевый ноутбук.

@cfcs Я сослался на сравнение gzip и brotli

Здесь у бротли всегда более быстрое и лучшее сжатие.

@Crest Это справедливо, у нас, вероятно, разные варианты использования - я просто не использую restic так, как вы. Я делаю резервные копии своего ноутбука и хочу, чтобы это закончилось быстро, чтобы я мог уйти со своим ноутбуком. Я так понимаю, вы говорите о резервных копиях серверов или других постоянно подключенных машин, где скорость резервного копирования не так важна. Точно так же мне никогда не нужно восстанавливать все мои данные в сжатые сроки; если есть нехватка времени (потому что вы используете его в профессиональном контексте?), я могу выборочно восстановить нужные мне данные и сделать все остальное позже.

Вы очень хорошо замечаете, что «входы во много раз малы»;

@viric Эффект, о котором вы говорите, учитывается в тестах Squash в разделе Transfer + Processing :-)

@ibib а, попался!

@ibib, можешь ли ты связать, откуда у тебя эта диаграмма?

Диаграмма взята с

Я проводил несколько тестов с brotli и zstd и заметил, что мои результаты совсем не совпадают с результатами теста сквоша. Потом я понял, что эталону 1,5 года.

zstd у меня очень хорошо работает. Быстро + высокое соотношение, и его «уровень» позволяет очень большой промежуток между быстрым и высоким коэффициентом. Великая вещь.

Brotli у меня работает очень медленно, степень сжатия не лучше, чем у гораздо более быстрого zstd. И brotli, кажется, ориентирован на небольшие файлы с английскими текстами (он включает английский словарь). Для сжатия HTML или аналогичного.

Я нашел более свежие тесты: https://github.com/inikep/lzbench

Поэтому я еще раз бросил свой тестовый стенд против zbackup со сжатием LZMA.

35G backup-unencrypted
6.4G    backup-unencrypted.tgz
2.5G    zbackup

Впечатляет, правда?

Достаточно сказать, что у zbackup есть свои ограничения и недостатки.

Итак, согласно ссылке @viric lzbench, наиболее подходящий компрессор - это тот, который не замедляет резервное копирование (высокая скорость сжатия ?,> 200 МБ / с), у которого действительно хорошая степень сжатия (> = 50), верно?

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

Я также выполнил _быстрый_ поиск реализаций Go (поэтому я сохранил их в таблице). Зачеркнутый означает, что я не нашел никакой реализации, которая устранила почти все. Поскольку это был всего лишь быстрый поиск, я сохранил результаты. Исключение для zstd - это просто оболочка.

| Название компрессора | Сжатие | Распаковать. Компр. размер | Соотношение |
| --------------- | ----------- | ----------- | ----------- | ----- |
| zstd 1.1.4 -1 | 242 МБ / с | 636 МБ / с | 73654014 | 34,75 |
| ящерица 1.0 -30 | 258 МБ / с | 867 МБ / с | 85727429 | 40,45 |
| плотность 0,12,5 бета -3 | 253 МБ / с | 235 МБ / с | 87622980 | 41,34 |
| gipfeli 13.07.2016 | 233 МБ / с | 451 МБ / с | 87931759 | 41,49 |
| содержательный 24.12.2011 -9 | 257 МБ / с | 1263 МБ / с | 90360813 | 42,63 |
| содержательный 24.12.2011 -6 | 295 МБ / с | 1268 МБ / с | 92090898 | 43,45 |
| quicklz 1.5.0 -1 | 346 МБ / с | 435 МБ / с | 94720562 | 44,69 |
| ящерица 1.0 -20 | 284 МБ / с | 1734 МБ / с | 96924204 | 45,73 |
| содержательный 24.12.2011 -3 | 352 МБ / с | 1222 МБ / с | 97255186 | 45,89 |
| lzrw 15 июля 1991 -4 | 243 МБ / с | 392 МБ / с | 100131356 | 47.24 |
| lzo1x 2.09 -1 | 394 МБ / с | 551 МБ / с | 100572537 | 47.45 |
| lz4 1.7.5 | 452 МБ / с | 2244 МБ / с | 100880800 | 47.60 |
| fastlz 0.1 -2 | 243 МБ / с | 469 МБ / с | 100906072 | 47,61 |
| lzo1y 2.09 -1 | 397 МБ / с | 556 МБ / с | 101258318 | 47,78 |
| lzo1x 2.09 -15 | 406 МБ / с | 549 МБ / с | 101462094 | 47,87 |
| плотность 0,12,5 бета -2 | 480 МБ / с | 655 МБ / с | 101706226 | 47,99 |
| lzf 3,6 -1 | 251 МБ / с | 565 МБ / с | 102041092 | 48.14 |
| мгновенно 1.1.4 | 327 МБ / с | 1075 МБ / с | 102146767 | 48,19 |
| blosclz 10.11.2015 -9 | 220 МБ / с | 696 МБ / с | 102817442 | 48,51 |
| содержательный 24.12.2011 -0 | 384 МБ / с | 1221 МБ / с | 103072463 | 48,63 |
| lzo1x 2.09 -12 | 418 МБ / с | 550 МБ / с | 103238859 | 48,71 |
| ящерица 1.0 -10 | 360 МБ / с | 2625 МБ / с | 103402971 | 48,79 |
| fastlz 0,1 -1 | 235 МБ / с | 461 МБ / с | 104628084 | 49,37 |
| lzrw 15 июля 1991 -3 | 226 МБ / с | 449 МБ / с | 105424168 | 49,74 |
| lzf 3,6 -0 | 244 МБ / с | 550 МБ / с | 105682088 | 49,86 |
| lzo1x 2.09 -11 | 424 МБ / с | 560 МБ / с | 106604629 | 50.30 |
| lz4fast 1.7.5 -3 | 522 МБ / с | 2244 МБ / с | 107066190 | 50,52 |
| торнадо 0.6a -1 | 233 МБ / с | 334 МБ / с | 107381846 | 50,66 |
| memcpy | 8657 МБ / с | 8891 МБ / с | 211947520 | 100.00 |

LZ4 выглядит как самый подходящий компрессор?

думаю, вам нужны lz4 (> = 1.7.0 r129) и zstd (> = 1.3.0), если есть. мы также используем их для borgbackup.

НО zstd очень настраивается одним целым числом, от скорости lz4 до лучшей.
чем сжатие xz. Это сделало бы счастливых пользователей плотной медленнее
сжатие и быстрое сжатие. Не говоря уже о том, что zstd
разжимается очень быстро, независимо от усилия сжатия.

lz4 имеет довольно узкую цель.

В субботу, 16 декабря 2017 г., в 09:50:49 -0800 TW написал:

думаю, вам нужны lz4 и zstd, если таковые имеются. мы также используем их для borgbackup.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/restic/restic/issues/21#issuecomment -352199097

-
(Escriu-me xifrat si saps PGP / Запись в зашифрованном виде, если вы знаете PGP)
Ключ PGP 7CBD1DA5 - https://emailselfdefense.fsf.org/

Что ж ... в соответствии с https://github.com/restic/restic/issues/21#issuecomment -250983311 сохранения restic-зависимостей свободными, zstd пока не подходит. Кроме того, есть несколько тем, касающихся патентов / лицензий.

Что касается xz и высоких коэффициентов сжатия, то даже при более низких настройках сжатия, согласно таблице, самое быстрое сжатие составляет около 15 МБ / с.

Если требования к быстрому резервному копированию снизятся, скажем,> = 30 МБ / с, мы могли бы добавить:

| Название компрессора | Сжатие | Распаковать. Компр. размер | Соотношение |
| --------------- | ----------- | ----------- | ----------- | ----- |
| xz 5.2.3 -9 | 1,70 МБ / с | 56 МБ / с | 48745306 | 23.00 |
| xz 5.2.3 -6 | 1,89 МБ / с | 58 МБ / с | 49195929 | 23.21 |
| xz 5.2.3 -3 | 4,18 МБ / с | 55 МБ / с | 55745125 | 26.30 |
| zstd 1.1.4 -8 | 30 МБ / с | 609 МБ / с | 61021141 | 28,79 |
| zling 10.01.2016 -2 | 32 МБ / с | 136 МБ / с | 61917662 | 29.21 |
| xz 5.2.3 -0 | 15 МБ / с | 44 МБ / с | 62579435 | 29,53 |
| zling 10.01.2016 -0 | 38 МБ / с | 134 МБ / с | 63407921 | 29.92 |
| zstd 1.1.4 -5 | 88 МБ / с | 553 МБ / с | 64998793 | 30,67 |
| lzfse 08.03.2017 | 48 МБ / с | 592 МБ / с | 67624281 | 31.91 |
| libdeflate 0.7 -6 | 64 МБ / с | 609 МБ / с | 67928189 | 32.05 |
| brotli 10.03.2017 -2 | 98 МБ / с | 289 МБ / с | 68085200 | 32.12 |
| zstd 1.1.4 -2 | 185 МБ / с | 587 МБ / с | 70164775 | 33.10 |
| торнадо 0.6a -4 | 91 МБ / с | 197 МБ / с | 70513617 | 33,27 |
| libdeflate 0.7 -3 | 96 МБ / с | 602 МБ / с | 70668968 | 33,34 |
| xpack 2016-06-02 -1 | 98 МБ / с | 506 МБ / с | 71090065 | 33,54 |
| торнадо 0.6a -3 | 119 МБ / с | 188 МБ / с | 72662044 | 34,28 |
| libdeflate 0.7 -1 | 117 МБ / с | 570 МБ / с | 73318371 | 34,59 |
| ящерица 1.0 -42 | 90 МБ / с | 938 МБ / с | 73350988 | 34,61 |
| zstd 1.1.4 -1 | 242 МБ / с | 636 МБ / с | 73654014 | 34,75 |

Существует несколько реализаций deflate, но не уверены, сопоставимы ли они.
Левый xz для справки
zstd выглядит очень многообещающе. Жаль, что нет реализации Go

@viric zstd - это не совсем скорость lz4.

но если вы хотите иметь только один компрессор, а не несколько, zstd более гибок.

Простите за опоздание. Некоторые комментарии:

Скорость сжатия: важна, потому что мы собираемся выполнять эту операцию каждый раз, когда добавляем блок, поэтому нам действительно нужно что-то, что может идти в ногу с AES-NI и общим вводом-выводом, чтобы не стать узким местом. Вероятно, мы не хотим выбирать алгоритм, который сжимает медленнее, чем распаковывает, так как у нас есть противоположный вариант использования веб-браузеров, для которых оптимизированы эти новые алгоритмы (например, zstd, lz4, brotli) (у нас есть «часто сжимать, редко распаковывать» в отличие от «сжимать один раз, часто декомпрессировать»).

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

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

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

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

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

У нас также есть два (как минимум?) Разных типа данных: индексы; и фрагменты данных. Они используются по-разному, и я думаю, можно было бы обсудить, имеет ли смысл выбирать для них разные алгоритмы.

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

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

Я понимаю эти опасения, но думаю, что это было бы ошибкой. По крайней мере, формат репо должен позволять использовать несколько алгоритмов сжатия, чтобы в будущем можно было добавлять новые. Вероятно, должны быть подключаемые модули для сжатия, чтобы пользователи могли выбирать те, которые они хотят использовать, например, я мог бы представить пакеты Debian, такие как restic-xz , restic-zstd и т. Д., Которые пользователи могли бы установить, если бы захотели. используйте эти алгоритмы. Сжатие данных резервных копий должно быть абстрагированным, чтобы restic передавал функции сжатия некоторые данные и возвращал их сжатым, а restic не должен заботиться о том, что происходит между ними; то же самое для декомпрессии.

Если требования к быстрому резервному копированию снизятся, скажем,> = 30 МБ / с, мы могли бы добавить

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

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

Добавлена ​​награда в размере 10 $ за пиво: :)

🍺 ++

Вот ссылка на BountySource, если кто-то еще хотел бы внести свой вклад

https://api.bountysource.com/badge/issue?issue_id=6096108

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

Давай решим, когда мы туда доберемся. Для записи: я не против дать пользователю немного контроля с точки зрения скорости и размера.

+1 для restic, нуждающегося в реализации сжатия. Я использую restic для резервного копирования образов виртуальных машин на backblaze и хотел бы иметь возможность сжать их перед загрузкой. В моем случае использования я бы потратил почти бесконечное количество времени / процессора, чтобы уменьшить размер передаваемых / сохраняемых данных. Я понимаю, что некоторых больше беспокоит скорость. Ключевым моментом является наличие подключаемой архитектуры, в которой можно выбрать несколько алгоритмов.

Я рад помочь в тестировании, так как это будет рассмотрено далее.

@ fd0 Прошло много времени с тех пор, как я работал над базой кода restic. Можете ли вы дать быстрое направление, как лучше подойти и где мне следует искать?

@klauspost Это не столько добавление сжатия на техническом уровне, это довольно просто сделать, сколько то, как мы обрабатываем обновление формата репо обратно совместимым способом. В настоящее время я занят переписыванием части архиватора (чтобы исчезли уродливые вещи вроде # 549), после этого я хотел бы добавить сжатие, а затем переключиться на репо v2.

Как вы думаете, какой алгоритм сжатия нам следует использовать? Думаю о поддержке трех режимов:
1) Без сжатия
2) Сжатие "линейного времени" (не увеличивает нагрузку на процессор)
3) «Максимальное сжатие»

Может первый и второй режим будут одинаковыми, пока не уверен

Было бы здорово иметь возможность использовать что-то вроде zstd, но в качестве нативного кода Go. Дамиан намекнул, что портировать версию для Java или C может быть не так много: https://twitter.com/dgryski/status/947259359628738560, могу ли я что-нибудь сделать, чтобы вы заинтересовались этим? :)

Я просмотрел спецификацию формата zstd, и для меня это нетривиально реализовать (ну). Исходники Java - это только декомпрессия.

Для быстрого сжатия LZ4 подойдет очень хорошо. Порт Go отличный. zstd было бы лучше, но я бы выбрал проверенный пакет, если вы не хотите использовать реализацию cgo.

Для середины дороги сжатие спуска по-прежнему является хорошей скоростью / сжатием. Хорошо протестировано и т. Д.

С высокой степенью сжатия немного сложнее. Однако похоже, что в пакете github.com/ulikunitz/xz есть собственная реализация LZMA (2) Go. Есть некоторые предостережения относительно стабильности и производительности README. В оболочке xz нет необходимости, поскольку у вас уже есть несжатый хэш и размер. Я могу покрутить его и посмотреть, как он сравнивается.

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

Вы также можете взглянуть на "оценщик сжимаемости", который я сделал. Это даст быструю оценку того, насколько сжимаемым является большой объем данных. Обычно он работает со скоростью> 500 МБ / с, поэтому его можно использовать для быстрого отклонения трудно сжимаемых данных.

Вы также можете взглянуть на "оценщик сжимаемости", который я сделал. Это даст быструю оценку того, насколько сжимаемым является большой объем данных. Обычно он работает со скоростью> 500 МБ / с, поэтому его можно использовать для быстрого отклонения трудно сжимаемых данных.

Обожаю оценщик сжимаемости! Избегая попыток сжатия несжимаемых данных, вы получите большую скорость.

Zstd имеет что-то вроде встроенного: [1]

Zstd быстрее передает несжимаемые данные. Ожидайте чего-то> 1 ГБ / с

Хотя я не нашел явных тестов на это.

Пакет xz выглядит неплохо для lzma. Сделал несколько быстрых тестов с настройками по умолчанию:

| алгоритм | уровень | insize | негабаритный | миллис | мб / с | соотношение |
| ----------- | ------- | ------------ | ----------- | ---- ---- | -------- | -------- |
| lz4 | - | 1000000000 | 625968314 | 5454 | 174,85 | 62,60% |
| flatekp | 1 | 1000000000 | 391051805 | 12367 | 77.11 | 39,11% |
| flatekp | 5 | 1000000000 | 342561367 | 20164 | 47,3 | 34,26% |
| flatekp | 9 | 1000000000 | 324191728 | 43351 | 22 | 32,42% |
| lzma2 | | 1000000000 | 291731178 | 149437 | 6.38 | 29,17% |
| lzma | | 1000000000 | 291688775 | 161125 | 5.92 | 29,17% |

Очень разумный компромисс между скоростью и сжатием. Все это одноядерная производительность на enwik9 - средний сжимаемый текст. Очевидно, у меня не было времени на тестирование полного образа виртуальной машины или чего-то вроде корпуса объемом 10 ГБ с более смешанным контентом.

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

Zstd имеет что-то вроде встроенного

Да, как и lz4 и deflate, однако я не видел этого так быстро, как специальная функция.

zstd, несомненно, впечатляет. Тесты с использованием реализации cgo:

| уровень | insize | негабаритный | миллис | мб / с | соотношение |
| ------- | ------------ | ----------- | -------- | ------- - | -------- |
| 1 | 1000000000 | 358512492 | 5100 | 186.96 | 35,85% |
| 2 | 1000000000 | 332265582 | 6264 | 152.24 | 33,23% |
| 3 | 1000000000 | 314403327 | 8099 | 117,75 | 31,44% |
| 4 | 1000000000 | 310346439 | 8588 | 111.04 | 31.03% |
| 5 | 1000000000 | 305644452 | 12739 | 74,86 | 30,56% |
| 6 | 1000000000 | 292551252 | 18531 | 51,46 | 29,26% |
| 7 | 1000000000 | 287414827 | 23212 | 41.08 | 28,74% |
| 8 | 1000000000 | 282783804 | 27811 | 34.29 | 28,28% |
| 9 | 1000000000 | 280432907 | 31752 | 30.03 | 28,04% |

Простите, если я что-то пропустил, но я не видел ответов на эти вопросы раньше.

1. Кажется, мы говорим о сжатии на уровне фрагментов, а не на уровне файлов, верно?
2. Если это так, это, очевидно, ограничивает эффективность, поскольку дублированные данные в нескольких фрагментах одного файла будут храниться и сжиматься для каждого фрагмента.
3. Однако это, очевидно, также зависит от размера блока.
4. Итак, каков средний размер блока? Похоже, это важный фактор в том, насколько полезно сжатие.
5. Если размер фрагмента довольно мал, возможно, нам следует рассмотреть возможность полного сжатия с предварительным фрагментированием для файлов с высокой степенью сжатия (например, с помощью оценщика @klauspost ). Например, текстовый файл размером 50 МБ (например, файлы журнала, большие файлы в режиме организации и т. Д.), Вероятно, будет хорошо сжимаемым как один файл. Но если он сначала разбивается на фрагменты, а затем каждый фрагмент сжимается индивидуально, без совместного использования индекса, это значительно ограничит эффективность сжатия (IIUC).

Спасибо.

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

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

@alphapapa

Кажется, мы говорим о сжатии на уровне фрагментов, а не на уровне файлов, верно?

Да, на уровне фрагментов.

Если это так, это, очевидно, ограничивает эффективность, поскольку дублированные данные в нескольких фрагментах одного файла будут храниться и сжиматься для каждого фрагмента. Однако это, очевидно, также зависит от размера блока. Итак, каков средний размер блока? Похоже, это важный фактор в том, насколько полезно сжатие.

Мы стремимся к 1 МБ, но может быть и 8 МБ.

Если размер фрагмента довольно мал, возможно, нам следует рассмотреть возможность полного сжатия с предварительным фрагментированием для файлов с высокой степенью сжатия (например, с помощью оценщика @klauspost ). Например, текстовый файл размером 50 МБ (например, файлы журнала, большие файлы в режиме организации и т. Д.), Вероятно, будет хорошо сжимаемым как один файл. Но если он сначала разбивается на фрагменты, а затем каждый фрагмент сжимается индивидуально, без совместного использования индекса, это значительно ограничит эффективность сжатия (IIUC).

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

@klauspost Большое спасибо за то, что cgo гораздо важнее для проекта в целом. И использование оценщика сжимаемости - отличная идея, мне это нравится.

Места, которые вы упомянули для добавления сжатия / декомпрессии, звучат хорошо, но нам нужно отслеживать метаданные для этого где-то еще. Я думаю , что мы , вероятно , добавить смысл битов в байте в заголовке пакета, см http://restic.readthedocs.io/en/latest/100_references.html#pack -format. Это та часть, которую нужно делать очень осторожно.

Итак, позвольте мне закончить с # 1494, тогда мы увидим, что это разрешится.

@sanmai re: побочные каналы: Я изначально
Предлагались разные решения, лично меня бы удовлетворило:

• наличие параметров конфигурации для внесения в белый / черный список использования сжатия (аналогично тому, что у нас есть для включения файлов)

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

Это было бы здорово! : beer: + 10 $

Просто выбросьте его туда, но оставив в стороне lzma или любой из более общих алгоритмов сжатия, как насчет простого кодирования длины прогона или сжатия нуля? Или это будет недостаточно полезно для достаточного количества людей?

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

+ $ 15

Просто выбросьте его туда, но оставив в стороне lzma или любой из более общих алгоритмов сжатия, как насчет простого кодирования длины прогона или сжатия нуля? Или это будет недостаточно полезно для достаточного количества людей?

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

@bherila restic пока не поддерживает архивирование / восстановление разреженных файлов, файлы будут храниться в репо, как если бы они просто содержали много нулей. Эти большие блоки нулей дедуплицируются, поэтому они не будут занимать много места в репо. Однако для восстановления вы получите обычный (не разреженный) файл без «дырок».

Просто хотел проверить, есть ли уже какое-то сжатие? Я сделал резервную копию нескольких компьютеров, в том числе одного с 50 ГБ данных, и у меня на сервере гораздо меньшее число:

# du -shc /home/restic/
40G     /home/restic/
40G     total

@Alwaysin Вероятно, это дедупликация , если, конечно, некоторые файлы не были исключены.

@rawtaz спасибо, я не знал о дедупликации, должно быть!

@iluvcapra сжатие больших повторяющихся блоков уже реализовано посредством дедупликации, как упоминалось в @rawtaz.

@klauspost ты это видел? https://github.com/mvdan/zstd

Да, но, честно говоря, потоковый декодер - это самая простая часть. Я закончил кодирование / декодирование FSE и подготовил кодировщик Хаффмана. После завершения декодирования по Хаффману декодер потока zstd становится довольно простым, а полный кодировщик является последней частью.

LZ4 вполне достаточно, и он также будет быстрой победой.

Почему бы не добавить lz4 и не создать еще один PR в поддержку zstd?

Почему бы не добавить lz4 и не создать еще один PR в поддержку zstd?

@ dave-fl, потому что нам нужно быть очень осторожными при изменении формата репозитория. Это должно быть сделано обратно совместимым способом. Самая важная часть всего проекта - это формат репо, а не реализация. Люди зависят от нас, чтобы мы не испортили формат, чтобы они могли восстановить свои данные :)

Думаю, со сжатием нельзя ждать слишком долго. Я только что провел несколько тестов на нескольких репозиториях резервных копий серверов, я ничего не выиграл, когда я сжал репозиторий! Как и @Alwaysin, я уже выигрываю 30% с дедупликацией.

Насчет обратной совместимости, вы имеете в виду, что Restic должен читать оба формата или инструменты для перехода со старого на новый? Когда Restic не на v1.0.0, я считаю, что можно просто мигрировать.

Я только что провел несколько тестов на нескольких репозиториях резервных копий серверов, я ничего не выигрываю, когда я gzip репозиторий!

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

Я не понимаю, как использование LZ4 делает вещи несовместимыми с предыдущими версиями. Сжатие есть сжатие. Почему бы не поддерживать несколько форматов?

Ты прав, я не думал об этом.
Однако когда я сжимаю исходный код, я не получаю больше 30%, дедупликация уже очень эффективна в большом каталоге с множеством дубликатов. Но, конечно, оба варианта могут произвести впечатление.
С zpaq, который выполняет сжатие и дедупликацию, я выигрываю немного больше, не так много.
Я очень открыт для тестирования ветки со сжатием, неважно, если она несовместима!

Я не понимаю, как использование LZ4 делает вещи несовместимыми с предыдущими версиями. Сжатие есть сжатие. Почему бы не поддерживать несколько форматов?

Что произойдет, если 2 клиента используют одно и то же репо, но один из них использует старую версию restic, которая не поддерживает сжатие? Эта функция должна быть тщательно спроектирована с учетом всех возможных угловых ситуаций.

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

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

Пожалуйста, не добавляйте никаких комментариев, спасибо!

@dimejo То, что вы

Осмелюсь сказать, что CGO-версия zstd выглядит несколько портативной :)

Я посмотрел, насколько возможно было бы написать реализацию zstd на golang, очень кратко, на основе спецификации .

zstd в основном использует собственные алгоритмы, но (необязательно) полагается на контрольную сумму xxHash-64 для проверки ошибок, и для этого есть порт golang . поскольку необязательные биты, ну, необязательны, вам не нужно реализовывать эти части, чтобы получить поддержку zstd для чтения / записи в restic. zstd поддерживает концепцию «словарей» для оптимизации сжатия - я не уверен, как это будет взаимодействовать с restict, но было бы интересной областью исследований для сжатия определенных частей архива, например JSON или потоков метаданных. в противном случае эту реализацию также можно было бы пропустить, поскольку она не является обязательной.

Там, где это становится сложнее, конечно, начинается энтропийное кодирование. Zstd использует новый подход, называемый энтропией конечного состояния (FSE, вариант [ANS] (https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#, из которых также существует только реализация C. Другие биты энтропийного кодирования реализованы с помощью кодирования Хаффмана , из которых существует несколько реализаций, в том числе две в стандартной библиотеке: одна в compress.flate и другая в net.http2.hpack , которая является довольно странно.

Насколько я могу судить, все остальное приклеено поверх этого ... Некоторые деревья Хаффмана, последовательности, фреймы и блоки. Есть интересные свойства в способе построения блоков и фреймов, которые могут хорошо отображаться в restic blobs, что может позволить сжимать репозиторий в целом, сохраняя отдельные капли внутри, хотя я не рассматривал это подробно. . Это также может сделать неприемлемой связь между форматом репозитория и сжатием.

zstd в значительной степени сложнее, чем gzip или xzip, с примерно 70 КБ строк кода (согласно cloc) по сравнению с 36 КБ и 12 КБ, соответственно. это включает, однако, многочисленные тесты: когда они игнорируются, сама реализация примерно сравнима с gzip (~ 34 КБ).

Итак, вкратце, внедрение этого в go - лишь вопрос времени. Я считаю, что такой движок может также использовать параллелизм golang, потому что «фреймы» zstd независимы друг от друга. Однако мне неясно, как используются кадры: большинство потоков, которые я тестировал, имели только один ( zstd /etc/motd ) или два ( zstd isos/Fedora-Workstation-Live-x86_64-27-1.6.iso ) кадра (по данным binwalk -R "\x28\xb5\x2f\xfd" ), так что, может быть, там нет такого выигрыша, потому что блоки взаимосвязаны и менее распараллеливаемы ...

в любом случае, все это спорно, если кто-то здесь не захочет сесть и портировать это, но я решил, что поделюсь тем, что нашел, читая эту вещь ... учитывая, что zstd является расширением LZMA, части компрессоров LZ77, это не должно портировать нереально ...

Есть новости о сжатии? Я знаю, что многие люди хотят дождаться zstd , но что будет плохого в реализации lz4 lzo или lzma ?

Если бы было обновление, эта проблема была бы обновлена.

А пока попробуем уважать просьбу автора:

Пожалуйста, не добавляйте никаких комментариев, спасибо!

@ fd0 , просто хотел указать, что, похоже, существует чистая реализация алгоритма zstd на Go https://github.com/klauspost/compress/tree/master/zstd . Сам не пробовал. Но это взволновало меня возможностью поддержки сжатия в рестике.

Я не знаю материала Go zstd (скорость? Качество кода? Обслуживание?), Но материал C zstd - это все, что нужно инструменту резервного копирования, поскольку он поддерживает широкий диапазон от быстрого / небольшого до более медленного / высокого сжатия.

Если бы у нас еще не было всех других алгоритмов сжатия (lz4, zlib, lzma) в borgbackup и мы начали бы добавлять сжатие сейчас, думаю, мы могли бы жить только с zstd и none.

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

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

Спасибо @ fd0 и всем участникам!

@filippobottega, если вы не заметили большой разницы в своем эксперименте, это означает:

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

и то, и другое не означает, что сжатие бессмысленно.

@ThomasWaldmann Я не вижу большой разницы по первой причине.
Сегодня данные уже сжаты разными способами: docx, xlsx, pptx, zip, 7z, jpeg, tif и так далее - все это сжатые форматы. А также изображения iso содержат сжатые файлы. По этой причине я считаю, что в рестике компрессия бессмысленна.

@filippobottega Вы немного ограничены в том, какие данные люди используют restic для резервного копирования. А как насчет дампа SQL, исходного кода, наборов данных, необработанных изображений и так далее? Дедупликация отлично справляется с уменьшением разницы между резервными копиями, однако ничего не делает для уменьшения исходного размера набора данных. В случае несжатых форматов это может означать много гигабайт. Не говоря уже о том, что сохранение несжатого формата и последующее сжатие + дедупликация может дать лучшие результаты, чем дедупликация уже сжатых файлов.

Дампы SQL были моей первой мыслью, но restic также выполняет резервное копирование моего почтового сервера, и, по-видимому, общее сжатие улучшается на основе некоторых снимков RAR, которые я сделал при переходе с Duplicati на restic.

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

@mrschyte

Вы немного ограничены в том, какие данные люди используют restic для резервного копирования.

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

А как насчет дампов SQL

Вы действительно храните свои SQL-дампы в несжатом виде? Я собираю все свои перед резервным копированием, потому что мне не нужно хранить их в сыром виде.

исходный код, наборы данных, необработанные изображения и т. д.

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

однако он ничего не делает для уменьшения исходного размера набора данных.

Возможно, это не работа программы резервного копирования. Это не должно касаться исходных данных.

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

Многие алгоритмы сжатия полагаются на дублирование для выполнения своей работы (см. Словари flate), поэтому меня это _ в целом_ не убеждает, хотя я согласен, что это правильно, по крайней мере, несколько раз.

(Я не говорю, что сжатие в состоянии покоя _ плохо_, если оно сделано правильно, я просто утверждаю, что это не должно быть приоритетом - особенно по сравнению с затянувшимися проблемами производительности - и мы должны уважать временные ограничения @ fd0 и пожелания относительно видения.)

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

Попробуйте этот тест.

1. взять дамп SQL или какой-нибудь другой несжатый файл. Сожмите его, а затем
   используйте restic, сделайте резервную копию.
2. удалить таблицу из базы данных SQL, сделать второй дамп, затем сжать его,
   затем используйте restic для резервного копирования.

Я думаю, вы это обнаружите, потому что сжатие выполняется ДО
дедупликации вы почти полностью победите алгоритм дедупликации restics.
Однако, если restic может обрабатывать сжатие ПОСЛЕ дедупликации вас
должен получить гораздо меньший общий выход.

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

Пт, 2 августа 2019 г., 13:29 Брэндон Шнайдер [email protected]
написал:

@mholt https://github.com/mholt Я бы согласен в целом, но делая
корневую резервную копию (через некоторый дамп или даже повторение содержимого /),
дает хорошую степень сжатия для меня. Не существенно , так как общая
уже используется мало, но я получаю около 50% экономии, и это всегда приятно
иметь "бесплатно" для конечного пользователя.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/restic/restic/issues/21?email_source=notifications&email_token=AC3I762ZVGTTJL4TF3ODZILQCRVIXA5CNFSM4AXPP352YY3PNVWWK3TUL52HS4DFVREXG43L78VMVBWueG63L78VMVBWW
или отключить поток
https://github.com/notifications/unsubscribe-auth/AC3I767IQQD3CZBIWM37C6TQCRVIXANCNFSM4AXPP35Q
.

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

Такое ощущение, что такое представление мешает эффективному хранению данных? Я пытаюсь отказаться от идеи, что каждая программа и операция экспорта должны реализовывать свой собственный формат сжатия adhoc, потому что он предотвращает дедупликацию / сжатие / и т.д. . При сжатии файлов по отдельности теряется возможность найти общность для разных файлов / дампов / и т. Д., И впоследствии вы теряете все преимущества дедупликации. Сохранение файлов в несжатом виде позволяет файловой системе (zfs, btrfs и т. Д.) Делать все это за вас, и даже лучше, поскольку она может как сжимать, так и выводить дубликаты по папкам, снимкам и т. Д. И абстрагироваться от всего этого, сохраняя при этом совместимость с инструментами, которые должны работать. с несжатыми данными.

Сжатие можно рассматривать как просто дополнительную оптимизацию дедупликации top restic, но они кажутся несовместимыми друг с другом, если выполняется по отдельности ... Предложение о том, что нужно сжимать и предварительно обрабатывать файлы перед их резервным копированием, возвращает все обратно в рабочий процесс, где вы также можете просто используйте вместо этого rsync / rclone, так зачем вообще использовать restic?

Такое ощущение, что такое представление мешает эффективному хранению данных? Я пытаюсь отказаться от идеи, что каждая программа и операция экспорта должны реализовывать свой собственный формат сжатия adhoc, потому что он предотвращает дедупликацию / сжатие / и т.д. . При сжатии файлов по отдельности теряется возможность найти общность для разных файлов / дампов / и т. Д., И впоследствии вы теряете все преимущества дедупликации. Сохранение файлов в несжатом виде позволяет файловой системе (zfs, btrfs и т. Д.) Делать все это за вас, и даже лучше, поскольку она может как сжимать, так и выводить дубликаты по папкам, снимкам и т. Д. И абстрагироваться от всего этого, сохраняя при этом совместимость с инструментами, которые должны работать. с несжатыми данными.

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

Теперь есть случаи, когда имеет смысл сжимать перед сохранением, особенно с очень сжимаемыми данными в медленных системах хранения, но это скорее исключение, чем правило, по моему опыту.

+1 сжатие мне бы очень помогло! Работая инженером-программистом, я создаю резервную копию всей своей домашней папки, в которой много несжатого исходного кода (а на динамических языках, таких как ruby ​​или python, это почти всегда исходный код - даже большинство зависимостей).

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

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

Конечно, есть много классов файлов, которые плохо сжимаются, но никто не говорит, что их нужно принудительно сжимать. Есть много подходов для решения этой проблемы - белый список, какие типы файлов должны быть сжаты, черный список, какие файлы не должны быть, или даже самый простой: попробуйте сжать, и, если результирующий размер не улучшится, сохраните несжатый (я считаю, ZFS использует этот подход, когда включено сжатие на диске).

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

Наконец, я сделал резервную копию чуть более 4 ТБ облачному провайдеру, и моя скорость загрузки в любом случае мала, поэтому, поскольку бонусное сжатие сделает мой процесс резервного копирования быстрее, а не медленнее - мой процессор может более чем справляться с моим плохим VDSL-соединением. .

Да, я могу просто согласиться со всеми остальными здесь. Компрессия очень важна, и я не вижу аргументов, почему в рестике ее не должно быть.

@mholt Полностью согласен с вами. Каждое слово.
В моей цепочке инструментов сжатие происходит до рестической дедупликации, потому что, например, я использую TFS в качестве системы управления версиями, и все источники уже сжаты в резервных копиях SQL, а образы приложений сжимаются в установочных файлах msi или в архивах 7z. Мне нужен только быстрый и простой способ получать ежедневную дельту и отправлять ее в облако, чтобы реализовать безопасный план аварийного восстановления.
Я думаю, что @ fd0 нужно сосредоточить свое время на решении проблем, а не на попытках добавить дополнительную сложность к продукту.

Просто подключаюсь к небольшому сравнению, которое я провел между borg, использующим сжатие auto,zstd и restic (без сжатия), сначала на / , затем на /home , исключая такие вещи, как изображения виртуальных машин и образы докеров (поскольку я тоже не создаю их резервные копии в реальном мире). Тестовая машина была моей машиной для ежедневной разработки программного обеспечения, которая содержит множество двоичных файлов, некоторые сжатые изображения и аудиофайлы, а также изрядное количество исходного текста в виде открытого текста, который должен хорошо сжиматься:

/ : 1053136 файлов, 92,9 ГиБ

• borg, нет: 17:27 мин, 64,1 ГиБ
• borg, zstd: 19:29 мин, 40,6 ГиБ
• restic: 09:45 мин., 62,4 ГиБ

/home : 221338 файлов, 58,3 ГиБ

• borg, zstd: 09:06 мин, 30,7 ГиБ
• restic: 04:36 мин., 39,4 ГиБ
  Я пропустил здесь borg без сжатия, поскольку он примерно такой же, как restic, в том, что касается места для хранения.

Во-первых, я хочу похвалить restic за то, что он почти в два раза быстрее в этом тестовом примере. Помимо того, что borg работает медленнее, может быть интересно то, что сжатие добавляет только ~ 2 минуты к общей продолжительности резервного копирования (+ 11%), но значительно сокращает объем данных, которые нужно сохранить для случая / (-35 %). В случае моего домашнего каталога экономия памяти составляет примерно 20%.

(В этом случае тест проводился на внешнем диске. При резервном копировании в удаленное хранилище время резервного копирования в основном зависит от пропускной способности загрузки, по крайней мере, когда скорость ЦП и ввода-вывода намного выше, чем в сети. Я тестировал this и borg со сжатием на самом деле быстрее, чем restic, потому что сжатие приводит к передаче меньшего количества данных). В общем, я очень сторонник поддержки сжатия для restic, в идеале с использованием автоопределения для проверки того, выигрывает ли фрагмент от сжатия.

@nioncode Если мои расчеты верны, вы создаете резервную копию примерно 100/150 МБ / с. Это ниже того, что может сжать zstd. Поскольку сжатие является асинхронным, замедления быть не должно. Это может быть даже немного быстрее, так как писать меньше.

Я знаю, что архивирование виртуальных машин может быть вариантом использования, но я стараюсь избежать необходимости в этом.
Я пытаюсь автоматизировать все построение виртуальной машины, начиная с файлов iso и setup.
В случае аварийного восстановления я хочу иметь возможность восстановить всю виртуальную машину, используя резервную копию установочных файлов, документов и резервных копий баз данных. И я пытаюсь сделать это без взаимодействия с пользователем.
Таким образом я могу избежать необходимости сжимать и создавать резервные копии множества мусорных файлов, содержащихся на виртуальной машине, таких как временные файлы, несжатые файлы, такие как exe и dll, и т. Д.
Я знаю, это непросто, но я могу избежать сжатия и дедупликации одних и тех же и бесполезных ГБ файлов, экономя дисковое пространство и пропускную способность.

Давайте не будем загромождать эту тему о том, кто как что делает. Этого было достаточно.

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

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

Во всяком случае, обе стороны высказались.

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

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

Я не верю, что кто-то говорит об обязательном сжатии.

Мой особый вариант использования - резервное копирование БОЛЬШИХ наборов дампов CSV и SQL. Эти файлы были бы ОЧЕНЬ сжимаемыми ... и я не хочу / не могу их предварительно сжать.

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

Поскольку сейчас это обсуждение становится немного более активным, я хотел бы поделиться некоторыми выводами, которые я получил с исправленной рестик-версией некоторых моих друзей. Они добавили сжатие в restic (более или менее быстрое и грязное, насколько я знаю), и я уведомлю их об этом посте, чтобы они могли прокомментировать особенности реализации, если кому-то интересно.
Мой вариант использования - это действительно уродливое банковское программное обеспечение, у которого есть собственный формат базы данных. Мы должны использовать это программное обеспечение по нормативным причинам, и данные, которые у нас есть, представляют собой несколько ТБ довольно больших файлов, которые можно сжать до 90% от их исходного размера. Таким образом, вполне очевидно, что сжатие позволит нам значительно сэкономить на хранилище резервных копий, времени резервного копирования и времени восстановления.
Мои результаты при сравнении restic upstream, исправленного restic со сжатием и нашего текущего решения для резервного копирования с tar можно найти здесь: https://gist.github.com/joerg/b88bf1de0ce824894ffc38f597cfef5f

| Инструмент | Время резервного копирования (м: с) | Время восстановления (м: с) | Место для резервного копирования (G) | Место для резервного копирования (%) | Резервное копирование (МБ / с) | Восстановить (МБ / с) |
| --------------------------- | ----------------- | ------------------ | ---------------- | ---------------- | ------------- | -------------- |
| Деготь | 4:42 | 5:19 | 11 | 9,6% | 404 | 357 |
| Restic S3 локальный апстрим | 10:04 | 30:56 | 102 | 89,5% | 189 | 61 |
| Restic S3 local Compress | 5:43 | 19:28 | 8,6 | 7,5% | 332 | 98 |
| Restic Local Upstream | 8:33 | 26:06 | 102 | 89,5% | 222 | 73 |
| Restic Local Compress | 5:21 | 16:57 | 8,6 | 7,5% | 355 | 112 |
| Restic S3 Remote Upstream | 17:12 | 46:06 | 102 | 89,5% | 110 | 41 |
| Restic S3 Remote Compress | 5:27 | 21:42 | 8,6 | 7,5% | 349 | 88 |

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

Не каждый файл будет иметь интересную степень сжатия. Сжатие видеофайла, вероятно, бесполезно, но сжатие дампа SQL, безусловно, бесполезно. Вот почему файловые системы, такие как Btrfs, сначала пытаются сжать первые 128 КБ файла, а при значительной степени сжатия затем сжимают весь файл. Это определенно не идеально, но это быстро и должно работать в большинстве случаев, если решено сжимать файлы по отдельности.

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

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

Привет @joerg , спасибо, что поделились своими тестами.
Вы пробовали выполнить резервное копирование с помощью restic вывода задачи сжатия Tar?
Мне любопытно сравнить "Restic S3 Remote Compress" и "Tar" + "Restic S3 Remote Upstream".
Более того, то, что вы говорите, кажется не совсем правдой:

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

Видя результаты теста, кажется, что процессорное время, необходимое для restic, в 2 раза больше для локального резервного копирования и в 6 раз больше для восстановления. Не очень хорошо по сравнению с Tar.

tar не является алгоритмом сжатия. конечно быстро.
РЕДАКТИРОВАТЬ: да и кстати. если вы заархивируете каталог, он не будет использовать несколько потоков для каждого файла, а также не будет работать с двумя или более файлами одновременно, вместо этого он просканирует каталог и добавит файл, а затем перейдет к следующему. довольно медленно. но проблема в архивном файле, который не предназначен для добавления в несколько потоков.

Видя результаты теста, кажется, что процессорное время, используемое restic, в 2 раза медленнее при локальном резервном копировании и в 6 раз медленнее при восстановлении. Не очень хорошо по сравнению с Tar.

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

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

@joerg Могут ли ваши друзья открыть запрос на слияние и сделать свои патчи для восстановления со сжатием общедоступными? Какой алгоритм сжатия они используют?

@joerg @thedaveCA
Прошу прощения , я неправильно понял смысл утверждения

Пожалуйста, помните, что мы не используем только tar-архивы, а gzip-архивы tar со специальной реализацией параллельного zip, иначе архивирование терабайт данных заняло бы дни, а не «просто» часы, которые требуются прямо сейчас: https: //gist.github. com / joerg / b88bf1de0ce824894ffc38f597cfef5f # tarpigz
@shibumi Я проинформировал их об этой проблеме и своей публикации, так что теперь им решать, хотят ли они участвовать в этом и насколько далеко. Лично я надеюсь, что они откроют этот пул-реквест ...

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

Давайте не будем создавать известную проблему там, где ее нет, не так ли?

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

Почему вы рассылаете спам? :( Это столько раз обсуждалось, что это почти оффтоп. Вы НЕ ПРИНУДИТЕ включать сжатие !!

Более того, я думаю, что ваша идея атаки требует, чтобы злоумышленник мог контролировать сжатие и шифрование данных (хотя я не уверен!). https://en.m.wikipedia.org/wiki/CRIME

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

Наличие даже дополнительной функции, ослабляющей шифрование, вызывает ложное чувство безопасности. Restic утверждает, что является _безопасной_ программой резервного копирования. Добавление необязательного сжатия аннулирует это обещание, поскольку иногда вы не можете быть в безопасности, только полный рабочий день, все время. И, конечно, будут отчеты о CVE. Кому нужна такая «популярность» для своего программного обеспечения?

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

FWIW в 2017 году я сделал демонстрацию, в которой убрал шифрование с Restic и показал, что сжатие может быть очень эффективным . В сто раз эффективен. Сжатие IIRC может быть добавлено как своего рода оболочка, как и шифрование, но я долгое время не смотрел на код, поэтому в наши дни все может быть сложнее или проще.

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

на самом деле ПРЕСТУПНОСТЬ должна знать длину зашифрованного текста

ПРЕСТУПЛЕНИЕ нужно, а вам нет. Представьте, что вы журналист-расследователь, получивший от источника набор совершенно секретных файлов. Вы делаете их резервную копию с помощью шифрования, и никто не узнает, что у вас есть эти файлы.

Теперь представьте, что вы не были достаточно умны, чтобы включить сжатие, и теперь все остальные, у кого тоже есть эти файлы, судя по размерам сжатых, а затем зашифрованных фрагментов, будут знать, что у вас есть эти совершенно секретные файлы в этом архиве без даже нужно знать ключ шифрования. Это далеко не безопасно. Люди могут попасть в тюрьму из-за этой «особенности», подвергнуться пыткам или того хуже.

нет "безопасной" программы резервного копирования

Затем необходимо обновление.

Также обратите внимание на безопасный по умолчанию.

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

Пт, 09.08.2019 в 02:09:23 -0700 Алексей Копытко написал:

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

Давайте не будем создавать известную проблему там, где ее нет, не так ли?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/restic/restic/issues/21#issuecomment -519844526

-
(Escriu-me xifrat si saps PGP / Запись в зашифрованном виде, если вы знаете PGP)
Ключ PGP 7CBD1DA5 - https://emailselfdefense.fsf.org/

Для тех, кто хочет узнать больше об этих проблемах безопасности, есть хороший документ с описанием этого http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf
Насколько я понимаю, может быть недостаток, если файл разбивается на части, а затем сжимается и зашифровывается. Но если файл сжимается перед фрагментированием, это двоичный файл, как и любой другой, и эти атаки с открытым текстом становятся бесполезными.

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

Это правильно. Но это не совсем поможет с эффективной дедупликацией, если я правильно понимаю, поскольку алгоритм сжатия может использовать другой словарь для каждой версии файла, что приводит к очень разному двоичному результату. Что, очевидно, не будет дедуплицироваться. Иначе говоря, имеет смысл только сжимать полученные куски.

restic хранит только упакованные куски, поэтому размер кусков не очевиден для тех, у кого нет ключей

Какое облегчение.

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

Кстати.:

However, it is important to note that these attacks have little security impact on, say, a bulkencryption application which compresses data before encrypting

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

ПРЕСТУПЛЕНИЕ нужно, а вам нет. Представьте, что вы журналист-расследователь, получивший от источника набор совершенно секретных файлов. Вы делаете их резервную копию с помощью шифрования, и никто не узнает, что у вас есть эти файлы.

Теперь представьте, что вы не были достаточно умны, чтобы включить сжатие, и теперь все остальные, у кого тоже есть эти файлы, судя по размерам сжатых, а затем зашифрованных фрагментов, будут знать, что у вас есть эти совершенно секретные файлы в этом архиве без даже нужно знать ключ шифрования. Это далеко не безопасно. Люди могут попасть в тюрьму из-за этой «особенности», подвергнуться пыткам или того хуже.

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

@sanmai , я не получаю этот пример с

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

Что подразумевается? Кто-то может догадаться, что эти файлы есть в зашифрованном снимке, просто взглянув на размер? Это предполагает, что файлы сжимаются отдельно или вместе с другими известными файлами. Но тогда то же самое можно сделать и с незашифрованным шепшотом.

Собственно, как насчет сжатия файлов перед резервным копированием? Открывает ли это уязвимость системы безопасности?

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

Я не верю, что сжатие может значительно снизить безопасность шифрования.

Большинство атак со сжатием по побочным каналам включает несколько факторов:
1) Злоумышленник может контролировать ввод
2) Злоумышленник может наблюдать размер вывода
3) Небольшие изменения входных данных приводят к измеримым изменениям размера выходных данных.
4) Злоумышленник может изменить ввод и повторить попытку сотни тысяч раз.

В отличие от веб-систем, которые в подавляющем большинстве случаев связаны с восстановлением резервных копий, (1) и (2) редко сохраняются одновременно. Более того, для блочного сжатия (3) на самом деле не гарантируется, и для большинства режимов резервного копирования (4) определенно не выполняется. Поскольку периодичность резервного копирования обычно составляет один раз в день или около того, потребуются тысячи лет, чтобы иметь возможность манипулировать данными и контролировать размер сжатых выходных данных, чтобы заметить какие-либо существенные различия, и это при условии, что никакие другие данные не меняются, что в большинстве случаев было бы.

Если вы делали резервные копии, в которых был виден выходной размер, возможно, вы захотите отключить сжатие. В противном случае на него действительно не существует практических атак, и его включение не сделало бы его менее безопасным.

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

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

честно говоря .... Я предпочитаю концепцию restic ... но я провел тесты в моем сценарии использования (много файлов CSV и дампа SQL) и мне пришлось переключиться на borg.

Я тестировал четыре поколения инкрементного резервного копирования, и мои файлы получили сжатие 7: 1, а вместе с дедупликацией я добился> 20: 1. Я не могу игнорировать это, поскольку уже сказал, что плачу за свое онлайн-хранилище резервных копий за гигабайт.

root<strong i="7">@xxxx</strong>:~# borg list
2019-08-08_14:37                     Thu, 2019-08-08 14:37:10 [5e113a8102f2bd7e40d100343f849dc73843d145011c7214d5fa0895927eb6d1]
2019-08-08_22:28                     Thu, 2019-08-08 22:28:21 [17d815d000212a576610b2fd5688ab87cce00039bb89f63722c6a7819dec1821]
2019-08-09_02:00                     Fri, 2019-08-09 02:00:23 [217c53b07f30dfbca584c49468cfa624a2445a005890220509c97715f7007e81]
2019-08-10_02:00                     Sat, 2019-08-10 02:00:10 [5dd45b8ccf0aa382bf00d5b08e1d5d88daae014f0a1a42b3e2b0fc368623bba0]
root<strong i="8">@xxxx</strong>:~# borg info
Repository ID: xxxx
Location: ssh://xxxx
Encrypted: Yes (repokey)
Cache: /var/lib/borg/cache/xxxx
Security dir: /var/lib/borg/security/xxxx
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:               69.02 GB             11.24 GB              2.80 GB

                       Unique chunks         Total chunks
Chunk index:                    9227                41812

Что подразумевается? Что кто-то может _ предположить_, что зашифрованный снимок содержит эти файлы, просто взглянув на размер? Это предполагает, что файлы сжимаются отдельно или вместе с другими известными файлами. Но тогда то же самое можно сделать и с незашифрованным шепшотом.

Точно. Разрежьте простой текстовый файл на равные части, затем сожмите и зашифруйте. Снова нарежьте, сожмите и зашифруйте. Поскольку размеры зашифрованных файлов не меняются с точки зрения AES, вы увидите, что в обоих случаях у вас есть размеры диапазона, которые соответствуют друг другу, как отпечаток пальца. Они (и под ними я имею в виду, в основном, администрации репрессивных режимов, таких как Иран или Россия) могут сделать разумное предположение, что эти файлы присутствуют здесь, что, таким образом, дает повод, скажем, для продолжения пыток подозреваемого. Я не понимаю, почему вас так обижают эти идеи, разве их не так просто понять? Это не ПРЕСТУПЛЕНИЕ как таковое, не так ли?

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

Подвергает ли добавление сжатия Restic какой-либо дополнительной уязвимости, учитывая, что он уже выполняет дедупликацию?

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

Если бы злоумышленник мог видеть несжатые И сжатые размеры каждого файла, тогда идентификация могла бы стать более реалистичной, но это было бы невозможно в режиме restic.

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

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

Ребята, вы пользуетесь ZIP или GZ? Тогда все будет в порядке.

Вы думаете, что иранские власти могут угадать мой контент по размерам? Тогда просто не используйте сжатие (!). Это просто не означает, что сжатие не должно быть доступно.

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

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

Мне кажется, что это обсуждение выходит из-под контроля, поэтому я пока блокирую эту проблему. Если вы хотите продолжить это обсуждение, перейдите на форум . Спасибо!