Saat menerapkan ini, tambahkan tolok ukur dan terutama lihat penggunaan memori dengan -benchmem dan benchcmp!

lz4, lzo, lzma, null. bz2 agak lambat.

snappy cepat dengan kompresi sedang

Jika kompresi dilakukan per-chunk, harus berhati-hati agar tidak membiarkan backup restic terbuka terhadap serangan watermarking/fingerprinting.

Ini pada dasarnya adalah masalah yang sama yang kami diskusikan terkait dengan sidik jari proses deduplikasi CDC:
Dengan CDC "naif", file "teks biasa yang diketahui" dapat diverifikasi keberadaannya dalam cadangan jika ukuran blok individu dapat diamati oleh penyerang, dengan menggunakan CDC pada file secara paralel dan membandingkan jumlah potongan dan individu yang dihasilkan. panjang potongan.
Seperti yang dibahas sebelumnya, ini dapat sedikit dikurangi dengan mengasinkan algoritma CDC dengan nilai rahasia, seperti yang dilakukan di loteng.

Dengan CDC asin, saya berasumsi kompresi akan terjadi pada setiap potongan individu, setelah membagi file yang bermasalah menjadi potongan-potongan. Potongan restic berada di kisaran 512 KB hingga 8 MB (tetapi tidak terdistribusi secara merata - bukan?).

• Penyerang mengetahui bahwa algoritme CDC menggunakan garam rahasia, sehingga penyerang menghasilkan rentang potongan yang terdiri dari 512 KB pertama hingga 8 MB file, satu untuk setiap panjang potongan yang valid. Penyerang juga dapat menentukan panjang potongan terkompresi.
• Penyerang kemudian mengompres potongan itu menggunakan algoritma kompresi.
• Penyerang membandingkan panjang potongan yang dihasilkan dengan potongan pertama di set cadangan restic.
• JIKA panjang blok yang cocok ditemukan, penyerang mengulangi latihan dengan potongan berikutnya, dan potongan berikutnya, dan potongan berikutnya, ... dan potongan berikutnya.
• Ini adalah keyakinan saya bahwa dengan file yang cukup besar, dan mengingat fakta bahwa algoritma CDC "bias" (tidak memiliki kata-kata yang lebih baik) untuk menghasilkan blok sekitar 1 MB, ini akan cukup untuk memastikan apakah file besar tertentu atau tidak. file ada di cadangan.

SEPERTI biasa, aliran kesadaran paranoid dan sangat tidak ilmiah.

Pikiran?

Menarik. Saya tidak mengerti bagaimana serangan yang Anda gambarkan tergantung pada apakah kompresi digunakan, apakah perlu sama sekali? Bukankah serangan ini bekerja dengan dan tanpa kompresi?

Saat ini saya sedang berpikir tentang bagaimana menerapkan #56. Apa pendapat Anda tentang menggabungkan beberapa gumpalan menjadi satu file?

Cara kerja yang tepat dari implementasi CDC agak tidak jelas bagi saya:

• Apakah Anda membagi pada batas byte yang tepat atau apakah blok 512 KB - 8 MB "dibulatkan" menjadi kelipatan sesuatu?
• (Pertanyaan sebenarnya adalah: apakah ada (15 * 512 * 1024) / (16 karena AES-CTR) kemungkinan ukuran potongan, atau lebih sedikit?)
• Saya juga ingin tahu tentang seberapa layak untuk merekonstruksi benih yang diberikan cukup banyak file yang dikenal - tidak terlalu layak, saya kira?

Untuk menjawab pertanyaan pertama Anda:
Dengan CDC yang diunggulkan, "sidik jari" tergantung pada (konten + benih rahasia), tetapi perbedaannya adalah ketika kompresi dilakukan _setelah_ chunking, dan dengan asumsi bahwa Anda dapat membedakan blok individu satu sama lain, Anda memiliki sidik jari/ watermark (tingkat kompresi blok tertentu) yang hanya bergantung pada konten, dalam skenario ini plaintext yang dikenal.

Contoh:
Jika file yang diberi watermark berisi 64 MB (8-128 potongan) "AAAA" , kemudian 64 MB "ABCABCABCABC", kemudian 64 MB data acak, 16-256 potongan pertama akan sangat kecil (karena urutan tersebut dikompres dengan sangat baik , di mana potongan 8-128 akan terkompresi agak buruk).
Penyerang juga dapat bekerja mundur, dimulai dengan potongan terakhir (24 - 384) dan mengompres 512KB-8MB hingga penyerang menemukan ukuran yang dikompres ke ukuran potongan yang sama persis. Setelah ditemukan, "berikutnya" 512KB-8MB dari plaintext asli dikompres untuk mengetahui panjang mana yang dikompresi dengan panjang blok kedua-terakhir (23 - 383), dan seterusnya, sampai penyerang memenuhi potongan kecil yang merupakan hasil dari string "AAAA".
Ini tidak memungkinkan musuh untuk mengonfirmasi secara positif bahwa file bertanda air disimpan di cadangan, tetapi saya pikir secara statistik itu dapat membuat hasil yang cukup jelas, dengan data yang cukup.

Saya melihat beberapa solusi potensial, mungkin Anda memiliki lebih banyak ide:

• Izinkan mematikan kompresi dan/atau deduplikasi untuk direktori tertentu (mungkin yang paling mudah diterapkan)
• Acak kamus kompresi (belum benar-benar memikirkan yang ini, tapi sepertinya ide yang menarik)
• Cegah penyerang mempelajari panjang masing-masing bongkahan terkompresi, misalnya dengan mengisi (berpotensi cukup mahal) atau dengan menggabungkan beberapa bongkahan kecil dan mengisi sisanya (lebih rumit, tetapi lebih efisien)

Terima kasih atas penjelasan Anda, saya mengerti skenario Anda sekarang.

Mungkin tidak akan ada opsi untuk mematikan deduplikasi di restic, karena itu sangat sulit dilakukan mengingat struktur program saat ini, restic dibangun di sekitar CDC. Menambahkan dukungan kompresi adalah prioritas rendah saat ini dan bukan tujuan untuk rilis alfa.

Ide ketiga Anda akan diimplementasikan di #56 (menggabungkan beberapa potongan), saya sedang mengerjakannya sekarang. Dan saya mungkin akan menambahkan lebih banyak dokumentasi ke doc/Design.md mengenai cara kerja chunker.

Sekali lagi terima kasih telah mengemukakan skenario ini!

Saya tidak yakin apakah saya mengikuti @cfcs - bukankah ukuran terkompresi seperti hash yang sangat buruk? Mengingat ukuran file terkompresi, jumlah kemungkinan input yang menghasilkan ukuran file itu tidak terbatas. Tapi mungkin aku hanya tidak mengerti.

Bagaimanapun. Saya hanya ingin tanpa malu-malu mengarahkan Anda ke perpustakaan deflate/gzip yang saya buat. Mungkin menarik bagi Anda bahwa saya memasukkan mode kompresi waktu konstan , yang memungkinkan ~150MB/s/core throughput pada data APAPUN, yang membuatnya hampir tidak terlihat dalam skenario pencadangan. Ada juga paket gzip paralel yang mengompresi file yang lebih besar dengan gzip pada banyak inti.

@klauspost : Ingatlah bahwa kita sedang membahas ukuran terkompresi dari potongan individu daripada file. File 100GB dengan ukuran potongan rata-rata 1MB akan memiliki sekitar 100 x 1024 potongan, masing-masing membocorkan rasio kompresi untuk bagian file tertentu. Ini menghasilkan lebih banyak data statistik daripada ukuran file terkompresi tunggal, sehingga memungkinkan untuk membandingkan teks biasa yang diketahui dengan file terkompresi dan terpotong bahkan jika garam CDC (dan dengan demikian batas penyelarasan yang tepat dari potongan) tidak diketahui.

151 telah digabungkan, jadi ini mungkin bukan masalah sekarang.

Menurut pendapat saya, kebocoran informasi ini tidak terlalu penting, mengingat kami memiliki chunker yang diunggulkan (melalui polinomial per-repo khusus) dan pengepakan gumpalan (di mana penyerang tidak dapat melihat potongan individu, tetapi hanya kelompok potongan dan jumlah potongan dalam grup, melalui panjang header teks yang jelas). Saya pikir itu ide yang baik untuk menawarkan penonaktifan kompresi sepenuhnya untuk masalah kecepatan atau privasi, tetapi default (ketika ini diterapkan) mungkin akan "mengaktifkan".

@klauspost Saya pasti akan melihat perpustakaan Anda, terima kasih telah menunjukkannya!

Saya setuju dengan pengamatan Anda di atas, @fd0 , tetapi saya ingin menambahkan bahwa saya pikir mungkin ada kasus penggunaan penting lainnya untuk menonaktifkan kompresi secara selektif untuk file/direktori/perangkat target tertentu, misalnya saat mencadangkan format multimedia yang sudah terkompresi, file biner dengan entropi tinggi yang tidak terkompresi dengan baik, atau saat melakukan pencadangan tambahan volume terenkripsi.

@cfcs - ok - dari teks Anda, saya pikir Anda menyiratkan bahwa Anda dapat menyimpulkan data. Jadi agar ini membuat perbedaan, Anda memerlukan data asli, yang jarang.

Mengenai file yang tidak dapat dimampatkan, itulah alasan saya menyebutkan mode waktu konstan Huffman only yang saya masukkan ke dalam deflate, seperti namanya, ini mengompresi semua data pada kecepatan yang sama, dan memiliki mundur otomatis untuk menyimpan data yang tidak terkompresi. Jadi overhead maksimum adalah sekitar 0,04% jika konten dikompresi.

Berikut adalah beberapa benchmark . Yang paling berlaku untuk pencadangan mungkin pada "Kompresi Sedang", yang merupakan konten campuran 10GB - dapat dikompresi dan tidak dapat dikompresi.

Default ke gzip Huffman saja dan memiliki opsi untuk menentukan lebih banyak tingkat kompresi yang memakan CPU bisa masuk akal.

Menurut pendapat saya, mungkin berguna untuk mengaktifkan/menonaktifkan kompresi secara selektif untuk data dan objek pohon. Terutama objek pohon besar harus dikompres dengan sangat baik.

Saya melihat beberapa "titik" di mana masuk akal untuk memasukkan kompresi. Tempat yang paling transparan dan serbaguna adalah di antara repositori dan backend.

Saya secara singkat melihat modifikasi Repository.Encrypt dan Repository.DecryptTo , tetapi kami tidak memiliki tipe, dan ukuran yang bervariasi akan mengacaukan segalanya.

Proposisi saya adalah mengimplementasikan kompresi dan _encryption_ sebagai "backend", yang keduanya menulis ke backend yang mendasarinya. Ini akan membuat kompresi dan enkripsi transparan ke repositori.

Alasan kami perlu memisahkan enkripsi adalah karena data terenkripsi tidak terkompresi (seperti yang mungkin Anda ketahui).

repositori.Repositori

Algoritme kompresi hanya dapat disetel pada inisialisasi, dan semuanya kecuali konfigurasi diasumsikan dikompresi dengan algoritme itu.

repositori.Konfigurasi

Konfigurasi tidak dapat dikompresi. Kami menambahkan string yang menunjukkan jenis dekompresi yang akan digunakan untuk semuanya. Kosong ("") tidak terkompresi. Kalau tidak, itu adalah bagian terakhir dari nama paket perpustakaan kompresi yang digunakan.

Perhatikan bahwa tingkat kompresi dapat diubah antara setiap run/type. Tidak ada masalah memiliki repo di mana beberapa snapshot/tipe mengempis level 0 (simpan) dan beberapa di level 9 (kompresi terbaik) - selama dekompresornya sama.

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

Kompresi ditambahkan sebagai parameter buat:

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

Backend diganti setelah LoadConfig/CreateConfig. Berikut adalah contoh tampilannya:

// 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
}

Implementasi Kompresi

Kompresor dapat menerapkan kompresi selektif/dapat disesuaikan untuk beberapa jenis. Karena dilihat sebagai "backend", ukuran terkompresi tidak akan pernah terlihat oleh repositori. Kompresor harus summetric dengan semua pengaturan.

Masalah

HELPME/FIXME: File "Dikemas" sepertinya bermasalah, karena enkripsi dimulai ulang di setiap file. Jika enkripsi dipindahkan ke backend, enkripsi akan dilakukan untuk seluruh gumpalan, bukan untuk setiap file. Saya menganggap itu adalah masalah, dan saya tidak punya solusi yang baik.

TODO: Temukan cara yang baik untuk mengirim parameter/konfigurasi ke kompresor. Tidak diperlukan untuk implementasi pertama.

TODO: Apakah kita peduli dengan ukuran di disk? Jika hal di atas diterapkan, repositori tidak akan mengetahuinya.

Terima kasih telah berbagi pemikiran Anda, ini milik saya:

Saya pikir kompresi dan enkripsi perlu diintegrasikan satu sama lain, saya akan memikirkannya. Saat ini, saya tidak suka pemikiran untuk sepenuhnya mengabstraksi lapisan kompresi/enkripsi satu sama lain. Seperti yang sudah Anda jelaskan, kita harus berhati-hati untuk tidak melakukan hal-hal bodoh, misalnya mengompres data terenkripsi. Selain itu, kami harus menawarkan opsi untuk menonaktifkan kompresi demi kecepatan dan/atau masalah keamanan. Mengenai enkripsi: Mungkin ada mode non-crypto untuk restic nanti, tetapi untuk saat ini crypto tidak opsional.

Juga file yang dikemas adalah tingkat abstraksi itu sendiri (misalnya barang dapat dikemas ulang), yang tidak bekerja dengan abstrak kripto.

Saya pikir objek Repository terlalu rumit dan perlu perbaikan umum sebelum menangani ini. Saya tidak benar-benar memiliki rencana yang baik siap untuk itu sekarang.

Mengenai algoritme dan opsi kompresi yang berbeda: Saya pikir kita harus memilih satu algoritme (termasuk satu set parameter) untuk data, dan mungkin yang kedua untuk mengompresi struktur pohon JSON, tetapi hanya itu. Untuk semua hal opsional (misalnya algoritme dan/atau parameter kompresi yang dapat dikonfigurasi berbeda) saya ingin memiliki pertimbangan yang baik dengan mempertimbangkan manfaat terhadap kompleksitas tambahan dan jumlah kode tambahan.

Tolong jangan salah paham, saya ingin menambahkan fitur ke restic, tetapi terutama untuk perubahan yang mengubah format pada disk, saya membutuhkan argumen yang sangat bagus. Dalam kasus umum menambahkan kompresi, saya dapat melihat manfaatnya, tetapi kerumitan dan perubahan pada format pada disk harus dapat dikelola.

Anda memerlukan algoritme dan parameter yang berbeda (dan bukan hanya per repo, tetapi bahkan per pencadangan), tidak ada kompresi "terbaik untuk setiap usecase".

hanya sebagai contoh praktis:

saya melakukan backup dari server perusahaan saya ke server backup saya di rumah. dsl uplink dengan ~ 700kbit/s.
untuk ini saya ingin kompresi terbaik (seperti lzma + level tinggi). cpu memiliki banyak waktu luang di malam hari sambil menunggu koneksi jelek untuk menerima paket berikutnya.

ke repositori yang sama saya juga membuat cadangan laptop saya ketika saya di rumah, di sana saya memiliki koneksi "N" nirkabel. tentu saja saya tidak ingin memperlambat koneksi dengan menggunakan lzma + level tinggi di sana, tetapi saya ingin sesuatu yang sangat cepat yang tidak melambat sama sekali - seperti lz4. saya masih ingin kompresi, tidak menggunakan lz4 akan memakan waktu sekitar 2x ruang.

Saya ingin lzma di sini tetapi lz4 di sana (diulang :-))

Itu semua bikeshedding imho ... Mari kita pilih default yang masuk akal dan tidak mengekspos terlalu banyak konfigurasi, itu hanya akan memperkenalkan banyak kompleksitas untuk sedikit keuntungan, imho.

Saya pikir objek Repository terlalu rumit dan perlu perbaikan umum sebelum menangani ini. Saya tidak benar-benar memiliki rencana yang baik siap untuk itu sekarang.

Cukup adil. Saya mulai mencari melalui repository.go dan menemukan semua tempat Anda akan memasukkan langkah kompresi/dekompresi, dan kerumitan tambahan bukanlah hal yang baik. Dengan mengimplementasikannya sebagai antarmuka backend , Anda tiba-tiba dapat menghapus semua enkripsi, dan menjadikannya bagian dari rantai backend. Anda dapat membuat tes umum yang memastikan simetri bagian backend, termasuk kompresi dan enkripsi.

Mengenai enkripsi: Mungkin ada mode non-crypto untuk restic nanti, tetapi untuk saat ini crypto tidak opsional.

Itulah sebabnya backend chaining membuatnya sangat bagus. Anda hanya meninggalkan enkripsi (atau membuat backend passthrough) dan itu bekerja dengan mulus.

Dalam kasus umum menambahkan kompresi, saya dapat melihat manfaatnya, tetapi kerumitan dan perubahan pada format pada disk harus dapat dikelola.

Ini adalah cara yang paling tidak mengganggu yang bisa saya lihat. Jika ada cara untuk memperbaiki masalah 'file yang dikemas', repo yang tidak terkompresi tetap kompatibel sepenuhnya; klien lama akan dapat mengoperasikannya seperti sebelumnya bersama yang baru.

Repo terkompresi jelas tidak, tetapi kita dapat mengubah version menjadi 2 hanya jika repo dikompresi, ini akan membuat klien lama gagal. Cek kemudian harus jelas diubah menjadi if cfg.Version > RepoVersion { , tetapi itu tidak memiliki masalah kompatibilitas.

Itu semua bikeshedding imho ... Mari kita pilih default yang masuk akal dan tidak mengekspos terlalu banyak konfigurasi, itu hanya akan memperkenalkan banyak kompleksitas untuk sedikit keuntungan, imho.

Setuju. Sebagian besar algoritma (lzma/deflate) memiliki banyak fleksibilitas dalam format dekompresi yang sama.

Untuk menguji kompresibilitas ada DataSmoke: https://github.com/Bulat-Ziganshin/DataSmoke

Juga, pcompress memilih berbagai macam algoritma kompresi yang bagus: https://github.com/moinakg/pcompress

Pustaka abstraksi kompresi squash memiliki daftar algoritme dan tolok ukur yang bagus: https://quixdb.github.io/squash/

Ada benchmark kompresi teks di sini: http://mattmahoney.net/dc/text.html

Pendekatan yang mudah adalah selalu memfilter di dalam fungsi crypto/crypto.go Encrypt/Decrypt.

gzip-compression-v1.patch.txt adalah

Terima kasih telah mencoba @mappu , tetapi sebelum menerapkan ini kita harus menyepakati strategi. Pertanyaan terbuka (dari atas kepala saya) setidaknya:

• Kapan kompresi diterapkan? (Data? Metadata/JSON?)
• Algoritma mana yang harus kita terapkan? Saya pikir @klauspost memiliki beberapa saran untuk kami :)
• Bagaimana kami menyimpan ini dalam repositori tanpa merusak klien?

Kapan kompresi diterapkan? (Data? Metadata/JSON?)

Datanya jelas ya.
Metadata/json, mungkin tidak ada gunanya tetapi saya pikir itu bisa membantu untuk file metadata besar karena data JSON sebagian besar ASCII dan akan mendapat manfaat dari fase pengkodean aritmatika/huffman (gzip memiliki).

Karena data/metadata selalu dienkripsi, saya pikir menambahkan ke rutin enkripsi/dekripsi adalah cara sederhana untuk menangkap semua penggunaan, tanpa ini "Saya mulai mencari melalui repositori.go dan menemukan semua tempat Anda akan memasukkan langkah kompresi/dekompresi, dan kerumitan tambahan bukanlah hal yang baik." dari @klauspost .
Juga karena gumpalan disimpan bernama hash(plaintext) bukan hash(ciphertext) {{jelas diperlukan untuk dedup jika tidak, IV acak akan menghancurkan dedup}}, aman untuk melakukan ini tanpa menyakiti dedup.

Algoritma mana yang harus kita terapkan? Saya pikir @klauspost memiliki beberapa saran untuk kami :)

tidak peduli Meskipun saya setuju dengan @ThomasWaldmann bahwa itu harus dapat dikonfigurasi. Setidaknya untuk kasus penggunaan --best dan --fast .

Saya akan menyarankan gzip hanya karena ini murni go, ada di perpustakaan standar golang, dan menerima perhatian kinerja dari Google. xz jauh lebih kuat kompresi lambat. lz4 adalah kompresi cepat yang jauh lebih lemah. gzip seimbang dan mudah disetel, meskipun tidak mencapai ekstrem.

Bagaimana kami menyimpan ini dalam repositori tanpa merusak klien?

Repositori harus kompatibel dalam satu arah saja. Saya rasa tidak apa-apa jika restic lama tidak bisa membaca repo baru, selama restic baru bisa membaca repo lama.

Mungkin Anda bisa menambahkan tag byte setelah MAC. Tidak ada - tidak ada kompresi (restic lama). Kemudian, byte juga dapat menunjukkan algoritma kompresi mana yang digunakan. 0x01 gzip 0x02 lz4 atau lebih.

Tampaknya ada masalah yang sama (atau lebih buruk) seperti di loteng (tidak ada tipe kompresi/byte parameter yang digunakan dalam format saat ini).

Di loteng (borg) saya beruntung karena format lama hanya gzip dan format gzip dapat dideteksi dari 2 byte pertama. Jadi saya menyimpan gzip tanpa byte tambahan (sama dengan repo lama) dan menambahkan byte tipe (tanpa atau kompresi lainnya) yang tidak pernah ambigu dengan 2 byte gzip pertama.

Jelas Anda tidak dapat melakukannya seperti itu jika format lama hanya data mentah dan sewenang-wenang.

Tidak. Tapi ada cara lain untuk memberi sinyal informasi ini. misalnya jika IV pada awal potongan terenkripsi persis "FORMAT BARU" (1 :: 2^xyz kemungkinan tabrakan) maka parsing sebagai format baru. Ini tidak begitu "bersih" tetapi saya pikir baik-baik saja dalam praktiknya.

seperti yang dilakukan dengan EXTENDEDPROTOCOL di jabat tangan kunci nmdc.

Oh tidak, kami tidak akan melakukan sesuatu yang buruk seperti ini, dan kami tidak perlu melakukannya. Jika kita memutuskan untuk menerapkan ini, file paket memiliki bidang type untuk setiap gumpalan. Ini adalah uint8 , dan saat ini hanya didefinisikan untuk data dan tree , kita dapat dengan mudah menambahkan compressed data dan compressed tree . https://github.com/restic/restic/blob/master/doc/Design.md#pack -format

Saat ini, saya tidak menganggap fitur ini sebagai prioritas utama.

Menambahkan tipe gumpalan baru ke format paket boleh saja untuk kompresi data, tetapi, tidak menyediakan kompresi indeks. Karena indeks bisa menjadi besar, dan JSON memiliki rasio kompresi yang baik, dan mungkin indeks tidak memiliki cache lokal, jadi saya pikir penting untuk mengompresi indeks juga.

Sangat penting bahwa new-restic bekerja dengan repo lama, untuk memungkinkan peningkatan yang mudah. Itu harus mulus (lebih disukai) atau memiliki alat restic upgrade-repo (tidak disukai).

Jadi Bagaimana dengan ini?

Semua perintah restic sudah melakukan pemuatan pertama+dekripsi config .

• jika config byte pertama adalah { (ini adalah objek json byte pertama), maka seluruh repo adalah format lama (tidak terkompresi)
• jika tidak, byte config adalah {tag byte} dan seluruh repo adalah format baru. {tag byte} di awal data yang didekripsi menunjukkan format kompresi. contoh 0x00 tidak terkompresi 0x01 gzip

Terima kasih atas proposalnya. Saya pikir tidak perlu mengompresi konfigurasi, karena ini hanya file yang sangat kecil dan selalu dapat tetap dalam format JSON, dan kita dapat menambahkan bidang seperlunya, misalnya apakah file indeks dikompresi atau tidak.

Saya baru saja menemukan restic kemarin saat mencari solusi cadangan yang bagus. Salah satu perhatian utama saya adalah membatasi berapa banyak ruang yang digunakan data saya. Apalagi jika saya mengirim data ke tempat yang saya bayar, seperti S3. Dedup pasti akan membantu, tetapi saya agak mengharapkan kompresi akan menjadi bagian tak terpisahkan dari solusi cadangan... Di https://github.com/restic/restic/issues/21#issuecomment -185920429 Anda ( @fd0 ) katakan ini adalah prioritas rendah, dapatkah Anda menjelaskan mengapa? Apakah ada peta jalan yang bisa saya lihat di mana saja?

Juga, +1. ;)

Saat ini saya sedang berupaya menghapus data cadangan lama (#518). Tidak mudah untuk mendapatkan kompresi yang benar dan aman pada saat yang sama, dan saya perlu berpikir lebih banyak tentang bagaimana mengintegrasikan ini ke dalam format repositori.

Kami akan menerapkan kompresi (setelah semua tentang masalah ini), itu belum selesai. restic adalah proyek yang agak baru, mohon bersabar :)

Masalah ini terkait dengan #116. Karena enkripsi kami tidak dapat mengompres cadangan setelah dengan alat lain bukan? Prioritas apa yang Anda miliki antara kompresi dan menjadikan enkripsi opsional? (Saya bertaruh untuk kompresi dulu!)
_Maaf membuat tekanan tentang ini, Anda benar bahwa format repositori harus dijaga dengan hati-hati!_

Ini mudah untuk dijawab: Kompresi akan diimplementasikan terlebih dahulu.

Ini karena saya tidak punya rencana saat ini untuk membuat enkripsi opsional. Saya pikir itu sangat sulit untuk mendapatkan yang benar juga. Kita perlu memikirkan tentang integritas, karena ini adalah hal yang seharusnya tidak opsional, tetapi (setidaknya untuk saat ini) ini terkait erat dengan enkripsi.

@ fd0 Terima kasih telah menjawab pertanyaan saya. Membuat saya berharap keterampilan dev saya dapat membantu dalam hal ini. Tapi saya baru saja menyentuh go, dan sebagian besar xp saya yang lain ada di skrip webdev atau sysadmin.

Saya sepenuhnya setuju bahwa Anda perlu memastikan kompresi dilakukan "benar dan aman". Jika itu menunda sesuatu, biarlah. :senyum:

Saya menerapkan kompresi tajam dalam restic di sini: https://github.com/viric/restic/tree/snappy

Itu hanya proposal. Pada dasarnya, saya menambahkan kompresi/dekompresi cepat untuk gumpalan dalam paket, dan saya menggunakan sedikit byte tipe gumpalan sebagai tanda. Saya juga menambahkan bidang dalam indeks paket: PLength (panjang plaintext), yang sampai saat itu tidak disimpan tetapi dihitung sebagai "bloblength - crypto.Extension".

Saya perhatikan bahwa untuk beberapa cadangan saya, ini tidak hanya membutuhkan lebih sedikit ruang, tetapi bahkan bekerja lebih cepat (lebih sedikit data untuk ditangani).

Semua tes restic lulus dengan baik. Itu dapat bekerja di atas repositori restic sebelumnya, tetapi restic normal (yaitu master) tidak dapat menangani gumpalan baru.

Saya menggunakan snappy (https://github.com/golang/snappy) karena saya pikir itu akan kurang mempengaruhi tujuan untuk kecepatan @ fd0.

Menambahkan hadiah $50 untuk pendaratan kompresi di master

Seperti disebutkan di atas, harus ada cara otomatis yang tidak dapat dikonfigurasi untuk menghindari mencoba mengompresi file yang tidak dapat dikompresi seperti media, yang dienkripsi atau yang sudah dikompresi. Masalah tersebut diperparah dengan beberapa format container seperti PDF yang isinya terkadang bisa dikompresi, terkadang tidak.

Akan lebih mudah menggunakan beberapa algoritme yang secara transparan menangani ini, seperti mode kompresi waktu konstan yang disebutkan dalam komentar pertama oleh @klauspost.

Jika tidak, akan ada kebutuhan untuk daftar tipe file: daftar hitam yang tidak pernah dikompresi, daftar putih yang selalu dikompresi, heuristik untuk sisanya yang mencoba mengompresi sebagian kecil file, dan menyerah jika pengurangan ukuran tidak melebihi ambang batas yang diberikan.

Tidak yakin seberapa baik ini akan dipetakan di chunk, daripada di level file.

Saya menentang menambahkannya ke pass enkripsi/dekripsi.
Kami tidak ingin mencampur jenis data yang berbeda, karena beberapa di antaranya dapat diprediksi, dan panjang paket/gumpalan yang dihasilkan dapat membocorkan informasi tentang teks biasa dari data yang tidak dapat diprediksi/rahasia.
Saya pikir itu harus per-file, bahkan jika ini membuatnya "kurang bagus". Itu, bagaimanapun, datang dengan manfaat tidak harus melakukan dekompresi nyasar berton-ton file paket (di mana hanya satu gumpalan dalam setiap hal) untuk membaca file.

@teknico

Seperti disebutkan di atas, harus ada cara otomatis yang tidak dapat dikonfigurasi untuk menghindari mencoba mengompresi file yang tidak dapat dikompresi seperti media, yang dienkripsi atau yang sudah dikompresi.

Paket deflate saya yang dimodifikasi mengimplementasikan melewatkan data yang sudah dikompresi dan melakukannya dengan kecepatan ~250MB/s per inti. Deflate Go 1.7 hanya mendukungnya pada tingkat kompresi tercepat.

Snappy dan LZ4 mendukung fungsi skipping yang serupa.

Akan lebih mudah untuk hanya menggunakan beberapa algoritma yang secara transparan menangani ini, seperti mode kompresi waktu konstan.

Itu pasti harus menjadi pilihan. Di Go 1.7 (sekarang disebut HuffmanOnly dan yang setara dengan saya) mode ini mendukung ~200MB/s per inti, apa pun inputnya. Namun kompresi sangat terhambat dibandingkan dengan "kecepatan terbaik", yang biasanya beroperasi pada 80 MB/s/core.

@cfcs

Saya pikir itu harus per-file, bahkan jika ini membuatnya "kurang bagus".

Secara umum saya setuju. Saya harus membaca tentang restic. Apakah ukuran biner dari setiap ukuran paket tersedia tidak terenkripsi?

@klauspost Sepertinya beberapa peningkatan Anda digabungkan ke mode Go 1.7 DEFLATE "BestSpeed", apakah itu benar? Mungkin itu akan menjadi standar yang masuk akal.

Keuntungan menggunakan format DEFLATE adalah tersedianya banyak kompresor berbeda yang menghasilkan bitstream yang kompatibel, sehingga benar-benar transparan bagi dekompresor.

Karena sifat dari cara kerja restic (membagi file menjadi blob, hanya menangani blob setelahnya) cara termudah untuk menambahkan kompresi adalah pada level blob. Mungkin kita bisa menambahkan beberapa heuristik untuk memutuskan apakah blob harus dikompresi atau tidak, tapi itu bisa menjadi langkah kedua.

Gumpalan digabungkan menjadi file paket, yang kemudian disimpan dalam repositori. File paket berisi sejumlah blob (dienkripsi secara terpisah), diikuti oleh header (terenkripsi), diikuti dengan panjang header (tidak terenkripsi). Penyerang tanpa kunci dekripsi hanya melihat ciphertext, panjang header, dan panjang file. Jadi berdasarkan ukuran file paket dan panjang header, penyerang dapat menghitung ukuran rata-rata gumpalan dalam file paket tertentu, tetapi hanya itu. File Indeks juga berisi semua data (ukuran, ukuran terenkripsi, dan kemudian mungkin ukuran terkompresi), tetapi itu juga dienkripsi. Saya tidak melihat risiko apa pun di sini.

Heuristik uji "dapat dimampatkan" rentan terhadap kesalahan dan agak mahal. Saya memperkirakan akan sulit untuk mendapatkan jauh di atas 200 MB/s/core - itu adalah kecepatan pencarian urutan 1 dalam paket dedup di AMD64.

Juga, itu akan sangat tergantung pada kompresor yang digunakan. Snappy tidak akan dapat mengompresi data basis 64 acak, tetapi mengempis misalnya, jadi saya akan menyerahkan bagian itu ke kompresor - kami memilikinya untuk Snappy, LZ4 dan deflate.

@fd0 maaf, maksud saya per-gumpalan, bukan per-file.
Kecuali jika kita memilih algoritme yang ringan, kompresi, karena agak berat CPU, kemungkinan akan menjadi hambatan (di samping AES, yang di masa depan diharapkan akan ditangani oleh AES-NI).

@fd0 - Saya membuat "penaksir kompresibilitas" cepat: https://play.golang.org/p/Ve5z3txkyz - ini memperkirakan prediktabilitas dan entropi data arbitrer. Padahal, seperti yang saya sebutkan, seharusnya kompresor yang memutuskan.

borg 1.1 akan memiliki 2 "penentu kompresi":

1. putuskan per file berdasarkan kecocokan pola jalur ( *.zip , *.mp3 , /htdocs/photos/* , ...)
2. jika ragu-ragu, putuskan per potongan, gunakan lz4 sebagai uji kompresibilitas - jika itu kompres, kompres lagi dengan kompresi yang diinginkan (lz4, zlib, lzma), jika tidak, jangan kompres.

@klauspost hm, tes itu tidak terlalu buruk di mesin saya:

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

Kode benchmark ada di sini: https://Gist.github.com/908c23123dda275a479cf931f2784f5d

Lz4 tidak memiliki entropy coder, jadi akan sering salah negatif
mungkin?

Saya pikir kita membutuhkan tiga mode (secara global):

• Kompres semua gumpalan data dengan kompresor waktu linier (default)
• Tidak ada kompresi
• Kompresi maksimum (untuk orang dengan banyak daya CPU, tetapi hanya bandwidth kecil)

Saya ingin selalu mengompres objek pohon (JSON), jadi kita harus memilih algoritme yang tepat untuk teks ASCII.

Kalau tidak, saya akan bekerja dengan @viric untuk membangun prototipe, lalu kita bisa bernalar tentang implementasi konkret.

Pikiran?

@klauspost hm, tes itu tidak terlalu buruk di mesin saya

Saya selalu lupa betapa buruknya kemampuan kompiler Go yang baru. Setidaknya dua kali dari apa yang saya harapkan.

Saya pikir kita membutuhkan tiga mode (secara global):

Deflate melakukan ketiganya dengan cukup baik, meskipun ada kompresor yang lebih efisien (kebanyakan LZMA). Mengempis tanpa kompresi tentu saja tidak diperlukan, tetapi tentu saja cepat dan dengan overhead minimal, sehingga pendekatan deflasi umum dapat digunakan, dengan kemungkinan untuk menentukan yang lain nanti.

Saya sudah mulai mencari speedup lain , yang akan berada di antara level 1 dan Huffman baik dalam hal kecepatan dan kompresi. Namun, waktu agak berharga saat ini, dan saya masih perlu menguji backport dari beberapa perubahan terakhir Go 1.7 sebelum saya dapat beralih ke hal-hal baru.

Jika Anda hanya menginginkan algoritma kompresi tunggal, Anda harus melihat zstd pesaing baru: https://github.com/facebook/zstd

Ini dikembangkan oleh pengembang yang sama dengan lz4 dan memiliki rasio kompresi yang lebih baik daripada gzip sementara lebih dari 3 kali lebih cepat: https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with -zstandar/

zstd terlihat sangat menjanjikan, meskipun saya tidak dapat menemukan implementasi di Go.

Situs resmi http://facebook.github.io/zstd/#other -languages ​​menautkan ke implementasi Go ini: https://github.com/DataDog/zstd

Atau maksud Anda implementasi Go murni?

Ya, berarti implementasi Go murni. Saat ini, restic tidak bergantung pada kode C apa pun, dan idealnya saya ingin tetap seperti itu.

Apakah ada perkiraan untuk menerapkan kompresi?

Menerapkan kompresi tergantung pada perubahan format repositori (perencanaan/ide ada di #628), yang membutuhkan perhatian besar. Jadi, tidak, tidak ada tanggal pasti kapan kompresi ditambahkan;)

Adakah yang bisa kita lakukan atau berkontribusi untuk membantu mewujudkan ini?

Saya rasa tidak, maaf :wink:, ini hanya butuh waktu.

Jadi saya pikir saya bisa menggunakan test bed saya dari #790 sekali lagi. Dalam build restic saya, saya menghapus semua enkripsi, lalu membuat cadangan penuh sekali lagi. Itu datang dalam ukuran yang sama seperti terenkripsi - tidak ada kejutan di sini. Tapi kemudian saya mengompres repositori, dan yang saya temukan adalah:

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

Apa perbedaan! Sebagai perbandingan, inilah ukuran dump database tunggal yang dikompresi:

1.7G    single-backup.sql.gz

Saya memiliki 29 di atas. Penghematan sekitar 100 kali lipat dibandingkan pencadangan biasa!

Karena saya menemukan semua tempat di mana enkripsi ditambahkan, saya pikir saya dapat menambahkan kompresi yang sangat sederhana yang dapat dikonfigurasi dengan implementasi stok gzip , dengan kemungkinan untuk menggunakan mesin kompresi yang berbeda di masa mendatang. Ada keberatan?

(Saya mungkin akan memberi diri saya waktu malam selama dua minggu untuk berhasil atau gagal.)

Terima kasih atas penelitian Anda dan posting hasilnya di sini! Saya mengharapkan hasil yang serupa. Sejujurnya: Saya tidak akan menggabungkan apa pun yang menghapus kripto, atau bahkan menjadikannya opsional. Itu sesuatu yang bisa kita lakukan nanti, tapi harus direncanakan dengan matang.

Menambahkan kompresi mungkin tampak mudah pada awalnya, tetapi sebenarnya tidak. Kita harus sangat berhati-hati agar tidak secara tidak sengaja membuat restic rentan terhadap serangan tak terduga (ini telah terjadi pada protokol TLS beberapa kali berturut-turut (ya, saya sadar bahwa ini adalah situasi yang berbeda)).

Hal terpenting dalam keseluruhan proyek bukanlah kodenya: Ini adalah format repositori. Pengguna mempercayai kami dengan data mereka, dan mereka bergantung pada kemampuan untuk memulihkan data setelah menggunakan restic dalam waktu yang lama, sehingga stabilitas format repositori sangat penting. Jadi untuk mendukung kompresi, pertama-tama kita harus memutuskan (dan mengimplementasikan) versi berikutnya dari format repositori. Diskusinya ada di sini: https://github.com/restic/restic/issues/628

Saya dapat melihat bahwa Anda sangat ingin mengimplementasikan ini (dan bahkan menyumbangkan kode), tetapi tolong jangan habiskan waktu untuk hal ini sampai kita menyetujui format repositori dan telah membahas semua sudut dari masalah ini. Terima kasih!

Adapun crypto yang dihapus, saya tidak akan mengusulkan untuk menggabungkannya. Saya melakukan itu hanya untuk melihat apakah kompresi akan berfungsi. Dan ya, ini harus direncanakan dengan hati-hati (tidak ada yang ingin tiba-tiba kehilangan kemampuan untuk memverifikasi repositori dengan enkripsi dinonaktifkan).

Karena kami menggunakan json.Unmarshal kami dapat menambahkan sebanyak mungkin kunci baru ke konfigurasi yang kami inginkan. Jika tidak ditemukan di JSON, mereka hanya akan mempertahankan nilai defaultnya.

Pilihan algoritma bukan poin utama, dipahami: tetapi hanya untuk referensi di masa mendatang, Brotli tampaknya merupakan pesaing yang kuat.

Untuk semua yang saya tahu kompresi Brotli sangat lambat (iirc 60 kali gzip), jadi disarankan untuk data yang sering dibaca dibandingkan dengan yang ditulis dan dikompresi yang mungkin tidak umum untuk cadangan. Tapi ya, mari kita belum membahas detailnya :)

Ini memberikan gambaran yang baik untuk algoritma kompresi yang berbeda.

Brotli selalu lebih cepat atau memiliki kompresi yang lebih baik. Tergantung pada tingkat kompresi.

@ibib Bagaimana Anda mencapai kesimpulan itu? Sepertinya saya brotli muncul lebih lambat daripada kebanyakan yang lain (pada kumpulan data campuran) sementara tidak mencapai tingkat kompresi yang luar biasa. Mungkin lebih baik untuk jenis data terstruktur tertentu?

Seperti yang tercantum dalam perbandingan di benchmark Squash, ada tiga parameter yang harus dilalui:

• Rasio kompresi yang dicapai: Seberapa baik kompresinya penting untuk menghemat ruang disk (dan I/O ke backend).

• Kecepatan kompresi: Penting karena kami akan melakukan operasi ini setiap kali kami menambahkan blok, jadi kami sangat menginginkan sesuatu yang dapat mengikuti AES-NI dan I/O umum agar tidak menjadi hambatan. Kami mungkin tidak ingin memilih algoritme yang mengompresi lebih lambat daripada mendekompresi karena kami memiliki kasus penggunaan yang berlawanan dari browser web dengan algoritme baru ini (seperti zstd , lz4 , brotli ) dioptimalkan untuk (kami memiliki "kompres sering, dekompresi jarang" sebagai lawan dari "kompres sekali, dekompresi sering").

• Kecepatan dekompresi: Kecepatan dekompresi hanya relevan saat kami memulihkan. Jika kami baik-baik saja dengan pemulihan yang lambat, kami dapat menerima kecepatan dekompresi yang lambat. Di sisi lain, kami juga memiliki metadata yang tidak ingin kami dekompresi secara perlahan, sehingga mungkin memerlukan dua algoritme yang berbeda.

Tampaknya density termasuk yang tercepat, meskipun tidak terlalu efisien dalam hal rasio kompresi. Dalam hal tidak menjadi hambatan, sepertinya itu akan membuat kita (rata-rata) rasio kompresi 2:1 hampir gratis. Jika kita menginginkan 4:1, kita harus memilih algoritme yang berbeda, tetapi pada akhirnya kita akan duduk dan menunggunya.

Kami juga memiliki dua (setidaknya?) jenis data yang berbeda: Indeks; dan potongan data. Keduanya digunakan secara berbeda, dan saya kira dapat didiskusikan apakah masuk akal untuk memilih algoritma yang berbeda untuk mereka. Saya pribadi berpikir kita harus tetap dengan satu algoritma (apa pun yang kita pilih) sehingga menerapkan kembali Restic (dalam bahasa baru atau apa pun) tidak dibuat terlalu sulit. Dan agar kami tidak mengekspos diri kami pada bug dari dua algoritma kompresi yang menarik karena itu sulit untuk diuji untuk kasus sudut.

Saya harus tidak setuju dengan trade-off yang Anda rekomendasikan. Pencadangan dapat berjalan di latar belakang pada waktu yang tepat (mungkin dengan 10 yang bagus). Memulihkan mereka terjadi di bawah tekanan waktu. Trade-off yang relevan yang saya lihat adalah antara ukuran blok dan rasio kompresi. Blok yang terlalu kecil tidak akan memampatkan dengan baik dan meningkatkan overhead metadata. Blok terlalu besar mengurangi rasio dedup. Untuk kebanyakan algoritma kompresi, pengaturan level yang lebih tinggi tidak akan meningkatkan rasio kompresi untuk input kecil.

Selain itu, rasio kompresi yang lebih tinggi memungkinkan pengguna untuk menyimpan lebih banyak versi data mereka di ruang yang sama.

Ingat bahwa pengujian saya dengan snappy memiliki hasil: 1) ukuran cadangan yang lebih kecil (kompres, normal), dan 2) pencadangan dan pemulihan yang lebih cepat (pengkodean data, HMAC, dan transfer lebih sedikit). Menggunakan laptop yang sangat murah.

@cfcs saya

Di sini brotli selalu memiliki kompresi yang lebih cepat dan lebih baik.

@Crest Itu cukup adil, kami mungkin memiliki kasus penggunaan yang berbeda -- Saya hanya tidak menggunakan restic dengan cara yang sama seperti yang Anda lakukan. Saya melakukan pencadangan laptop saya dan ingin menyelesaikannya dengan cepat sehingga saya dapat pergi dengan laptop saya. Saya kira Anda sedang berbicara tentang pencadangan server atau mesin lain yang terus-menerus terhubung di mana tingkat pencadangan tidak begitu penting. Demikian pula saya tidak perlu mengembalikan semua data saya di bawah tekanan waktu; jika ada tekanan waktu (karena Anda menggunakannya dalam konteks profesional?), saya dapat secara selektif memulihkan data yang saya butuhkan, dan melanjutkan untuk melakukan sisanya nanti.

Anda membuat poin yang sangat bagus tentang "masukan kecil berkali-kali;"

@viric Efek yang Anda maksud dipertimbangkan dalam benchmark Squash di bawah bagian yang disebut Transfer + Processing :-)

@ibib ah,

@ibib dapatkah Anda menautkan dari mana Anda mendapatkan bagan itu?

Bagan berasal dari https://quixdb.github.io/squash-benchmark/

Saya telah melakukan beberapa tes dengan brotli dan zstd, dan saya perhatikan bahwa hasil saya tidak cocok sama sekali dengan benchmark squash. Kemudian saya mengerti bahwa patokan itu berumur 1,5 tahun.

zstd bekerja sangat baik untuk saya. Rasio cepat + tinggi, dan "level"-nya memungkinkan rentang yang sangat besar antara rasio cepat dan tinggi. Hal yang bagus.

Brotli bekerja sangat lambat untuk saya, tanpa rasio kompresi yang lebih baik daripada zstd yang jauh lebih cepat. Dan brotli tampaknya fokus pada file kecil teks bahasa Inggris (termasuk kamus bahasa Inggris). Untuk kompresi html atau sejenisnya.

Tolok ukur lebih baru yang saya temukan: https://github.com/inikep/lzbench

Jadi saya melemparkan test bed saya sekali lagi melawan zbackup dengan kompresi LZMA.

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

Mengesankan, bukan?

Cukuplah untuk mengatakan zbackup memiliki batasan dan kekurangannya sendiri.

Jadi, menurut tautan @viric lzbench, kompresor yang paling tepat adalah yang tidak memperlambat pencadangan (kecepatan kompresi tinggi?, >200 MB/detik), yang sebenarnya memiliki rasio kompresi yang baik (>=50), bukan?

Jadi, saya telah menyaring hasil dari tabel urutan berdasarkan rasio.

Saya juga telah melakukan pencarian _quick_ untuk implementasi Go (itulah sebabnya saya menyimpannya di tabel). Dicoret berarti saya tidak menemukan implementasi apa pun, yang menghilangkan hampir semuanya. Karena itu hanya pencarian cepat, saya menyimpan hasilnya. Pengecualian untuk zstd yang hanya pembungkus.

| Nama kompresor | Kompresi| Dekompresi.| Kompr. ukuran | Rasio |
| --------------- | -----------| -----------| ----------- | ----- |
| zstd 1.1.4 -1 | 242 MB/dtk | 636 MB/dtk | 73654014 | 34,75 |
| kadal 1.0 -30 | 258 MB/dtk | 867 MB/dtk | 85727429 | 40.45 |
| kepadatan 0,12,5 beta -3 | 253 MB/dtk | 235 MB/dtk | 87622980 | 41,34 |
| gipfeli 13-07-2016 | 233 MB/dtk | 451 MB/dtk | 87931759 | 41.49 |
| bernas 2011-12-24 -9 | 257 MB/dtk | 1263 MB/dtk | 90360813 | 42.63 |
| bernas 2011-12-24 -6 | 295 MB/dtk | 1268 MB/dtk | 92090898 | 43,45 |
| quicklz 1.5.0 -1 | 346 MB/dtk | 435 MB/dtk | 94720562 | 44,69 |
| kadal 1.0 -20 | 284 MB/dtk | 1734 MB/s | 96924204 | 45,73 |
| bernas 2011-12-24 -3 | 352 MB/dtk | 1222 MB/dtk | 97255186 | 45,89 |
| lzrw 15-Jul-1991 -4 | 243 MB/dtk | 392 MB/dtk | 100131356 | 47.24 |
| lzo1x 2.09 -1 | 394 MB/dtk | 551 MB/dtk | 100572537 | 47.45 |
| lz4 1.7.5 | 452 MB/dtk | 2244 MB/dtk | 100880800 | 47.60 |
| fastlz 0.1 -2 | 243 MB/dtk | 469 MB/dtk | 100906072 | 47.61 |
| lzo1y 2.09 -1 | 397 MB/dtk | 556 MB/dtk | 101258318 | 47,78 |
| lzo1x 2.09 -15 | 406 MB/dtk | 549 MB/dtk | 101462094 | 47,87 |
| kepadatan 0,12,5 beta -2 | 480 MB/dtk | 655 MB/dtk | 101706226 | 47,99 |
| lzf 3.6 -1 | 251 MB/dtk | 565 MB/dtk | 102041092 | 48.14 |
| tajam 1.1.4 | 327 MB/dtk | 1075 MB/dtk | 102146767 | 48.19 |
| blosclz 2015-11-10 -9 | 220 MB/dtk | 696 MB/dtk | 102817442 | 48,51 |
| bernas 2011-12-24 -0 | 384 MB/dtk | 1221 MB/dtk | 103072463 | 48.63 |
| lzo1x 2.09 -12 | 418 MB/dtk | 550 MB/dtk | 103238859 | 48.71 |
| kadal 1.0 -10 | 360 MB/dtk | 2625 MB/dtk | 103402971 | 48,79 |
| fastlz 0.1 -1 | 235 MB/dtk | 461 MB/dtk | 104628084 | 49.37 |
| lzrw 15-Jul-1991 -3 | 226 MB/dtk | 449 MB/dtk | 105424168 | 49,74 |
| lzf 3.6 -0 | 244 MB/dtk | 550 MB/dtk | 105682088 | 49,86 |
| lzo1x 2.09 -11 | 424 MB/dtk | 560 MB/dtk | 106604629 | 50.30 |
| lz4fast 1.7.5 -3 | 522 MB/dtk | 2244 MB/dtk | 107066190 | 50.52 |
| angin puting beliung 0.6a -1 | 233 MB/dtk | 334 MB/dtk | 107381846 | 50,66 |
| memcpy | 8657 MB/dtk | 8891 MB/s | 211947520 |100.00 |

LZ4 terlihat seperti kompresor yang paling tepat?

kira Anda ingin lz4 (>=1.7.0 r129) dan zstd (>=1.3.0), jika ada. kami juga menggunakan ini untuk borgbackup.

TAPI zstd sangat merdu dengan satu bilangan bulat tunggal, dari kecepatan lz4 menjadi lebih baik
dari kompresi xz. Itu akan membuat pengguna yang bahagia menjadi lebih lambat
kompresi dan kompresi cepat. Belum lagi zstd
dekompresi sangat cepat, terlepas dari upaya kompresi.

lz4 bertujuan cukup sempit.

Pada Sabtu, 16 Desember 2017 pukul 09:50:49AM -0800, TW menulis:

kira Anda ingin lz4 dan zstd, jika ada. kami juga menggunakan ini untuk borgbackup.

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/restic/restic/issues/21#issuecomment -352199097

--
(Escriu-me xifrat si saps PGP / Tulis ciphered jika Anda tahu PGP)
Kunci PGP 7CBD1DA5 - https://emailselfdefense.fsf.org/

Yah .. menurut https://github.com/restic/restic/issues/21#issuecomment -250983311 dari menjaga ketergantungan restic bebas, zstd bukanlah pilihan, untuk saat ini. Juga, ada beberapa topik tentang masalah paten/lisensi.

Adapun xz dan rasio kompresi tinggi, bahkan untuk pengaturan kompresi yang lebih rendah, menurut tabel, kompresi tercepat adalah sekitar 15MB/detik.

Jika persyaratan untuk pencadangan cepat diturunkan, katakanlah, >=30MB/dtk, kita dapat menambahkan:

| Nama kompresor | Kompresi| Dekompresi.| Kompr. ukuran | Rasio |
| --------------- | -----------| -----------| ----------- | ----- |
| xz 5.2.3 -9 | 1,70 MB/dtk | 56 MB/dtk | 48745306 | 23.00 |
| xz 5.2.3 -6 | 1,89 MB/dtk | 58 MB/dtk | 49195929 | 23.21 |
| xz 5.2.3 -3 | 4,18 MB/dtk | 55 MB/dtk | 55745125 | 26.30 |
| zstd 1.1.4 -8 | 30 MB/dtk | 609 MB/dtk | 61021141 | 28,79 |
| zling 2016-01-10 -2 | 32 MB/dtk | 136 MB/dtk | 61917662 | 29.21 |
| xz 5.2.3 -0 | 15 MB/dtk | 44 MB/dtk | 62579435 | 29,53 |
| zling 2016-01-10 -0 | 38 MB/dtk | 134 MB/dtk | 63407921 | 29,92 |
| zstd 1.1.4 -5 | 88 MB/dtk | 553 MB/dtk | 64998793 | 30,67 |
| lzfse 2017-03-08 | 48 MB/dtk | 592 MB/dtk | 67624281 | 31,91 |
| libdeflate 0,7 -6 | 64 MB/dtk | 609 MB/dtk | 67928189 | 32.05 |
| brotli 2017-03-10 -2 | 98 MB/dtk | 289 MB/dtk | 68085200 | 32.12 |
| zstd 1.1.4 -2 | 185 MB/dtk | 587 MB/dtk | 70164775 | 33.10 |
| angin puting beliung 0.6a -4 | 91 MB/dtk | 197 MB/dtk | 70513617 | 33.27 |
| libdeflate 0,7 -3 | 96 MB/dtk | 602 MB/dtk | 70668968 | 33,34 |
| xpack 02-06-2016 -1 | 98 MB/dtk | 506 MB/dtk | 71090065 | 33,54 |
| angin puting beliung 0.6a -3 | 119 MB/dtk | 188 MB/dtk | 72662044 | 34.28 |
| libdeflate 0,7 -1 | 117 MB/dtk | 570 MB/dtk | 73318371 | 34.59 |
| kadal 1.0 -42 | 90 MB/dtk | 938 MB/dtk | 73350988 | 34,61 |
| zstd 1.1.4 -1 | 242 MB/dtk | 636 MB/dtk | 73654014 | 34,75 |

Ada beberapa implementasi deflate, tetapi tidak yakin apakah mereka sebanding.
Kiri xz untuk referensi
zstd terlihat sangat menjanjikan. Sayang sekali tidak ada implementasi Go

@viric zstd tidak cukup kecepatan lz4.

tetapi jika seseorang ingin hanya memiliki satu kompresor daripada beberapa, zstd lebih fleksibel.

Maafkan keterlambatan saya. Beberapa komentar:

Kecepatan kompresi: Penting karena kami akan melakukan operasi ini setiap kali kami menambahkan blok, jadi kami sangat menginginkan sesuatu yang dapat mengikuti AES-NI dan I/O umum agar tidak menjadi hambatan. Kami mungkin tidak ingin memilih algoritme yang mengompresi lebih lambat daripada yang didekompresi karena kami memiliki kasus penggunaan yang berlawanan dari browser web yang algoritme baru ini (seperti zstd, lz4, brotli) dioptimalkan untuk (kami memiliki "sering kompres, jarang dekompresi" sebagai lawan dari "kompres sekali, dekompresi sering").

Tidak, tidak perlu mengompres pada kecepatan AES yang dipercepat perangkat keras. Kompresi adalah tentang waktu perdagangan untuk ukuran. Sangat diharapkan bahwa cadangan terkompresi akan memakan waktu lebih lama.

Misalnya, daripada menggunakan restic pada cadangan pribadi saya, saya masih menggunakan Obnam, karena di salah satu server kecil tempat saya menyimpannya, jika tidak dikompresi, mereka tidak akan muat. Pencadangan sudah memakan waktu berjam-jam, dan berjalan di latar belakang jadi saya bahkan tidak menyadarinya.

Saya tidak peduli jika cadangan terkompresi restic memakan waktu lebih lama. Memang, saya mengharapkan mereka, dan itu adalah pengorbanan yang harus saya lakukan. Tanpa kompresi semacam ini, restic tidak akan berguna bagi saya.

Kecepatan dekompresi: Kecepatan dekompresi hanya relevan saat kami memulihkan. Jika kami baik-baik saja dengan pemulihan yang lambat, kami dapat menerima kecepatan dekompresi yang lambat. Di sisi lain, kami juga memiliki metadata yang tidak ingin kami dekompresi secara perlahan, sehingga mungkin memerlukan dua algoritme yang berbeda.

Pemulihan dilakukan jauh lebih jarang daripada pencadangan, jadi kecepatan dekompresi tidak begitu penting. Seseorang menyebutkan bahwa mereka sering dilakukan di bawah tekanan waktu: ini benar, tetapi itu tidak berarti bahwa pemulihan harus secepat pencadangan, atau di mana pun mendekatinya.

Kami juga memiliki dua (setidaknya?) jenis data yang berbeda: Indeks; dan potongan data. Keduanya digunakan secara berbeda, dan saya kira dapat didiskusikan apakah masuk akal untuk memilih algoritma yang berbeda untuk mereka.

Mungkin tidak perlu (atau ide yang bagus) untuk mengompresi indeks sama sekali. Menjadi indeks, tampaknya tidak mungkin mereka akan memampatkan dengan baik sejak awal, karena seluruh tujuannya adalah untuk menyimpan data unik.

Saya pribadi berpikir kita harus tetap dengan satu algoritma (apa pun yang kita pilih) sehingga menerapkan kembali Restic (dalam bahasa baru atau apa pun) tidak dibuat terlalu sulit. Dan agar kami tidak mengekspos diri kami ke bug dari dua algoritma kompresi yang menarik karena itu sulit untuk diuji untuk kasus sudut.

Saya memahami kekhawatiran ini, tetapi saya pikir itu akan menjadi kesalahan. Setidaknya, format repo harus memungkinkan beberapa algoritma kompresi sehingga yang lebih baru dapat ditambahkan di masa mendatang. Mungkin harus ada modul yang dapat dipasang untuk kompresi sehingga pengguna dapat memilih yang ingin mereka gunakan, misalnya saya dapat membayangkan paket Debian seperti restic-xz , restic-zstd , dll. yang dapat diinstal pengguna jika mereka mau menggunakan algoritma tersebut. Kompresi data cadangan harus diabstraksikan sehingga restic memberikan fungsi kompresi beberapa data dan membuatnya kembali dikompresi, dan restic tidak peduli apa yang terjadi di antaranya; sama untuk dekompresi.

Jika persyaratan untuk pencadangan cepat diturunkan, katakanlah, >=30MB/dtk, kita dapat menambahkan

Itu tampaknya masuk akal bagi saya. Ingatlah bahwa cadangan lokal hanya satu jenis; cadangan jaringan cenderung tidak terhambat oleh kecepatan kompresi.

Namun, sekali lagi, ini harus disesuaikan oleh pengguna sehingga mereka dapat memilih solusi yang tepat untuk kebutuhan mereka.

Menambahkan hadiah $ 10 untuk :bir: :)

++

Berikut ini tautan ke BountySource jika ada orang lain yang ingin berkontribusi

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

Saya ingin tahu apakah ini dapat diimplementasikan dengan cara yang dapat dikonfigurasi pengguna sehingga pilihan kecepatan vs ukuran diserahkan kepada pengguna untuk memutuskan. Saya lebih suka kompres yang lebih tinggi sebagai default.

Mari kita putuskan kapan kita sampai di sana. Sebagai catatan: Saya baik-baik saja dengan memberi pengguna sedikit kontrol dalam hal kecepatan vs. ukuran.

+1 untuk restic yang membutuhkan implementasi kompresi. Saya menggunakan restic untuk mencadangkan gambar VM ke backblaze dan ingin mengompresnya sebelum mengunggah. Dalam kasus penggunaan saya, saya akan menukar jumlah waktu/CPU yang hampir tak terbatas untuk mengurangi ukuran data yang ditransfer/disimpan. Saya menyadari kecepatan lebih menjadi perhatian bagi sebagian orang. Memiliki arsitektur plug-able di mana beberapa algoritma dapat dipilih adalah kuncinya.

Saya senang membantu menguji karena ini dilihat lebih lanjut.

@ fd0 Sudah lama sejak saya bekerja di basis kode restic. Apakah mungkin bagi Anda untuk memberikan arahan cepat tentang pendekatan yang baik dan ke mana saya harus mencari?

@klauspost Ini tidak begitu banyak menambahkan kompresi pada tingkat teknis, itu agak mudah dilakukan, tetapi bagaimana kami menangani pemutakhiran format repo dengan cara yang kompatibel ke belakang. Saat ini saya sedang sibuk menulis ulang bagian pengarsip (agar hal-hal buruk seperti #549 hilang), setelah itu saya ingin menambahkan kompresi dan kemudian beralih ke repo v2.

Apa pendapat Anda tentang algoritma kompresi mana yang harus kita gunakan? Saya sedang berpikir untuk mendukung tiga mode:
1) Tidak ada kompresi
2) Kompresi "waktu linier" (tidak menambah banyak beban CPU)
3) "Kompresi maks"

Mungkin mode pertama dan kedua akan sama, saya belum yakin

Akan sangat luar biasa untuk dapat menggunakan sesuatu seperti zstd, tetapi sebagai kode Go asli. Damian mengisyaratkan bahwa mungkin tidak banyak pekerjaan untuk mem-porting versi Java atau C: https://twitter.com/dgryski/status/947259359628738560, apakah ada yang bisa saya lakukan untuk membuat Anda tertarik untuk mencobanya? :)

Saya telah melihat spesifikasi format zstd, dan bagi saya itu tidak sepele untuk diterapkan (baik). Sumber Java hanya dekompresi.

Untuk kompresi cepat, LZ4 harus bekerja dengan sangat baik. Port Go sangat baik. zstd akan lebih baik, tetapi saya akan menggunakan paket yang telah dicoba dan diuji, kecuali jika Anda ingin menggunakan implementasi cgo.

Untuk jalan tengah, kompresi kempis masih baik kecepatan/bijaksana kompresi. Diuji dengan baik, dll.

Kompresi tinggi sedikit lebih rumit. Namun, sepertinya ada implementasi LZMA(2) Go asli dalam paket github.com/ulikunitz/xz . Ada beberapa peringatan tentang stabilitas dan kinerja di README. Tidak perlu pembungkus xz, karena Anda sudah memiliki hash dan ukuran yang tidak terkompresi. Saya bisa memberikannya pusaran dan melihat bagaimana perbandingannya.

Saya melihat sumbernya untuk menemukan tempat alami untuk memasukkan langkah kompresi. Yang masuk akal bagi saya adalah melakukan kompresi di sini dan dekompresi di sini . Tapi saya melihat tantangan dalam mengidentifikasi dan melacak kompresi.

Anda juga dapat melihat "penaksir kompresibilitas" yang saya buat. Ini akan memberikan perkiraan cepat tentang seberapa kompresibel gumpalan data. Biasanya beroperasi pada >500MB/dtk, sehingga dapat digunakan untuk menolak data yang sulit dikompresi dengan cepat.

Anda juga dapat melihat "penaksir kompresibilitas" yang saya buat. Ini akan memberikan perkiraan cepat tentang seberapa kompresibel gumpalan data. Biasanya beroperasi pada >500MB/dtk, sehingga dapat digunakan untuk menolak data yang sulit dikompresi dengan cepat.

Suka penaksir kompresibilitas! Menghindari upaya untuk mengompresi data yang tidak dapat dikompresi akan mendapatkan banyak kecepatan.

Zstd memiliki sesuatu seperti itu bawaan: [1]

Zstd lebih cepat melewati data yang tidak dapat dimampatkan. Harapkan sesuatu > 1 GB/dtk

Meskipun saya belum menemukan tolok ukur eksplisit tentang itu.

Paket xz terlihat bagus untuk lzma. Melakukan beberapa tes cepat dengan pengaturan default:

| algoritma | tingkat | ukuran | sangat besar | mili | mb/s | rasio |
|-----------|-------|------------|-----------|---- ----|--------|--------|
| 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% |

Pertukaran kecepatan/kompresi yang sangat wajar. Semuanya adalah kinerja inti tunggal pada enwik9 - badan teks kompresibel sedang. Jelas, saya tidak punya waktu untuk menguji gambar VM penuh atau sesuatu seperti korpus 10GB dengan lebih banyak konten campuran.

Tampaknya lzma2 tidak menawarkan banyak hal dalam implementasinya saat ini di atas lzma standar. Karena Anda berurusan dengan blok kecil, perbedaannya harus cukup kecil.

Zstd memiliki sesuatu seperti itu di dalamnya

Ya, seperti halnya lz4 dan deflate, bagaimanapun, saya belum melihatnya secepat fungsi khusus.

zstd benar-benar mengesankan, tidak diragukan lagi. Tolok ukur menggunakan implementasi cgo:

| tingkat | ukuran | sangat besar | mili | mb/s | rasio |
|-------|------------|-----------|--------|------- -|--------|
| 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% |

Maafkan saya jika saya melewatkan sesuatu, tetapi saya tidak melihat pertanyaan-pertanyaan ini dijawab sebelumnya.

1. Kita sepertinya berbicara tentang kompresi pada level chunk, bukan pada level file, benar?
2. Jika demikian, itu jelas membatasi keefektifan karena data yang digandakan dalam banyak potongan dari satu file akan disimpan dan dikompresi untuk setiap potongan.
3. Namun, itu jelas tergantung pada ukuran potongan juga.
4. Jadi, berapa ukuran potongan rata-rata? Sepertinya ini adalah faktor penting dalam seberapa berguna kompresi.
5. Jika ukuran chunk cukup kecil, mungkin kita harus mempertimbangkan kompresi file penuh, pra-chunking untuk file yang sangat kompresibel (misalnya menggunakan estimator @klauspost ). Misalnya, file teks berukuran 50 MB (mis. file log, file mode Org besar, dll.) kemungkinan besar dapat dikompresi sebagai file tunggal. Tetapi jika itu dipotong terlebih dahulu, dan kemudian setiap potongan dikompresi secara individual, tidak berbagi indeks, itu akan sangat membatasi efektivitas kompresi (IIUC).

Terima kasih.

Jika kita akan mengompres seluruh file, itu dapat merusak algoritma de-duplikasi yang mungkin membuatnya kurang efisien.

Selain itu jangan lupa bahwa kompresi apa pun sambil menawarkan keuntungan luar biasa dari segi ruang , membuka kita untuk serangan saluran samping. Dari ukuran data terkompresi, seseorang dapat menebak isi data. Saya pikir ini disebutkan sebelumnya, tapi tetap saja.

@alphapa

Kita sepertinya berbicara tentang kompresi pada level chunk, bukan pada level file, benar?

Yap, pada tingkat potongan.

Jika demikian, itu jelas membatasi keefektifan karena data yang digandakan dalam banyak potongan dari satu file akan disimpan dan dikompresi untuk setiap potongan. Namun, itu jelas tergantung pada ukuran potongan juga. Jadi, berapa ukuran potongan rata-rata? Sepertinya ini adalah faktor penting dalam seberapa berguna kompresi.

Kami menargetkan 1MiB, tetapi bisa sebesar 8MiB.

Jika ukuran chunk cukup kecil, mungkin kita harus mempertimbangkan kompresi file penuh, pra-chunking untuk file yang sangat kompresibel (misalnya menggunakan estimator @klauspost ). Misalnya, file teks berukuran 50 MB (mis. file log, file mode Org besar, dll.) kemungkinan besar dapat dikompresi sebagai file tunggal. Tetapi jika itu dipotong terlebih dahulu, dan kemudian setiap potongan dikompresi secara individual, tidak berbagi indeks, itu akan sangat membatasi efektivitas kompresi (IIUC).

Pada awalnya saya ingin mengintegrasikan kompresi pada tingkat chunk, dan melihat seberapa baik kinerjanya dalam skenario kehidupan nyata. Kita dapat meninjau kembali ide ini nanti.

@klauspost Terima kasih banyak telah meluangkan waktu untuk membandingkan beberapa algoritma/implementasi dan rekomendasi Anda, saya menghargainya! Meskipun akan menyenangkan untuk memiliki zstd, saya pikir tidak bergantung pada cgo jauh lebih penting untuk proyek secara keseluruhan. Dan menggunakan estimator kompresibilitas adalah ide bagus, saya suka itu.

Tempat yang Anda sebutkan untuk menambahkan kompresi/dekompresi terdengar bagus, tetapi kami perlu melacak metadata untuk itu di tempat lain. Saya pikir kita mungkin akan menambahkan arti pada bit dalam byte di header paket, lihat http://restic.readthedocs.io/en/latest/100_references.html#pack -format. Ini adalah bagian yang perlu dilakukan dengan sangat hati-hati.

Jadi, izinkan saya menyelesaikan dengan #1494, lalu kita akan melihat bahwa ini akan teratasi.

@sanmai re: side-channels: Saya mengungkitnya pada awalnya.
Berbagai solusi disarankan, saya pribadi akan puas dengan:

• memiliki opsi konfigurasi untuk penggunaan kompresi daftar putih/daftar hitam (mirip dengan apa yang kami miliki untuk penyertaan file)

Ide lain adalah mencoba menyembunyikan batas chunk dalam file paket, yang secara teoritis akan membuatnya lebih sulit, tetapi saya merasa bahwa Anda masih dapat mengatur waktu penulisan jaringan, dan saluran samping seperti sejauh mana sistem file tempat potongan itu ditulis. dan seterusnya dapat digunakan untuk menyimpulkan batas, jadi saya merasa bahwa yang paling aman/termudah adalah dengan menyarankan untuk tidak mengompresi data sensitif.

Ini akan luar biasa! :bir: +$10

Hanya membuangnya di luar sana, tetapi mengesampingkan lzma atau algo kompresi yang lebih umum, bagaimana dengan pengkodean run-length atau zero-squashing? Atau apakah ini tidak cukup berguna untuk cukup banyak orang?

(Saya memiliki anjing dalam perburuan ini, saya sering mencadangkan file WAV besar dengan banyak keheningan.)

+$15

Hanya membuangnya di luar sana, tetapi mengesampingkan lzma atau algo kompresi yang lebih umum, bagaimana dengan pengkodean run-length atau zero-squashing? Atau apakah ini tidak cukup berguna untuk cukup banyak orang?

Juga berguna untuk mencadangkan drive VM dengan sebagian besar ruang kosong/file jarang (tidak yakin apakah restic sudah mendukung pencadangan/pemulihan file jarang)

@bherila restic belum mendukung pengarsipan/pemulihan file yang jarang, file akan disimpan dalam repo seolah-olah hanya berisi banyak nol. Blok nol besar ini dideduplikasi, jadi tidak akan memakan banyak ruang di repo. Untuk pemulihan, Anda akan mendapatkan file biasa (tidak jarang) tanpa "lubang".

Saya hanya ingin memeriksa, apakah sudah ada semacam kompresi? Saya telah mencadangkan beberapa komputer, termasuk satu dengan data 50GB, dan saya mendapatkan angka yang jauh lebih rendah di server:

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

@Alwaysin Ini mungkin deduplication , kecuali beberapa file dikecualikan tentu saja.

@rawtaz terima kasih, saya tidak tahu tentang deduplikasi, pasti begitu!

@iluvcapra squashing blok berulang besar sudah diimplementasikan melalui deduplikasi, seperti yang disebutkan oleh @rawtaz.

@klauspost apakah Anda melihat ini? https://github.com/mvdan/zstd

Ya, tapi sejujurnya stream decoder adalah bagian yang mudah. Saya telah menyelesaikan en/decoding FSE dan menyiapkan encoder Huffman. Setelah decoding Huffman selesai, dekoder aliran zstd cukup mudah, dengan enkoder lengkap menjadi bagian terakhir.

LZ4 sangat memadai dan juga akan menjadi kemenangan cepat.

Mengapa tidak menambahkan lz4 dan membuat PR lain untuk mendukung zstd?

Mengapa tidak menambahkan lz4 dan membuat PR lain untuk mendukung zstd?

@dave-fl karena kita harus sangat berhati-hati saat mengubah format repositori. Itu harus dilakukan dengan cara yang kompatibel ke belakang. Bagian terpenting dari keseluruhan proyek adalah format repo, bukan implementasinya. Orang-orang bergantung pada kami untuk tidak mengacaukan format sehingga mereka dapat memulihkan data mereka :)

Saya pikir kita tidak bisa menunggu terlalu lama dengan kompresi. Saya baru saja melakukan beberapa tes pada beberapa repositori cadangan server, saya benar-benar tidak memenangkan apa pun ketika saya gzip repositori! Seperti @Alwaysin saya sudah menang 30% dengan deduplikasi.

Tentang cara yang kompatibel ke belakang, maksud Anda Restic harus membaca kedua format atau alat untuk bermigrasi dari yang lama ke yang baru? Ketika Restic tidak di v1.0.0 saya percaya tidak apa-apa untuk bermigrasi saja.

Saya baru saja melakukan beberapa tes pada beberapa repositori cadangan server, saya sama sekali tidak memenangkan apa pun ketika saya gzip repositori!

Uhm, itu yang diharapkan: Semua data dalam repo dienkripsi, jadi hampir tidak bisa dikompresi sama sekali. Jika kompresi digunakan, itu harus dilakukan pada data sebelum mengenkripsinya.

Saya tidak melihat bagaimana menggunakan LZ4 membuat hal-hal yang tidak kompatibel ke belakang. Kompresi adalah kompresi. Mengapa tidak mendukung banyak format?

Anda benar, saya tidak memikirkan itu.
Namun ketika saya gzip sumber saya tidak menang lebih dari 30%, deduplikasi sudah sangat efisien pada direktori besar dengan banyak duplikat. Tapi tentu saja dengan keduanya bisa mengesankan.
Dengan zpaq yang melakukan kompresi dan deduplikasi, saya menang sedikit lebih banyak, tidak terlalu banyak.
Saya sangat terbuka untuk menguji cabang dengan kompresi, tidak masalah jika itu tidak kompatibel!

Saya tidak melihat bagaimana menggunakan LZ4 membuat hal-hal yang tidak kompatibel ke belakang. Kompresi adalah kompresi. Mengapa tidak mendukung banyak format?

Apa yang terjadi jika 2 klien menggunakan repo yang sama tetapi 1 di antaranya menggunakan versi restic yang lebih lama yang tidak mendukung kompresi? Fitur ini perlu dirancang dengan hati-hati dengan mempertimbangkan semua kemungkinan kasus sudut.

Saya lebih suka tidak ada kompresi daripada solusi setengah kerja yang mungkin merusak cadangan sebelumnya.

Saya pikir sudah cukup banyak diskusi tentang masalah penambahan kompresi. Saya dapat melihat itu adalah fitur yang sangat dinanti. Saya akan menangani ini selanjutnya setelah menyelesaikan kode pengarsipan baru (lihat #1494).

Tolong jangan menambahkan komentar lebih lanjut, terima kasih!

@dimejo Apa yang Anda

Saya berani mengatakan bahwa versi CGO dari zstd terlihat agak portabel :)

saya melihat betapa layak untuk menulis implementasi golang zstd, secara singkat, berdasarkan spesifikasi .

zstd sebagian besar semua algoritma in-house tetapi (opsional) bergantung pada checksum xxHash-64 untuk pemeriksaan kesalahan, dan ada port golang itu . karena bit opsional, yah, opsional, Anda tidak perlu mengimplementasikan bagian-bagian itu untuk mendapatkan dukungan zstd untuk pembaca/penulis di restic. zstd mendukung konsep "kamus" untuk mengoptimalkan kompresi - saya tidak yakin bagaimana itu akan berinteraksi dengan restict, tetapi akan menjadi area penelitian yang menarik untuk mengompresi bagian tertentu dari arsip, misalnya JSON atau aliran metadata. jika tidak, implementasi juga dapat dilewati karena bersifat opsional.

Di mana itu menjadi lebih sulit, tentu saja, adalah di mana pengkodean entropi dimulai. zstd menggunakan pendekatan baru di sana yang disebut Entropi Keadaan Hingga (FSE, variasi dari [ANS](https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#, yang hanya ada implementasi C. bit pengkodean entropi lainnya diimplementasikan dengan pengkodean huffman , di mana ada beberapa implementasi, termasuk dua di pustaka standar: satu di compress.flate dan satu lagi di net.http2.hpack , yang agak aneh.

Dari apa yang saya tahu, segala sesuatu yang lain adalah lem di atas itu ... Beberapa pohon huffman, urutan, bingkai dan blok. Ada properti menarik dalam cara blok dan bingkai dibangun juga yang mungkin memetakan dengan baik ke dalam gumpalan restic, yang memungkinkan untuk mengompresi repositori secara keseluruhan sambil menjaga gumpalan terpisah di dalam, meskipun saya belum melihatnya secara detail . Mungkin juga membuat penggabungan antara format repositori dan kompresi tidak dapat diterima.

zstd sebagian besar lebih rumit daripada gzip atau xzip, dengan sekitar 70k baris kode (menurut cloc) dibandingkan dengan 36k dan 12k, masing-masing. itu termasuk tes, namun, yang banyak: ketika itu diabaikan, implementasinya sendiri hampir sebanding dengan gzip (~ 34k).

jadi, singkatnya, hanya masalah waktu sebelum ini diimplementasikan. Saya percaya mesin seperti itu juga dapat memanfaatkan paralelisme golang karena "bingkai" zstd tidak tergantung satu sama lain. tidak jelas bagi saya, bagaimanapun, bagaimana bingkai digunakan: sebagian besar aliran yang saya uji hanya memiliki satu ( zstd /etc/motd ) atau dua ( zstd isos/Fedora-Workstation-Live-x86_64-27-1.6.iso ) bingkai (seperti yang ditemukan oleh binwalk -R "\x28\xb5\x2f\xfd" ), jadi mungkin bukan keuntungan di sana, karena blok saling terkait dan kurang dapat diparalelkan ...

anyways, semua diperdebatkan kecuali seseorang di sini ingin benar-benar duduk dan port itu, tetapi saya pikir saya akan membagikan apa yang saya temukan saat membaca hal itu ... mengingat zstd adalah perluasan dari bagian LZMA dari keluarga kompresor LZ77, seharusnya 'tidak layak untuk port...

Ada update tentang kompresi? Saya tahu bahwa banyak orang ingin menunggu zstd , tetapi apa yang salah dengan menerapkan lz4 atau lzo atau lzma ?

Jika ada pembaruan, masalah ini akan diperbarui.

Mari kita coba hormati permintaan penulis untuk sementara waktu:

Tolong jangan menambahkan komentar lebih lanjut, terima kasih!

@fd0 , hanya ingin menunjukkan bahwa tampaknya ada implementasi Go murni dari algoritma zstd https://github.com/klauspost/compress/tree/master/zstd . Saya sendiri belum mencoba ini. Tapi ini membuat saya bersemangat tentang kemungkinan dukungan kompresi di restic.

Saya tidak tahu hal-hal Go zstd (kecepatan? kualitas kode? pemeliharaan?), tetapi hal-hal C zstd adalah tentang semua kebutuhan alat cadangan karena mendukung berbagai dari kompresi cepat/sedikit hingga lebih lambat/tinggi.

Jika kita belum memiliki semua algo kompresi lainnya (lz4, zlib, lzma) di borgbackup dan akan mulai menambahkan kompresi sekarang, kira kita bisa hidup hanya dengan zstd dan tidak ada.

Sebagai masalah selera/preferensi, defaultnya bisa jadi tidak ada (seperti sebelumnya) atau level zstd yang sangat cepat (yang secara keseluruhan masih membuat sebagian besar pencadangan lebih cepat karena lebih sedikit data untuk ditransfer).

Halo,
menurut saya kompresi bukanlah suatu keharusan untuk memiliki fitur untuk restic. Saya telah membandingkan pencadangan data saya yang dilakukan dengan Duplikati (dengan kompresi) dan restic (tanpa kompresi) dan keseluruhan ruang yang digunakan sangat mirip.
Saya perlu restic hanya untuk mendapatkan cadangan inkremental yang cepat dan andal. Tak perlu patah sedikit pun...
Pemulihan juga penting dan restic cocok untuk pemulihan bencana. Duplikati adalah mimpi buruk karena jika Anda kehilangan db lokal, tugas perbaikan membutuhkan waktu berhari-hari ...

Terima kasih @fd0 dan terima kasih kepada semua kontributor!

@filippobottega jika Anda tidak melihat perbedaan besar dalam eksperimen Anda yang berarti:

• bahwa data Anda tidak (banyak) dapat dikompresi (tetapi ini tidak terjadi secara umum), atau
• duplikat itu memiliki beberapa efisiensi penyimpanan yang lebih buruk yang tidak terkait dengan kompresi (misalnya karena format penyimpanan yang berbeda, granularitas, algoritme, apa pun ...), sehingga penghematan kompresi dikompensasi oleh kerugian di area lain.

keduanya tidak berarti bahwa kompresi tidak ada gunanya.

@ThomasWaldmann Saya tidak melihat perbedaan besar untuk alasan pertama.
Data saat ini sudah dikompresi dalam banyak cara: docx, xlsx, pptx, zip, 7z, jpeg, tif, dan sebagainya semuanya adalah format terkompresi. Dan juga gambar iso berisi file terkompresi. Untuk alasan ini kompresi tidak ada gunanya dalam restic saya pikir.

@filippobottega Pandangan Anda agak sempit tentang data apa yang digunakan orang lain untuk dicadangkan. Bagaimana dengan dump SQL, kode sumber, kumpulan data, gambar mentah, dan sebagainya? De-duplikasi melakukan pekerjaan yang baik dalam mengurangi ukuran delta di antara cadangan, namun tidak mengurangi ukuran asli kumpulan data. Dalam hal format terkompresi ini bisa berarti banyak gigabyte. Belum lagi bahwa menyimpan format yang tidak dikompresi dan kemudian mengompresi + menghapus duplikat dapat memberikan hasil yang lebih baik daripada menghapus duplikat file yang sudah dikompresi.

SQL dump adalah pemikiran pertama saya, tetapi restic juga mencadangkan server email saya dan tampaknya mendapatkan kompresi keseluruhan yang lebih baik berdasarkan beberapa snapshot RAR yang saya ambil saat berpindah dari Duplicati ke restic.

Saya dapat melihat kasus penggunaan untuk membuat kompresi opsional dan memiliki daftar default jenis file, tetapi kompresi akan menghemat jumlah uang yang masuk akal.

@mrschyte

Pandangan Anda agak sempit tentang data apa yang digunakan orang lain untuk membuat cadangan.

Sekarang sekarang, tidak perlu menjadi pribadi. Perspektifnya sama validnya dengan Anda dan patut dipertimbangkan. Saya telah menemukan bahwa sebagian besar data yang saya cadangkan sudah dikompresi karena format file.

Bagaimana dengan SQL dump?

Apakah Anda benar-benar menyimpan dump SQL Anda tidak terkompresi? Saya menyimpan semua milik saya sebelum mencadangkannya, karena saya tidak perlu menyimpannya mentah-mentah.

kode sumber, kumpulan data, gambar mentah, dan sebagainya

Saya pikir satu-satunya kasus penggunaan yang valid untuk cadangan terkompresi adalah dengan file besar yang tidak terkompresi dengan banyak pengulangan _yang secara aktif digunakan dan dengan demikian tidak disimpan terkompresi_. Dalam pengalaman saya (yang mencakup bertahun-tahun mengelola data orang lain), sangat sedikit data yang termasuk dalam kategori ini. Setidaknya, tidak cukup untuk membuat perbedaan besar dalam kasus-kasus itu.

namun itu tidak mengurangi ukuran asli kumpulan data.

Bisa dibilang, itu bukan tugas program cadangan. Seharusnya tidak menyentuh data asli.

Belum lagi bahwa menyimpan format yang tidak dikompresi dan kemudian mengompresi + menghapus duplikat dapat memberikan hasil yang lebih baik daripada menghapus duplikat file yang sudah dikompresi.

Banyak algoritma kompresi mengandalkan duplikasi untuk melakukan pekerjaan mereka (lihat kamus flate), jadi saya tidak yakin dengan ini _secara umum_ meskipun saya setuju ini benar setidaknya beberapa kali.

(Saya tidak mengatakan bahwa kompresi dalam restic adalah _bad_ bila dilakukan dengan benar, saya hanya berpendapat bahwa itu tidak perlu menjadi prioritas -- terutama dibandingkan dengan masalah kinerja yang masih ada -- dan kita harus menghormati batasan waktu @ fd0 dan keinginan sehubungan dengan visi.)

@mholt Saya setuju secara umum, namun melakukan pencadangan root (melalui beberapa dump atau bahkan mengulangi konten /), menghasilkan rasio kompresi yang bagus untuk saya. Tidak penting , karena total yang digunakan sudah kecil, tetapi saya mendapatkan penghematan sekitar 50%, dan itu selalu menyenangkan untuk dimiliki secara "gratis" sejauh menyangkut pengguna akhir.

Coba tes ini.

1. ambil SQL dump atau file lain yang tidak terkompresi. Kompres dan kemudian
   gunakan restic back up.
2. hapus tabel dari database SQL, ambil dump kedua, lalu kompres,
   kemudian gunakan restic untuk mencadangkannya.

Saya yakin Anda akan menemukannya karena kompresi dilakukan SEBELUM
deduplikasi Anda hampir seluruhnya akan mengalahkan algoritma dedup restics.
Namun, jika restic dapat menangani kompresi SETELAH menghapus duplikasi Anda
harus mendapatkan output keseluruhan yang jauh lebih kecil.

Di industri penyimpanan perusahaan dengan alat seperti DataDomain selalu
direkomendasikan untuk memasukkan data ke perangkat penyimpanan dalam format yang tidak terkompresi
format dan biarkan perangkat melakukan deduplikasi dan kemudian kompresi. NS
urutan umum bahwa alat-alat ini harus diterapkan adalah deduplikasi,
kompresi, lalu enkripsi. Pikirkan tentang ini sebentar .... kan?
benar-benar ingin menghabiskan semua CPU ekstra mengompresi banyak data yang sama
kali hanya untuk itu untuk ditipu dan pada dasarnya dibuang? Nya
diterima secara umum bahwa yang terbaik adalah mengurangi kumpulan data melalui dedup terlebih dahulu
sebelum mengeluarkan tugas yang berpotensi berat untuk melakukan kompresi.

Pada Jumat, 2 Agustus 2019 di 01:29 Brandon Schneider [email protected]
menulis:

@mholt https://github.com/mholt Saya setuju secara umum, namun melakukan
cadangan root (melalui beberapa dump atau bahkan mengulangi isi /),
menghasilkan rasio kompresi yang bagus untuk saya. Tidak penting , sebagai total
bekas sudah kecil, tapi saya mendapatkan penghematan sekitar 50%, dan itu selalu menyenangkan
untuk dimiliki secara "gratis" sejauh menyangkut pengguna akhir.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/restic/restic/issues/21?email_source=notifications&email_token=AC3I762ZVGTTJL4TF3ODZILQCRVIXA5CNFSM4AXPP352YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVWZ78HJKTDN5
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AC3I767IQQD3CZBIWM37C6TQCRVIXANCNFSM4AXPP35Q
.

Apakah Anda benar-benar menyimpan dump SQL Anda tidak terkompresi? Saya menyimpan semua milik saya sebelum mencadangkannya, karena saya tidak perlu menyimpannya mentah-mentah.
Bisa dibilang, itu bukan tugas program cadangan. Seharusnya tidak menyentuh data asli.

Sepertinya pandangan seperti ini menghalangi penyimpanan data yang efisien? Gagasan bahwa setiap program dan operasi ekspor harus mengimplementasikan format kompresi adhoc-nya sendiri adalah sesuatu yang saya coba hindari, karena mencegah deduplikasi/kompresi/dll bekerja pada apa pun kecuali lingkup per-file (atau direktori tarball) yang telah ditentukan sebelumnya . Mengompresi file secara individual kehilangan kemampuan untuk menemukan kesamaan di berbagai file/dumps/etc dan selanjutnya Anda kehilangan semua manfaat deduplikasi. Menjaga hal-hal yang tidak terkompresi memungkinkan sistem file (zfs, btrfs, dll) untuk melakukan ini semua untuk Anda, dan lebih baik karena dapat mengompres dan mendedupe di seluruh folder, snapshot, dll. dan mengabstraksi semuanya sambil mempertahankan kompatibilitas dengan alat yang perlu bekerja dengan data yang tidak terkompresi.

Kompresi dapat dilihat hanya sebagai pengoptimalan tambahan pada deduplikasi restic teratas, tetapi tampaknya tidak kompatibel satu sama lain jika dilakukan secara terpisah... Menyarankan bahwa seseorang harus mengompresi dan memproses file sebelum mencadangkannya membawa semuanya kembali ke alur kerja di mana Anda mungkin juga gunakan saja rsync/rclone, jadi mengapa menggunakan restic sejak awal?

Sepertinya pandangan seperti ini menghalangi penyimpanan data yang efisien? Gagasan bahwa setiap program dan operasi ekspor harus mengimplementasikan format kompresi adhoc-nya sendiri adalah sesuatu yang saya coba hindari, karena mencegah deduplikasi/kompresi/dll bekerja pada apa pun kecuali lingkup per-file (atau direktori tarball) yang telah ditentukan sebelumnya . Mengompresi file secara individual kehilangan kemampuan untuk menemukan kesamaan di berbagai file/dumps/etc dan selanjutnya Anda kehilangan semua manfaat deduplikasi. Menjaga hal-hal yang tidak terkompresi memungkinkan sistem file (zfs, btrfs, dll) untuk melakukan ini semua untuk Anda, dan lebih baik karena dapat mengompres dan mendedupe di seluruh folder, snapshot, dll. dan mengabstraksi semuanya sambil mempertahankan kompatibilitas dengan alat yang perlu bekerja dengan data yang tidak terkompresi.

Bukan hanya penyimpanan data yang efisien, tetapi juga alur kerja yang ada. Saya ingin produk cadangan untuk mencadangkan data saya dengan andal dan efisien, tidak memaksakan alur kerja di seluruh aspek sistem lainnya. Jauh lebih penting untuk cadangan (yang disimpan, berpotensi tanpa batas waktu) untuk disimpan secara efisien sedangkan data kerja langsung harus disimpan dalam format terbaik untuk digunakan secara aktif.

Sekarang ada kasus di mana masuk akal untuk mengompres sebelum menyimpan, terutama dengan data yang sangat kompresibel pada sistem penyimpanan yang lambat, tetapi ini adalah pengecualian lebih dari aturan dalam pengalaman saya.

Kompresi +1 akan sangat membantu saya! Di tempat kerja sebagai insinyur perangkat lunak, saya mencadangkan seluruh folder rumah saya, yang memiliki banyak kode sumber yang tidak terkompresi (dan dalam bahasa dinamis, seperti ruby ​​atau python, hampir selalu kode sumber -- bahkan sebagian besar dependensi).

Di rumah saya mencadangkan seluruh / , sekali lagi termasuk banyak hal yang mendapat manfaat dari kompresi, seperti binari, file man, file sumber daya, dll.

Tentu saja saya bisa mengompres semuanya, dan melakukan banyak transformasi sebelum saya mencadangkannya, tetapi itu akan mengalahkan banyak kenyamanan hanya dengan menjalankan perintah yang sangat sederhana, dan bisa mendapatkan cadangan, serta dengan mudah memulihkan hal-hal.

Sekarang tentu saja ada banyak kelas file yang tidak terkompresi dengan baik, tetapi tidak ada yang mengatakan bahwa mereka harus dipaksa untuk dikompresi. Ada banyak pendekatan di luar sana untuk menyelesaikan ini -- daftar putih jenis file mana yang harus dikompres, daftar hitam file mana yang tidak boleh, atau bahkan yang paling sederhana: coba kompres, dan jika ukuran yang dihasilkan tidak membaik, simpan tanpa kompresi (saya percaya ZFS menggunakan pendekatan ini ketika kompresi pada disk diaktifkan).

Pada akhirnya, kompresi adalah contoh trade-off ruang vs waktu klasik: apakah Anda ingin membayar lebih banyak cpu, atau lebih banyak penyimpanan? Dalam kasus saya, penyimpanan mendominasi biaya saya, jadi saya pikir akan lebih bagus jika quad-core saya sedikit lebih panas, dan kemudian tagihan hosting file saya lebih kecil.

Akhirnya, saya mencadangkan sedikit lebih dari 4 TB ke penyedia cloud dan kecepatan unggah saya tetap lemah, sehingga kompresi bonus akan membuat proses pencadangan saya lebih cepat, bukan lebih lambat -- cpu saya dapat lebih dari sekadar mengimbangi koneksi VDSL saya yang buruk .

Yap, saya hanya bisa setuju dengan semua orang lain di sini. Kompresi cukup penting dan saya benar-benar tidak melihat argumen mengapa restic tidak memilikinya.

@mholt Saya sepenuhnya setuju dengan Anda. Setiap kata.
Dalam kompresi rantai alat saya datang sebelum deduplikasi restic karena, misalnya, saya menggunakan TFS sebagai kontrol sumber dan semua sumber sudah dikompresi dalam SQL Backup dan gambar aplikasi dikompresi dalam file pengaturan msi atau arsip 7z. Saya hanya perlu cara cepat dan sederhana untuk mendapatkan delta setiap hari dan mengirimkannya ke cloud untuk menerapkan rencana pemulihan bencana yang aman.
Saya pikir @fd0 perlu memfokuskan waktunya untuk menyelesaikan masalah daripada mencoba menambahkan kompleksitas lain ke produk.

Hanya menimpali dengan sedikit perbandingan yang saya lakukan antara borg menggunakan auto,zstd kompresi dan restic (tanpa kompresi), pertama pada / , kemudian pada /home , tidak termasuk hal-hal seperti gambar VM dan gambar buruh pelabuhan (karena saya juga tidak mencadangkannya di cadangan dunia nyata). Mesin uji adalah mesin pengembangan perangkat lunak harian saya, yang berisi banyak file biner, beberapa gambar terkompresi dan file audio, tetapi juga cukup banyak kode sumber teks biasa, yang seharusnya dikompres dengan cukup baik:

/ : 1053136 file, 92,9 GiB

• borg, tidak ada: 17:27 menit, 64,1 GiB
• borg, zstd: 19:29 menit, 40,6 GiB
• istirahat: 09:45 menit, 62,4 GiB

/home : 221338 file, 58,3 GiB

• borg, zstd: 09:06 menit, 30,7 GiB
• restic: 04:36 min, 39,4 GiB
  Saya menghilangkan borg tanpa kompresi di sini, karena kira-kira sama dengan restic sejauh menyangkut ruang penyimpanan.

Pertama, saya ingin memuji restic karena hampir persis dua kali lebih cepat pada test case itu. Selain borg lebih lambat, mungkin menarik bahwa kompresi hanya menambahkan ~2 menit ke durasi pencadangan keseluruhan (+11%), tetapi secara signifikan mengurangi data yang akan disimpan untuk kasus / (-35 %). Dalam hal direktori home saya, penghematan penyimpanan kira-kira 20%.

(Pengujian dilakukan ke disk eksternal untuk kasus itu. Saat mencadangkan ke penyimpanan jarak jauh, waktu pencadangan sebagian besar bergantung pada bandwidth unggahan, setidaknya ketika kecepatan CPU dan IO jauh lebih tinggi daripada jaringan. Saya menguji ini dan borg dengan kompresi sebenarnya lebih cepat daripada restic, karena hasil kompresi lebih sedikit data yang ditransfer). Secara keseluruhan, saya sangat mendukung restic mendapatkan dukungan kompresi, idealnya menggunakan deteksi otomatis untuk memeriksa apakah potongan mendapat manfaat dari kompresi.

@nioncode Jika perhitungan saya benar, Anda mencadangkan sekitar 100/150MB/s. Itu di bawah apa yang dapat dikompres oleh zstd. Karena kompresi tidak sinkron, seharusnya tidak ada perlambatan. Bahkan mungkin sedikit lebih cepat karena lebih sedikit yang harus ditulis.

Saya tahu bahwa pengarsipan VM mungkin merupakan kasus penggunaan, tetapi saya mencoba menghindari kebutuhan untuk melakukannya.
Saya mencoba mengotomatiskan seluruh bangunan VM mulai dari file iso dan pengaturan.
Dalam kasus pemulihan bencana, saya ingin dapat memulihkan seluruh VM menggunakan cadangan file pengaturan, dokumen, dan cadangan basis data. Dan saya mencoba melakukannya tanpa interaksi pengguna.
Dengan cara ini saya dapat menghindari kebutuhan untuk mengompres dan mencadangkan banyak file sampah yang terdapat dalam VM seperti file temp, file yang tidak terkompresi seperti exe dan dll, dan sebagainya.
Saya tahu, ini tidak sederhana, tetapi saya dapat menghindari untuk mengompres dan menghapus duplikat file GB yang sama dan tidak berguna yang menghemat ruang disk dan bandwidth.

Mari kita tidak mengacaukan utas ini tentang siapa yang melakukan sesuatu. Sudah cukup.

Kompresi adalah fitur yang diinginkan banyak orang (termasuk saya sendiri) dan dapat menghemat penyimpanan cadangan dan waktu unggah jika konektivitas internet lambat-sedang, bagi sebagian orang bahkan 30% atau lebih.

Namun, tidak semua orang membutuhkannya dan beberapa orang telah menyesuaikan alur kerja mereka dengan cara yang cerdas untuk menghadapinya - atau hanya memiliki uang atau bandwidth atau keduanya untuk tidak peduli.

Bagaimanapun, kedua belah pihak telah berbicara.

@ bjoe2k4 atau khawatir tentang implikasi keamanan negatif dari mengompresi data sebelum mengenkripsinya, yang memberikan informasi tentang data teks biasa, seperti juga telah diangkat sebagai argumen beberapa kali di utas ini selama beberapa tahun terakhir. :)

Kecuali kompresi menjadi wajib maka masalah keamanan kompresi hanyalah tradeoff yang dapat dilakukan pengguna. Saya akan mengambil cadangan lebih cepat dan mengurangi biaya bulanan dan satu kali atas risiko teoretis ini (risiko yang kemungkinan besar tidak dapat dieksploitasi karena set data saya besar dan perubahannya tidak dapat diprediksi, sehingga kebisingan akan menghilangkan upaya apa pun untuk menghasilkan sinyal dari kompresi).

Saya tidak percaya ada orang yang berbicara tentang membuat kompresi wajib.

Kasus penggunaan khusus saya adalah mencadangkan kumpulan besar CSV dan SQL dump. File-file ini akan SANGAT dapat dikompresi... dan saya tidak ingin/tidak dapat mengompresnya terlebih dahulu.

Saya sangat ingin memiliki fitur kompresi karena saya membayar untuk setiap GB penyimpanan online

Karena diskusi ini menjadi sedikit lebih aktif sekarang saya ingin berbagi beberapa temuan saya dengan versi istirahat yang ditambal dari beberapa teman saya. Mereka menambahkan kompresi ke restic (kurang lebih cepat dan kotor sejauh yang saya tahu) dan saya akan memberi tahu mereka tentang posting ini sehingga mereka dapat mengomentari spesifik implementasi jika ada yang tertarik.
Kasus penggunaan saya adalah beberapa perangkat lunak perbankan yang sangat jelek yang memiliki format database sendiri. Kami harus menggunakan perangkat lunak ini untuk alasan peraturan dan data yang kami miliki adalah beberapa TB dari file yang agak besar yang dapat dikompresi hingga 90% dari ukuran aslinya. Jadi, jelas sekali, kompresi akan menghemat banyak penyimpanan cadangan, waktu pencadangan, dan waktu pemulihan.
Temuan saya ketika membandingkan restic upstream, restic yang ditambal dengan kompresi dan solusi cadangan kami saat ini dengan tar dapat ditemukan di sini: https://Gist.github.com/joerg/b88bf1de0ce824894ffc38f597cfef5f

| Alat | Waktu Cadangan (m:s) | Waktu Pemulihan (m:s) | Ruang cadangan (G) | Ruang cadangan (%) | Cadangan (MB/dtk) | Pulihkan (MB/dtk) |
| --------------------------- | ----------------- | ------------------ | ---------------- | ---------------- | ------------- | -------------- |
| Tar | 4:42 | 5:19 | 11 | 9,6% | 404 | 357 |
| Restic S3 lokal Hulu | 10:04 | 30:56 | 102 | 89,5% | 189 | 61 |
| Kompres lokal S3 Restic | 5:43 | 19:28 | 8.6 | 7,5% | 332 | 98 |
| Hilir Lokal Restic | 8:33 | 26:06 | 102 | 89,5% | 222 | 73 |
| Kompres Lokal Istirahat | 5:21 | 16:57 | 8.6 | 7,5% | 355 | 112 |
| Restic S3 Remote Upstream | 17:12 | 46:06 | 102 | 89,5% | 110 | 41 |
| Kompres Jarak Jauh S3 Restic | 5:27 | 21:42 | 8.6 | 7,5% | 349 | 88 |

Saya pikir restic akan mendapatkan secara besar-besaran dengan kompresi opsional dalam bentuk apa pun karena mengurangi hampir semuanya.

Tidak setiap file akan memiliki rasio kompresi yang menarik. Mengompresi file video mungkin tidak berguna, tetapi mengompresi dump SQL tentu saja tidak berguna. Itu sebabnya sistem file seperti Btrfs pertama-tama mencoba mengompresi 128KB pertama dari sebuah file dan jika ada rasio kompresi yang signifikan maka akan mengompres seluruh file. Ini jelas tidak sempurna tetapi cepat dan akan berfungsi untuk sebagian besar kasus penggunaan jika diputuskan untuk mengompresi file satu per satu.

Bagi mereka yang menentang penyediaan kompresi sebagai opsi, kasus penggunaan saya adalah bahwa saya mencadangkan campuran sebagian besar jenis file yang dapat dikompresi yang tidak dapat saya kendalikan kontennya dan tidak masuk akal untuk mengharapkan saya harus mengompres data pada beberapa mesin (yang memakan lebih banyak ruang disk lokal dalam hal mengompresi ke arsip baru atau membuat file tidak dapat digunakan oleh aplikasi terkait jika dikompresi di tempat) sebelum melakukan operasi pencadangan.

Saya lebih suka dapat menggunakan restic sebagai alat cadangan DR saya, tetapi saat ini saya menggunakan borg (persyaratan ram yang lambat, besar, dll) karena kompresi yang dihasilkan + dedupe yang dicapainya menghemat banyak gigabyte transfer jaringan per operasi pencadangan dan dengan mudah lebih dari satu terabyte ruang penyimpanan (yang saya bayar per bulan) di cloud di seluruh set cadangan saya. Saya akan dapat menyimpan cadangan lebih lama atau mengurangi biaya penyimpanan saya jika kompresi yang didukung restic.

Halo @joerg , terima kasih telah membagikan tes Anda.
Sudahkah Anda mencoba mencadangkan dengan restic output dari tugas kompresi Tar?
Saya ingin tahu tentang membandingkan "Restic S3 Remote Compress" dan "Tar" + "Restic S3 Remote Upstream".
Selain itu, apa yang Anda katakan tampaknya tidak sepenuhnya benar:

Saya pikir restic akan meningkat secara besar-besaran dengan kompresi opsional dalam bentuk apa pun karena mengurangi hampir semuanya

Melihat hasil pengujian, tampaknya waktu CPU yang dibutuhkan oleh restic 2x lebih lama untuk backup lokal dan 6x lebih lama untuk restore. Tidak terlalu bagus dibandingkan dengan Tar.

tar bukan algoritma kompresi. tentu saja cepat.
EDIT: oh dan btw. jika Anda tar direktori, itu tidak akan menggunakan banyak utas per file dan itu juga tidak akan berfungsi dengan dua file atau lebih sekaligus, melainkan akan memindai direktori dan menambahkan file dan kemudian pergi ke yang berikutnya. cukup lambat. tetapi masalahnya adalah file arsip yang tidak dirancang untuk ditambahkan dengan banyak utas.

Melihat hasil pengujian, tampaknya waktu CPU yang digunakan oleh restic 2x lebih lambat di backup lokal dan 6x lebih lambat di restore. Tidak terlalu bagus dibandingkan dengan Tar.

Saya tidak sepenuhnya yakin dengan maksud Anda di sini. restic lebih lambat dari Tar, tentu saja, tetapi restic dengan kompresi selalu lebih cepat daripada restic tanpa, jadi restic jelas akan menguntungkan.

Tar adalah perbandingan yang berguna dari "kasus terbaik pada perangkat keras ini", tetapi kurang di sebagian besar fitur restic lainnya (snapshot dan deduplikasi data muncul dalam pikiran). Menambahkan kompresi tampaknya hanya meningkatkan waktu pencadangan, waktu pemulihan, dan biaya penyimpanan, semua hal yang penting untuk produk pencadangan.

@joerg Bisakah teman Anda membuka Permintaan Tarik dan membuat tambalan mereka untuk restic dengan kompresi tersedia untuk umum? Algoritma kompresi mana yang mereka gunakan?

@joerg @thedaveCA
Saya minta maaf, saya salah memahami maksud pernyataan @joerg . Jelas istirahat dengan kompresi lebih baik daripada istirahat tanpa kompresi. Sekarang pertanyaan saya adalah: Tar + restic lebih baik atau tidak dibandingkan dengan restic dengan kompresi?

Harap diingat bahwa kami tidak menggunakan arsip tar kosong, tetapi arsip tar gzip dengan implementasi zip paralel khusus, jika tidak, pengarsipan terabyte data akan memakan waktu berhari-hari, bukan "hanya" jam yang diperlukan sekarang: https://Gist.github. com/joerg/b88bf1de0ce824894ffc38f597cfef5f#tarpigz
@shibumi Saya memberi tahu mereka tentang masalah ini dan posting saya jadi sekarang terserah mereka jika dan sejauh mana mereka ingin terlibat dalam hal ini. Secara pribadi, saya berharap mereka akan membuka permintaan tarik itu. . .

Kompresi tidak cocok untuk enkripsi. Ini memungkinkan penyerang untuk menebak apakah repositori terenkripsi berisi file tertentu sebagai bagian (potongan) dari file kompres ke ukuran yang sama independen dari kunci enkripsi yang digunakan. Ini adalah kerentanan protokol enkripsi yang

Mari kita tidak membuat masalah yang diketahui di mana tidak ada, ya?

(Saya pikir masalah ini sudah disebutkan, dan mungkin tidak sekali pun. Masih masalah ini terbuka, di mana saya merasa hanya karena alasan ini itu harus ditutup sekali dan untuk semua.)

Mengapa Anda mengirim spam ke masalah ini? :( Telah dibahas berkali-kali sehingga hampir keluar dari topik. Anda tidak akan DIPAKSA untuk mengaktifkan kompresi!!

Selain itu, saya pikir ide serangan Anda mengharuskan penyerang untuk dapat mengontrol data yang akan dikompresi dan dienkripsi (meskipun saya tidak yakin!). https://en.m.wikipedia.org/wiki/CRIME

Tetapi bagaimanapun juga, bahkan jika itu adalah masalah keamanan, seseorang mungkin ingin menggunakan kompresi hanya untuk penyimpanan yang berada di bawah kendalinya sendiri untuk menghemat ruang penyimpanan.

Bahkan memiliki fitur opsional yang melemahkan enkripsi mengundang rasa aman yang salah. Restic mengklaim sebagai program cadangan _secure_. Menambahkan kompresi opsional akan membatalkan janji ini karena Anda kadang-kadang tidak aman, hanya penuh waktu, sepanjang waktu. Dan akan ada laporan CVE, pasti. Siapa yang ingin perangkat lunak mereka "populer" seperti ini?

Tapi saya pikir menambahkan kompresi dengan cara yang tidak akan pernah digunakan dengan enkripsi adalah pilihan yang layak.

FWIW pada tahun 2017 saya membuat demo di mana saya menghapus enkripsi dari Restic, dan menunjukkan bahwa kompresi bisa sangat efektif . Seratus kali efektif. Kompresi IIRC dapat ditambahkan sebagai semacam pembungkus seperti enkripsi, tetapi saya belum melihat kode untuk waktu yang lama sehingga hal-hal mungkin lebih sulit akhir-akhir ini, atau lebih mudah.

sebenarnya KEJAHATAN perlu mengetahui panjang ciphertext, yang pada dasarnya tidak mungkin dalam keadaan istirahat.
juga tidak ada program cadangan "aman". jika file cadangan dapat diakses oleh pihak ketiga selalu ada kemungkinan seseorang dapat merusak atau lebih buruk lagi, baca datanya.
jadi mengatakan kompresi membuatnya lebih buruk, itu bodoh.

sebenarnya KEJAHATAN perlu mengetahui panjang ciphertext

KEJAHATAN membutuhkan tetapi Anda tidak. Bayangkan Anda seorang jurnalis investigasi yang diberi satu set file rahasia oleh sumber Anda. Anda mencadangkannya dengan enkripsi dan tidak ada yang akan tahu bahwa Anda memiliki file-file ini.

Sekarang bayangkan Anda tidak cukup pintar untuk mengaktifkan kompresi, dan sekarang semua orang, yang kebetulan juga memiliki file-file ini, hanya dilihat dari ukuran bongkahan terkompresi-kemudian-dienkripsi, akan tahu bahwa Anda memiliki file-file rahasia di arsip ini tanpa bahkan perlu mengetahui kunci enkripsi. Ini sangat jauh dari kata aman. Orang bisa masuk penjara karena "fitur" ini, disiksa, atau lebih buruk lagi.

tidak ada program cadangan "aman"

Ini kemudian membutuhkan pembaruan.

Perhatikan juga aman secara default.

toko restic hanya mengemas bongkahan, jadi ukuran bongkahan tidak terlihat jelas
seseorang tidak memiliki kunci.

Pada Jumat, 09 Agustus 2019 pukul 02:09:23 -0700, Alexey Kopytko menulis:

Kompresi tidak cocok untuk enkripsi. Ini memungkinkan penyerang untuk menebak apakah repositori terenkripsi berisi file tertentu sebagai bagian (potongan) dari file kompres ke ukuran yang sama independen dari kunci enkripsi yang digunakan. Ini adalah kerentanan protokol enkripsi yang

Mari kita tidak membuat masalah yang diketahui di mana tidak ada, ya?

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/restic/restic/issues/21#issuecomment -519844526

--
(Escriu-me xifrat si saps PGP / Tulis ciphered jika Anda tahu PGP)
Kunci PGP 7CBD1DA5 - https://emailselfdefense.fsf.org/

Bagi yang ingin tahu lebih banyak tentang masalah keamanan ini, ada makalah bagus yang menjelaskannya http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf
Dalam pemahaman saya mungkin ada cacat jika file tersebut dipotong dan kemudian dikompresi dan dienkripsi. Tetapi jika file dikompresi sebelum dipotong, itu adalah file biner seperti yang lain dan serangan plaintext itu menjadi tidak berguna.

Tetapi jika file dikompresi sebelum dipotong, itu adalah file biner seperti yang lain dan serangan plaintext itu menjadi tidak berguna.

Itu betul. Tapi itu tidak akan membantu dengan deduplikasi yang efisien jika saya mengerti dengan benar karena algoritma kompresi dapat menggunakan kosakata yang berbeda untuk setiap versi file yang menghasilkan hasil biner yang sangat berbeda. Yang jelas tidak akan terduplikasi. Jika tidak, masuk akal untuk mengompres potongan yang dihasilkan.

toko restic hanya mengemas potongan, jadi ukuran potongan tidak jelas bagi seseorang yang tidak memiliki kunci

Itu melegakan.

Maksud saya tetap: bahwa ada banyak cara seseorang dapat menambahkan kelemahan tersembunyi ke dalam sebuah program ketika mengimplementasikan kompresi bersama dengan enkripsi, jadi sebaiknya tidak menambahkannya sama sekali. Bahkan enkripsi _experts_ memutuskan tentang TLS memilih untuk menghapus kompresi. Kira mereka memiliki alasan yang sama.

Omong-omong.:

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

...
juga KEJAHATAN hanya berfungsi jika Anda memiliki beberapa versi berbeda dari file terenkripsi.
yaitu beberapa proses pencadangan (ke repositori yang berbeda, tempat penyerang memperoleh semuanya)
dan itu juga hanya berfungsi dengan sejumlah kecil data.

KEJAHATAN membutuhkan tetapi Anda tidak. Bayangkan Anda seorang jurnalis investigasi yang diberi satu set file rahasia oleh sumber Anda. Anda mencadangkannya dengan enkripsi dan tidak ada yang akan tahu bahwa Anda memiliki file-file ini.

Sekarang bayangkan Anda tidak cukup pintar untuk mengaktifkan kompresi, dan sekarang semua orang, yang kebetulan juga memiliki file-file ini, hanya dilihat dari ukuran bongkahan terkompresi-kemudian-dienkripsi, akan tahu bahwa Anda memiliki file-file rahasia di arsip ini tanpa bahkan perlu mengetahui kunci enkripsi. Ini sangat jauh dari kata aman. Orang bisa masuk penjara karena "fitur" ini, disiksa, atau lebih buruk lagi.

itu omong kosong. karena hanya bekerja dengan ukuran sampel yang kecil. itu juga masih bisa masuk penjara tanpa kompresi. terutama di beberapa titik waktu, ketika penyerang mendapatkan file cadangan Anda, dia mungkin dapat memaksanya di masa depan.
mungkin ada masalah keamanan lain yang muncul di masa depan, dll...
diskusi hanya berubah menjadi ketakutan yang tidak berarti.

@sanmai , saya tidak mendapatkan contoh ini dengan

Bayangkan Anda seorang jurnalis investigasi ... Sekarang bayangkan Anda tidak cukup pintar untuk mengaktifkan kompresi, dan sekarang semua orang, yang kebetulan juga memiliki file-file ini, hanya dilihat dari ukuran potongan terkompresi-kemudian-dienkripsi, akan tahu bahwa Anda memiliki file rahasia di arsip ini bahkan tanpa perlu mengetahui kunci enkripsi.

Apa yang dimaksud? Bahwa seseorang dapat menebak bahwa snapshot terenkripsi memiliki file-file ini hanya dengan melihat ukurannya? Ini mengasumsikan bahwa file dikompresi sendiri, atau bersama-sama dengan file lain yang dikenal. Tapi kemudian tebakan yang sama dapat dilakukan dengan shapshot yang tidak terenkripsi.

Sebenarnya, bagaimana dengan gzip file sebelum mencadangkan? Apakah ini juga membuka kerentanan keamanan?

Saya pikir contoh ini tidak masuk akal: jika Anda mengklaim bahwa Anda dapat menentukan apakah snapshot berisi versi terkompresi dari beberapa file (sewenang-wenang) yang Anda ketahui, Anda juga dapat menentukan apakah itu berisi file-file yang tidak terkompresi.

Saya tidak percaya kompresi dapat membuat enkripsi secara signifikan kurang aman.

Sebagian besar serangan saluran samping kompresi melibatkan beberapa faktor:
1) Penyerang dapat mengontrol input
2) Penyerang dapat mengamati ukuran output
3) Perubahan kecil pada data input menghasilkan perubahan terukur pada ukuran output
4) Penyerang dapat mengubah input dan mencoba lagi ratusan ribu kali

Tidak seperti sistem berbasis web, di sebagian besar melibatkan cadangan restic, (1) dan (2) jarang akan terus pada waktu yang sama. Selanjutnya, untuk kompresi berbasis blok (3) tidak benar-benar dijamin, dan untuk sebagian besar rezim pencadangan (4) tentu saja tidak berlaku. Karena frekuensi pencadangan biasanya sekali sehari atau lebih, dibutuhkan ribuan tahun untuk dapat memanipulasi data dan memantau ukuran keluaran terkompresi untuk melihat perbedaan yang signifikan, dan dengan asumsi bahwa tidak ada data lain yang berubah, yang dalam banyak kasus itu akan menjadi.

Jika Anda membuat cadangan di mana ukuran output terlihat, Anda mungkin ingin mempertimbangkan untuk menonaktifkan kompresi. Jika tidak, benar-benar tidak ada serangan praktis terhadapnya dan itu tidak akan membuatnya kurang aman untuk mengaktifkannya.

restic sudah melakukan de-duplikasi yang memaparkannya pada serangan teoretis yang sama dengan saluran samping kompresi, dan tidak ada yang mengeluh tentang ini sepengetahuan saya.

Faktanya adalah, ada ratusan atau ribuan pengguna yang akan mendapat manfaat dari fitur kompresi tanpa kekurangan apa pun. Bisakah kami menyerahkan masalah 5 tahun ini kepada pengembang yang sedang mengerjakannya?

jujur ​​.... Saya lebih suka konsep restic ... tapi saya membuat tes di usecase saya (banyak file CSV dan dump SQL) dan harus beralih ke borg.

Saya menguji dengan empat generasi cadangan inkremental dan file saya mendapatkan kompresi 7:1 dan bersama-sama dengan deduplikasi saya mencapai > 20:1. Saya tidak dapat mengabaikannya karena saya telah mengatakan bahwa saya membayar penyimpanan cadangan online saya per GB.

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

Apa yang dimaksud? Bahwa seseorang dapat _menebak_ bahwa snapshot terenkripsi memiliki file-file ini hanya dengan melihat ukurannya? Ini mengasumsikan bahwa file dikompresi sendiri, atau bersama-sama dengan file lain yang dikenal. Tapi kemudian tebakan yang sama dapat dilakukan dengan shapshot yang tidak terenkripsi.

Tepat. Iris file teks biasa menjadi potongan yang sama, kompres kemudian, lalu enkripsi. Iris lagi, kompres dan enkripsi. Karena ukuran file terenkripsi tidak berubah dari segi AES, Anda akan melihat bahwa dalam kedua kasus Anda memiliki rentang ukuran yang cocok satu sama lain seperti sidik jari. Mereka (dan maksud saya terutama administrasi rezim yang menindas seperti Iran atau Rusia) dapat membuat asumsi yang masuk akal bahwa file-file ini ada di sini, yang oleh karena itu memberikan alasan, katakanlah, untuk terus menyiksa tersangka. Saya tidak mengerti mengapa Anda begitu tersinggung dengan ide-ide ini, bukankah itu mudah dimengerti? Ini bukan KEJAHATAN semata, kan?

Tetapi seperti yang disebutkan sebelumnya oleh @viric , secara teknis Restic tidak terpengaruh oleh kerentanan ini karena ukuran potongan tidak terlihat tanpa kunci enkripsi. Namun jika kompresi ditambahkan di beberapa titik, Restic mungkin masih tidak terpengaruh sekarang, tetapi mungkin akan terpengaruh nanti.

Apakah menambahkan kompresi mengekspos Restic ke kerentanan tambahan, mengingat ia sudah melakukan deduplikasi?

Jika kekhawatiran Anda adalah penyerang menebak ukuran blok terkompresi untuk menyimpulkan ukuran yang tidak terkompresi, oke, tetapi apakah kompresi memperburuk ini? Bukankah penyerang memiliki informasi dasar yang sama?

Jika penyerang dapat melihat ukuran yang tidak dikompresi DAN dikompresi dari setiap file, maka identifikasi mungkin menjadi lebih realistis, tetapi ini tidak mungkin dilakukan dalam keadaan diam.

Pada akhirnya de-duplikasi sudah memaparkan Anda pada setiap serangan teoretis yang dapat saya lihat berdampak pada kompresi, ditambah tentu saja kompresi dapat dinonaktifkan untuk mempertahankan keadaan saat ini jika ini lebih sesuai dengan situasi Anda.

Saya benar-benar tidak mengerti mengapa Anda membahas tentang masalah keamanan hipotetis tentang menebak keberadaan file dengan melihat ukuran potongan terenkripsi..,,

Kalian menggunakan ZIP atau GZ? Maka Anda harus baik-baik saja.

Anda berpikir bahwa otoritas iran dapat menebak konten saya berdasarkan ukuran? Maka jangan gunakan kompresi (!). Itu tidak berarti bahwa kompresi tidak boleh tersedia.

Saya pikir kami telah membahas semua sudut yang relevan untuk menambahkan kompresi ke restic, terima kasih banyak atas semua masukan Anda.

Saya pikir kita harus menambahkan kompresi dan mengaktifkannya secara default, tetapi mengizinkan pengguna untuk menonaktifkan kompresi. Harap bersabar sampai saya punya lebih banyak waktu untuk mengerjakannya.

Bagi saya diskusi ini terasa tidak terkendali, jadi saya mengunci masalah ini untuk saat ini. Jika Anda ingin melanjutkan diskusi ini, silakan menuju ke forum . Terima kasih!