Saya tidak yakin tentang memindahkan header ke depan. Saya tahu ini saat ini tidak diterapkan, tetapi untuk repositori lokal, memiliki header di bagian akhir berarti kita dapat menyimpan salinan file.

Poin yang menarik, terima kasih. Saya belum yakin bagaimana menilai mana yang lebih baik. Untuk backend jarak jauh, kami juga dapat (setelah beberapa perubahan pada antarmuka backend) hanya meneruskan io.Reader dan kemudian mungkin stdlib dapat menggunakan sendfile untuk mengalirkan file langsung dari disk. hm.

Sekedar FYI Saya bertanya-tanya mengapa Anda tidak menggunakan GCM, jadi saya menjalankan benchmark. AES-CTR + Poly1305 cukup cepat jika CPU tidak memiliki AES-NI (50% lebih cepat dari GCM bawaan Go). Dengan AES-NI, kode perakitan Go yang dioptimalkan untuk GCM mungkin tidak ada duanya.

Intel Xeon E312xx

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

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

Intel Pentium G630 (tanpa AES-NI)

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

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

Ini bukan milik masalah ini, tetapi saya akan tetap menjawab:

Saya pikir pada saat saya memulai restic, Go tidak memiliki versi GCM yang dioptimalkan. Selain itu, saya tidak nyaman menggunakan GCM karena saya tidak memahaminya, sedangkan kertas Poly1305 jauh lebih mudah dibaca dan dipahami.

Saya pikir benchmark Anda memproses gumpalan data yang jauh lebih kecil, mungkin akan semakin dekat ketika gumpalan lebih besar.

Saya melihat. Ya, GCM yang dioptimalkan cukup baru, saya pikir Cloudflare menyumbangkannya untuk Go 1.5.

Mengenai ukuran blok, benchmark restic menggunakan 8 MiB sedangkan bodohgcm menggunakan 4kiB . Saya mencoba lagi dengan ukuran blok 8 MiB untuk bodohgcm tetapi hasilnya hampir identik.

Jadi jangan buang waktu untuk ini, saya pikir CTR+Poly1305 cukup cepat.

Apakah penting untuk memiliki ukuran yang tidak terkompresi dalam file indeks atau footer paket? Saya pikir tidak apa-apa untuk mengetahuinya hanya di dalam gumpalan, kemudian, lebih sedikit perubahan yang diperlukan dalam keadaan istirahat. Apakah ini memungkinkan fitur baru untuk dikenal di tempat tambahan ini?

Menurut pendapat saya, format repositori 2 == byte pertama dari data gumpalan menunjukkan format kompresi, itu saja yang diperlukan. Mungkin salah satu dari 255 format yang mungkin adalah {64-bit uncompressed length}{compressed data}.

Saya pikir koreksi kesalahan adalah ide bagus untuk cadangan. Tapi saya pikir itu adalah tanggung jawab sistem file. Apakah Anda juga ingin mengimplementasikan RAID di dalam restic?

Apakah penting untuk memiliki ukuran yang tidak terkompresi dalam file indeks atau footer paket?

Ya: Header paket menjelaskan apa yang ada di dalam paket dan ini memberi tahu proses ekstraksi apa yang diharapkan (dalam hal algoritma kompresi, ukuran yang tidak dikompresi, dan kemudian juga atribut lain seperti kunci yang digunakan untuk enkripsi). Kebutuhan yang sama direpresentasikan dalam indeks, yang telah diperkenalkan sehingga restic tidak perlu mencari setiap gumpalan di header paket. Jadi informasi yang sama perlu hadir di sana.

Menurut pendapat saya, format repositori 2 == byte pertama dari data gumpalan menunjukkan format kompresi, itu saja yang diperlukan. Mungkin salah satu dari 255 format yang mungkin adalah {64-bit uncompressed length}{compressed data}.

Saya tidak suka ide ini, itu membuat format file lebih rumit: Kami akan memiliki informasi kontrol di dua tempat berbeda: di awal gumpalan dan di header. Header justru lokasi yang berisi informasi kontrol.

Saya pikir koreksi kesalahan adalah ide bagus untuk cadangan. Tapi saya pikir itu adalah tanggung jawab sistem file.

Pada prinsipnya saya setuju, tetapi sistem file adalah hal yang sangat rumit, dan propagasi kesalahan (misalnya kesalahan baca/tulis media) seringkali kurang optimal. Untuk data cadangan yang sangat berkurang (dalam hal redundansi, misalnya deduplikasi) saya masih berpikir itu ide yang baik untuk menambahkan (atau menawarkan untuk menambahkan) lapisan lain dari koreksi kesalahan.

Untuk kode Reed-Solomon, ada implementasi Go murni di https://github.com/klauspost/reedsolomon dengan beberapa data kinerja.

Menurut https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank_html/ ZFEC harus lebih cepat. Implementasi ada di https://gitlab.com/zfec/go-zfec yang tampaknya didasarkan pada https://pypi.python.org/pypi/zfec.

ECC diterapkan setelah kompresi dan biasanya disisipkan dalam file data, karena mendistribusikannya membuatnya lebih kuat jika data ditransfer melalui saluran komunikasi yang tidak dapat diandalkan atau berisik.

Dalam grup biner Usenet mereka menggunakan file terpisah (lihat https://en.wikipedia.org/wiki/Parchive) yang berisi informasi ECC. Itu hanya akan menambahkan subdirektori lain ke tata letak repositori dan menerapkan ECC ke informasi manajemen repo (config, indeks, ...) juga akan mudah. Tapi saya tidak yakin apakah melakukannya dengan cara itu akan melemahkan skema ECC (mungkin ketahanan terhadap kesalahan cluster dalam informasi ECC berkurang).

Terima kasih atas petunjuknya. Saya telah menemukan makalah versi PDF di sini: https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank.pdf

Implementasi ZFEC Go hanyalah pembungkus di sekitar pustaka C.

Untuk ZFEC ada port Go dengan tambahan (penggunaan goroutine) bernama jfec di [https://github.com/korvus81/jfec].

Saya telah menambahkan "proyek" (tambahan terbaru ke GitHub) untuk melacak penerapan format repositori baru: https://github.com/restic/restic/projects/3

Beberapa ide yang dapat dilihat ketika melanggar kompatibilitas mundur:

• Ubah dari sha256 ke sha512

Akankah menggunakan sha512 (atau sha512/256) alih-alih sha256 menghasilkan peningkatan kecepatan pencadangan? Sejauh yang saya bisa lihat ini berlaku untuk sebagian besar platform kecuali ARM.

Diskusi sinkronisasi (https://github.com/syncthing/syncthing/issues/582)

Diskusi Borg (https://github.com/jborg/attic/issues/209)

Makalah di sha512/256 (https://eprint.iacr.org/2010/548.pdf)

• Menggunakan enkripsi kunci publik alih-alih kata sandi sederhana

Saat ini setiap orang yang memiliki akses untuk menulis ke repositori memiliki akses untuk membaca darinya. Enkripsi kunci publik akan menghilangkan ini dan masih memungkinkan deduplikasi berdasarkan hash.

Menerapkan enkripsi kunci publik ke gumpalan data akan berhasil, tetapi saya tidak cukup akrab dengan bagaimana restic memproses struktur pohon untuk mengetahui apakah itu dapat diimplementasikan dengan sukses untuk itu juga. Itu mungkin bisa memperkenalkan banyak kerumitan. Jika hanya gumpalan data yang disembunyikan, masih ada banyak informasi di pohon.

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

• Identifikasi repositori

Saat ini tidak ada cara untuk mengetahui bahwa Anda sedang melihat repositori restic ketika Anda menemukan repositori tersebut. Kami saat ini membocorkan "created":"TIMESTAMP","username":"XXXXX","hostname":"XXXXX" di file kunci. Saya akan menyarankan untuk menyembunyikan informasi ini, dan sebagai gantinya menyertakan beberapa informasi tentang restic, seperti restic repository version X . Mungkin sesederhana README.

Mengenai diskusi sebelumnya; Saya sangat mendukung penerapan beberapa bentuk koreksi kesalahan.

@oysols Terima kasih telah menambahkan ide Anda!

Saya akan menambahkan pemikiran saya di bawah ini:

Ubah dari sha256 ke sha512 (untuk kecepatan)

Saat ini, saya tidak peduli dengan kecepatan (restic sudah sangat cepat), jadi setidaknya bagi saya item ini adalah prioritas rendah. Bahkan ada versi SHA256 yang dioptimalkan untuk prosesor berkemampuan SIMD yang dapat dengan mudah kita alihkan. Di sisi lain, ketika kami memutuskan untuk mempercepat restic dan hash akan dibahas, saya mungkin lebih suka Keccak (SHA3) atau Blake2, yaitu (sejauh yang saya tahu, saya belum melakukan benchmark apa pun) lebih cepat.

Jadi, dari sudut pandang saya, item ini ditunda untuk saat ini.

Menggunakan enkripsi kunci publik alih-alih kata sandi sederhana

Fitur ini direncanakan (lihat #187), tetapi rumit dan membutuhkan banyak pemikiran dan beberapa perubahan infrastruktur besar. Saya juga ingin menunda ini dan lebih suka melakukan pembaruan tambahan yang lebih kecil daripada pembaruan di mana kami mengubah segalanya -> ditunda.

Identifikasi repositori (tambahkan file README ke dalam repositori)

Poin yang sangat bagus, kita bahkan dapat menambahkannya sekarang tanpa merusak apa pun.

Repositori "kebocoran informasi" (menghapus nama pengguna, nama host, dan stempel waktu yang dibuat dari file kunci)

Itu juga poin yang bagus. Saat ini kami hanya menggunakan informasi ini untuk menampilkannya di samping ID kunci dalam perintah key list . Kita dapat dengan mudah menjatuhkan username dan host , stempel waktu tidak memberikan banyak informasi, dalam banyak kasus akan sama dengan tanggal pembuatan file.

Saya ingin memasukkan username dan host dan membiarkan stempel waktu yang dibuat tetap masuk.

Saya telah bermain-main dengan https://github.com/klauspost/reedsolomon hari ini dan saya pikir kita dapat menambahkan kode koreksi kesalahan dengan lebih mudah ke akhir file paket (setelah kita memindahkan header paket ke awal file ). Ada dua kelemahan, meskipun:

• Ukuran file akan meningkat ~14-30%, tergantung pada parameter yang kita pilih untuk reed-solomon
• Kita perlu menyimpan checksum (tidak harus hash kriptografis) dari bagian file paket dalam file paket itu sendiri, ini diperlukan untuk rekonstruksi karena algoritme untuk rekonstruksi perlu mengetahui bagian file mana yang telah rusak. Jadi itu membutuhkan waktu sedikit lebih lama untuk menghitung, meskipun kita dapat memilih untuk menggunakan checksum cepat (seperti CRC atau lebih).

Pikiran?

Bisakah perlindungan batang data menjadi opsional? Saya menganggap ukurannya meningkat lebih dari marginal (ini adalah fitur hebat untuk orang lain meskipun saya percaya!)

Biarkan saya bermain dengan ini sedikit, jadi saya bisa merasakan seberapa besar (atau lebih kecil?) repo ketika ECC digabungkan dengan kompresi. Mungkin kita menambahkan dua jenis kode: Satu untuk header paket, dan satu (mungkin opsional) untuk data.

jatuhkan nama pengguna dan host

Kedengarannya seperti ide yang bagus. Jika kita ingin menyimpan informasi, itu dapat ditambahkan ke bidang terenkripsi yang terpisah, dengan cara yang sama seperti kunci utama.

ECC: Ukuran file akan meningkat ~14-30%,

Saya tidak berpikir itu adalah ide yang baik untuk memasukkan ECC ke dalam file paket itu sendiri. Mereka tidak berguna dalam skenario pemulihan biasa, dan hanya digunakan jika file paket rusak.

Saya menyarankan agar data paritas ditempatkan di direktori terpisah:

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

• Paritas akan sepenuhnya opsional, dan dapat dibuat setelah cadangan.
• Tidak ada perlambatan operasi pemulihan. Tidak diperlukan bandwidth tambahan untuk pemulihan.
• Nama file yang identik memudahkan untuk mengidentifikasi data paritas yang benar. Ini berarti bahwa data paritas tidak dinamai menurut hash sha256-nya sendiri, tetapi tidak diperlukan indeks tambahan. (Verifikasi data paritas harus dilakukan dengan memverifikasi file paket.)
• Pengguna mendapat gambaran tentang jumlah data paritas.

Tidak peduli bagaimana penerapannya; Dengan banyak lapisan kompresi dan enkripsi saya pikir beberapa jenis ECC diperlukan. Satu bit yang salah dapat menyebabkan banyak masalah.

Terima kasih atas komentar Anda, mari pindahkan diskusi ke masalah terpisah yang baru saja saya buat: #804.

Mau tak mau saya mendapat kesan bahwa ada dua kelompok yang saling berbicara tentang kode koreksi kesalahan penerusan dalam restic. Satu grup ingin (hanya) melindungi repo dari bitrot, karena bahkan satu bitflip dapat membuat masalah besar dalam repo yang dideduplikasi. Grup lain ingin menggunakan kode penghapusan untuk menyebarkan repo ke beberapa domain kegagalan (mis. disk non-RAID). Kedua tujuan dapat dilayani oleh kode Reed-Solomon, tetapi mereka memerlukan parameter yang berbeda dan tata letak penyimpanan yang berbeda.

Saya menjalankan pemeriksaan cepat pada repo saya dengan skrip python saya (https://github.com/oysols/restic-python).

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

Dari cadangan 146 GB, gumpalan pohon hanya berukuran 54 MB dan akan terkompresi dengan baik hingga sekitar sepertiga dari ruang aslinya, saat kami menerapkan kompresi.

Apakah akan ada peningkatan kinerja dengan memisahkan gumpalan pohon dari gumpalan data?

Tampaknya sebagian besar operasi yang dilakukan selama pemulihan dilakukan berdasarkan gumpalan pohon, sebelum benar-benar memulihkan data. Memisahkan mereka untuk memisahkan file paket akan meminimalkan jumlah data yang perlu diunduh untuk mengurai pohon cadangan. Mengingat ukuran gumpalan pohon yang kecil, mungkin lebih cepat untuk mengunduh semua gumpalan pohon sebelum memulai proses pemulihan.

Tentu saja; Distribusi ini mungkin tidak sama untuk semua repo.

Apakah menurut Anda ini layak untuk diteliti lebih lanjut?

Apakah akan ada peningkatan kinerja dengan memisahkan gumpalan pohon dari gumpalan data?

Mungkin, ini adalah salah satu optimasi yang saya pikirkan untuk masa depan.

Terlepas dari ini, saya juga ingin menambahkan cache lokal untuk metadata, sehingga tidak perlu diambil dari repo sama sekali. Ini akan sangat meningkatkan kecepatan banyak operasi.

Apakah akan ada peningkatan kinerja dengan memisahkan gumpalan pohon dari gumpalan data?

Ini secara teoritis dapat meningkatkan operasi prune , karena lebih sedikit pengemasan ulang akan diperlukan jika gumpalan pohon dan gumpalan data berada dalam file paket yang terpisah (mungkin menjadi mungkin untuk menghapus file paket lama daripada mengemasnya kembali).

Saya sudah melihatnya selama #842

gcm vs ctr: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html

sym vs asym: idenya adalah untuk mengenkripsi kunci "sesi", bukan?

Mari kita tidak membahas crypto dalam masalah ini, karena ditunda untuk saat ini. Masalah yang relevan untuk diskusi kripto asimetris adalah #187. Selain itu, saya ingin menjaga diskusi tetap pada tingkat tinggi sampai kita menyelesaikan kasus penggunaan. Kemudian kita dapat berbicara tentang crypto tingkat rendah.

Hapus nama pengguna dan nama host dari file kunci.

Kebocoran metadata besar!
Misalnya, "username":"WorldBank\\JimYongKim" dengan jelas menunjukkan pemilik berpangkat tinggi .

Menunggu ini menjadi _removed_ (atau _encrypted_) sejak biner Windows pertama dikompilasi pada Januari 2017.
Untungnya, saya memeriksa cadangan sebelum mengunggah atau merekomendasikan Restic kepada rekan-rekan yang sadar privasi.

Sunting: Zona waktu pengguna juga disebutkan dalam teks biasa, yang juga bertentangan dengan prinsip kerahasiaan .

Re: SHA3 -- inilah satu pendapat tentang mengapa itu tidak layak untuk diadopsi (belum?): https://www.imperialviolet.org/2017/05/31/skipsha3.html

Jadi saya percaya bahwa SHA-3 mungkin tidak boleh digunakan. Ini tidak menawarkan keuntungan yang menarik dibandingkan SHA-2 dan membawa banyak biaya. Satu-satunya argumen yang dapat saya hargai adalah bagusnya memiliki fungsi hash cadangan, tetapi SHA-256 dan SHA-512 umumnya didukung dan memiliki inti yang berbeda. Jadi kami sudah memiliki dua fungsi hash yang aman dan saya rasa kami tidak membutuhkan yang lain.

Saya sudah membaca posting dan saya mengerti argumen agl. Untuk restic, itu tidak terlalu relevan: Kami menggunakan fungsi hash untuk (secara unik) mengidentifikasi gumpalan, bukan sebagai blok penyusun protokol kriptografi. Ide saya untuk melihat fungsi hash lainnya terutama karena SHA-256 lambat untuk dihitung, terutama pada sistem kelas bawah. Fungsi hash lainnya jauh lebih cepat (misalnya blake2).

Tidak yakin apakah ini format repo: Bagaimana kalau membuat enkripsi opsional? Saya sedang memikirkan cadangan yang akan disimpan di server cadangan tepercaya yang sudah memiliki disk terenkripsi.

@mschiff Lihat #1018 untuk diskusi itu. ;)

Bagaimana membuat ukuran bagian pilihan?
Saat ini saya memiliki 4-6 MB per file. Dengan lebih sedikit file tetapi lebih besar, pencadangan jarak jauh akan jauh lebih cepat.

@fd0 menulis:

Saat ini, saya tidak peduli dengan kecepatan (restic sudah sangat cepat), jadi setidaknya bagi saya item ini adalah prioritas rendah. Bahkan ada versi SHA256 yang dioptimalkan untuk prosesor berkemampuan SIMD yang dapat dengan mudah kita alihkan. Di sisi lain, ketika kami memutuskan untuk mempercepat restic dan hash akan dibahas, saya mungkin lebih suka Keccak (SHA3) atau Blake2, yaitu (sejauh yang saya tahu, saya belum melakukan benchmark apa pun) lebih cepat.

Pertimbangan lain untuk algoritma hash yang lebih cepat dan kurang intensif CPU (seperti Blake2) akan mengurangi penggunaan baterai pada laptop saat membuat cadangan saat tidak terhubung ke sumber daya.

Menanggapi posting pertama:

Hapus nama pengguna dan nama host dari file kunci.

Apakah ini akan diganti dengan nama kunci atau deskripsi semacam itu? Saya percaya beberapa cara untuk membedakan kunci yang berbeda (tanpa memiliki akses ke kunci itu sendiri, misalnya ketika mencabut akses untuk beberapa mesin) berguna untuk membuat manajemen kunci berguna?

Satu saran baru: Bagaimana kalau menggunakan kunci yang berbeda untuk blob, tree, dan snapshot? Ini akan, AFAICS, mengaktifkan skenario di mana pelupaan dan pemangkasan terjadi di server penyimpanan cadangan, bukan di klien. Dengan memberikan akses server penyimpanan ke pohon dan objek snapshot, itu harus memiliki info yang cukup untuk menentukan objek apa yang dibutuhkan oleh snapshot apa dan objek apa yang tidak lagi digunakan. Jika server penyimpanan setiap dikompromikan, akses diperoleh ke metadata pohon, tetapi bukan konten file yang sebenarnya.

Ini dapat dibuat sedikit lebih kuat dengan hanya mengizinkan akses ke daftar id objek yang direferensikan oleh pohon, tanpa mengizinkan akses ke metadata lainnya (tetapi ini akan memerlukan struktur data tambahan untuk setiap pohon).

Jika hal di atas dimungkinkan, ini membuka jalan untuk menggunakan jenis penyimpanan hanya tulis/tambahkan saja (di mana klien yang dicadangkan tidak dapat menghapus cadangan, lihat #784), tanpa harus mengorbankan pemangkasan otomatis, atau keamanan data.

Mengenai komentar saya sebelumnya (pemangkasan tanpa memerlukan akses penuh ke data): Ini juga berlaku (bahkan mungkin lebih kuat) untuk memeriksa cadangan. Masuk akal untuk memeriksa repo di server penyimpanan untuk alasan efisiensi (AFAICS untuk memeriksa repo dari jarak jauh memerlukan transfer semua konten), atau ketika menerapkan dukungan hanya-tulis yang sebenarnya (lihat https://github.com/ncw/rclone/issues /2499).

Juga, untuk pendekatan hanya tulis yang sebenarnya, perubahan diperlukan untuk membatasi file mana yang perlu dibaca (menurut https://github.com/ncw/rclone/issues/2499#issuecomment-418609301). Saya tidak yakin apakah itu juga memerlukan perubahan format repositori, jika demikian, mungkin berguna untuk memasukkan ini di sini?

Memeriksa dan memangkas repositori di server jauh akan sangat bagus. Saya sedang dalam proses menyiapkan restic untuk mencadangkan beberapa host dan ingin melakukan semua tugas pemeliharaan pada jarak jauh sehingga penyiapan klien semudah mungkin dan hanya memerlukan pencadangan untuk berjalan secara teratur.

Saya ingin membahas beberapa (mungkin opsional) tambahan pada format file snapshot:

• Tambahkan daftar file indeks yang digunakan (lihat #1988)
• Tambahkan kemungkinan untuk data yang ditentukan pengguna (seperti deskripsi tambahan, dll, tidak menemukan masalah saat ini)
• Tambahkan data statistik seperti jumlah file/gumpalan, ruang yang digunakan, dll. Ini dapat membuat tampilan statistik lebih cepat dan juga memungkinkan pemeriksaan tambahan

Tentang format file paket, saya ingin mempertanyakan mengapa tidak menghapus header sepenuhnya.
Informasi tersebut secara berlebihan disertakan dalam file indeks. Ada beberapa diskusi tentang menambahkan redundansi untuk koreksi kesalahan, tetapi IMO ini harus (dan dapat) dipisahkan dari format repo umum dan dapat ditambahkan atau tidak ditambahkan di atasnya.

Singkatnya: Jika Anda tidak membutuhkan atau menginginkan informasi tambahan untuk koreksi kesalahan, tidak perlu menduplikasi informasi di header paket dan file indeks. File indeks diperlukan untuk operasi yang berkinerja baik dan digunakan di mana saja. Header paket jarang digunakan - dan jika itu hanya untuk pemeriksaan ulang atau koreksi kesalahan.

Proposal lain: Tambahkan nama pengguna, nama host, dan konten file konfigurasi ke bagian data dari file kunci. Jadi hapus file konfigurasi sepenuhnya.

Seperti yang sudah diusulkan, nama pengguna dan host harus ada hanya dalam bentuk terenkripsi. Untuk memeriksa apakah kunci turunan KDF valid, sudah cukup untuk memeriksa MAC dari bagian data yang dienkripsi.
IMO masuk akal untuk meletakkan semua informasi yang diperlukan untuk mengidentifikasi kunci di sana. Menambahkan informasi yang disimpan di ATM file config hanya menghapus file tambahan dari repo dan membuat inisialisasi repo menjadi lebih mudah.

Maaf untuk pertanyaan "bodoh", tetapi apakah ada upaya serius yang dilakukan untuk memperkenalkan format yang ditingkatkan dalam waktu dekat? Saya telah mengikuti masalah ini selama bertahun-tahun. restic saat ini tidak berfungsi dengan baik untuk kumpulan data besar, atau ketika ada banyak snapshot, dan membutuhkan banyak memori. Sepertinya kurangnya kompresi dan overhead yang besar dari metadata yang disandikan JSON adalah masalah besar restic. Mungkinkah usaha itu terhenti karena ada kebutuhan yang dirasakan untuk mencapai "kesempurnaan"?

Saya juga tertarik dengan apa yang akan terjadi di masa depan. Terutama dalam kripto dan kompresi asimetris.
Omong-omong, untuk fungsi hash baru, ada juga blake3 yang sangat baru dan juga sangat cepat: https://github.com/BLAKE3-team/BLAKE3
Jika belum ada keputusan yang dibuat mengenai perubahan fungsi hash, ini mungkin menarik.

Beberapa ide lagi untuk repo.v2:

• simpan pohon dan gumpalan data ke direktori yang berbeda (di pohon sebelumnya dan data dicampur, tetapi ini tidak digunakan lagi dengan pengenalan cache).
• tambahkan info 'waktu yang dibuat' ke gumpalan data.

Ini akan menyederhanakan dukungan untuk penyimpanan 'dingin' dengan unduhan yang sangat lambat atau mahal seperti amazon Glacier.

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

Saya tidak suka ide ini .. Itu membuat menebak ukuran file cadangan lebih mudah sementara saya tidak melihat manfaatnya.

* add 'created time' info to data blobs.

Saya tidak melihat ada gunanya menambahkan "waktu yang dibuat". Bisakah Anda memberikan kasus penggunaan?

Ini akan menyederhanakan dukungan untuk penyimpanan 'dingin' dengan unduhan yang sangat lambat atau mahal seperti amazon Glacier.

Saya akan mengatakan bahwa dukungan "penyimpanan dingin" sudah dapat dicapai dengan format repo saat ini dengan menambahkan beberapa kemungkinan fine-tuning ke restic dan penyimpanan ganda file yang jarang digunakan, misalnya dalam cache lokal. Lihat juga #2504

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

Saya tidak suka ide ini .. Itu membuat menebak ukuran file cadangan lebih mudah sementara saya tidak melihat manfaatnya.

Manfaatnya dijelaskan dengan baik dalam komentar sebelumnya tentang masalah ini:
https://github.com/restic/restic/issues/628#issuecomment -280436633
https://github.com/restic/restic/issues/628#issuecomment -280833405
Hasil di komentar pertama juga menunjukkan bahwa mencampurkan kedua jenis gumpalan ini tidak mengaburkan ukuran file dengan cara apa pun yang berarti.

posting forum terkait:
https://forum.restic.net/t/feature-using-an-index-for-restic-find/1773

@cfbao Komentar yang Anda maksud adalah tentang mencampur pohon dan gumpalan data dalam satu file data (paket). Memisahkan ini berguna untuk mengaktifkan penanganan cache. Ini juga sudah diubah dalam restic.

Namun, saya masih tidak melihat manfaat menyimpan pohon dan gumpalan data di direktori yang berbeda . Bisakah Anda memberikan kasus penggunaan? (IMO topik forum find tidak terkait - saya akan menjawab Anda di sana)

Memisahkan entri pohon dan gumpalan data dalam file indeks terpisah (misalnya direktori "data indeks" dan "pohon indeks") akan memungkinkan beberapa perbaikan.

Blob pohon sudah disimpan dalam file paket terpisah (ini diperkenalkan bersama dengan cache).
Hanya dengan menuliskannya ke direktori yang berbeda akan membuka cara untuk meningkatkan dukungan penyimpanan yang sangat lambat untuk diunduh (3-5 jam untuk standar Amazon Glacier). Seperti menyimpan semua metadata (indeks+snapshot+pohon di S3 biasa, dan data di Glacier).

2504 sedikit meningkatkannya, tetapi saya tidak suka ide mengandalkan 'local-cache' atau menunggu banyak untuk mengisi cache.

Saya lebih suka ide untuk memiliki beberapa proxy terbalik yang akan menyimpan tree+index+snapshots pada S3 biasa atau tempat lain, tetapi memasukkan data ke arsip yang dalam.
Bagaimanapun, pasti dimungkinkan untuk menggunakan restic sebagaimana adanya dengan beberapa batasan. Tetapi beberapa perubahan format dapat meningkatkan/menyederhanakan banyak hal.

@cfbao sejauh yang saya lihat dari kode restic find tidak akan mendapat manfaat dari ini. Itu sudah berjalan di atas snapshot. Pada dasarnya sebagian besar sama dengan restic ls <all-snapshots> | grep something .

@dionorgua
Saya suka ide menambahkan repositori arbitrer sebagai cache "tambahan" di mana semua kecuali paket data di-cache. Ini tidak memerlukan perubahan dalam tata letak repositori dan IMO jauh lebih fleksibel.
Saya sudah mengerjakan ini, lihat juga #2516, komentar terakhir.

Mungkin itu ide yang bodoh tapi bagaimana dengan format yang kompatibel dengan borg atau kopia ?

@aawsome

Komentar yang Anda maksud adalah tentang pencampuran pohon dan gumpalan data dalam satu file data (paket).

Benar. Salahku. Ya, ini satu-satunya hal yang saya pedulikan.

Ini juga sudah diubah dalam restic.

Apakah Anda tahu di PR/versi mana ini diubah? Terakhir kali saya memeriksa repo saya, saya melihat campuran data & gumpalan pohon dalam file paket yang sama. Adakah cara saya bisa (mungkin perlahan) mengubah repo saya menjadi pemisahan yang lebih baik?

Saya masih tidak melihat manfaat dari menyimpan pohon dan gumpalan data di direktori yang berbeda. Bisakah Anda memberikan kasus penggunaan?

Saya tidak punya ide. Seperti yang disebutkan sebelumnya, saya tidak terlalu peduli dengan hal ini.

@dionorgua

sejauh yang saya lihat dari kode restic find tidak akan mendapat manfaat dari ini. Itu sudah berjalan di atas snapshot. Pada dasarnya sebagian besar sama dengan restic ls| memahami sesuatu.

Tidakkah memisahkan gumpalan pohon dari gumpalan data akan mengurangi jumlah panggilan API yang diperlukan untuk menemukan? Jika terkonsentrasi, jumlah file paket yang berisi gumpalan pohon akan berkurang, dan restic dapat mengunduh lebih sedikit seluruh file daripada mengambil banyak segmen dari banyak file paket. Ini penting untuk backend yang relatif lambat dan memiliki batasan kecepatan yang lebih ketat (mis. Google Drive).

Cara apa pun yang saya bisa (mungkin perlahan) mengubah repo saya menjadi lebih baik
pemisahan?

Dengan versi restic terbaru, menjalankan 'prune' harus membangun kembali paket campuran ini..
Perhatikan bahwa implementasi sebenarnya dari 'Prune' menghasilkan banyak lalu lintas untuk repositori jarak jauh. Dengan penerapan ulang eksperimental di #2718, Anda hanya dapat mengemas ulang paket campuran sambil memiliki lalu lintas minimal.

Tidak akan memisahkan gumpalan pohon dari gumpalan data mengurangi jumlah API
panggilan yang diperlukan untuk menemukan?

Dalam versi terbaru dan dengan repo yang tidak memiliki paket campuran, semua informasi yang diperlukan di-cache secara lokal.

Ide lain untuk format repositori yang ditingkatkan:

Seperti yang telah kita lihat, sangat bermanfaat untuk memisahkan file paket berdasarkan jenis gumpalan (pohon dan gumpalan data masuk ke file paket yang berbeda). Bukankah ide yang baik untuk juga memisahkan file indeks menurut jenis gumpalan? PR indeks baru-baru ini telah menuju ke arah pemisahan entri indeks untuk pohon dan gumpalan data dalam representasi dalam memori.
Juga ada kemungkinan optimasi untuk memuat hanya sebagian dari indeks

Melakukan ini juga di repositori akan memungkinkan representasi yang lebih ringkas, misalnya

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