Restic: Pencadangan super lambat ke B2

Hei, bandwidth upstream apa yang Anda miliki? Di mana lokasi Anda (dalam hal jaringan)? B2 bukan layanan tercepat, latensi ke API (setidaknya dari Eropa) cukup tinggi.

Bagaimana tepatnya Anda menjalankan restic?

Apakah Anda memeriksa bandwidth yang digunakan dengan alat eksternal?

Throughput apa yang Anda dapatkan dengan menggunakan program lain seperti rclone ?

anekdot: Saya mencadangkan dua server yang identik, satu di New Jersey dan satu di Jerman. Yang pertama membutuhkan waktu sekitar 20 menit dan yang terakhir 90 menit mundur ke B2.

Hai,
Menambahkan umpan balik saya di sini. Server saya di Amsterdam, kecepatan unggah sekitar 100Mb/s.
Versi istirahat 0.7.3

Saya mencadangkan folder data nextcloud saya, sekitar 65-70GB dari berbagai ukuran file tidak terenkripsi
Saya buat ke repositori, satu lokal dan satu di B2. Yang lokal tampaknya memproses data pada ~5MB/dtk

restic backup -r ./resticbackup /srv/nextcloud
scanned 6320 directories, 47379 files in 0:00
[2:53] 1.12%  4.326 MiB/s  748.373 MiB / 65.470 GiB  619 / 53699 items  0 errors  ETA 4:15:47

Ketika saya menjalankan pencadangan awal yang sama ke B2, setelah ledakan singkat, kecepatannya turun dengan cepat

Saya sudah menunggu beberapa menit untuk kecepatan turun setelah ledakan dan itu duduk sekitar 1MB/s. Ini dikonfirmasi dengan menggunakan alat "nethogs" untuk memantau bandwidth berdasarkan proses, restic tampaknya berosilasi antara 500KB/s dan 2000KB/s

Saya kemudian menggunakan rclone tanpa opsi khusus untuk mengunggah struktur folder yang mirip dengan repositori cadangan dan mendapatkan kecepatan yang sama

Sebagian besar berosilasi antara 500 dan 1500 KB/s selama pengujian saya

Jadi masalahnya bukan dengan restic itu sendiri tetapi dengan B2.

Sunting:

Saya telah mencoba kembali pencadangan dengan koneksi B2 yang besar (-o b2.connections=50) dan kecepatannya meningkat secara drastis.
Saat ini saya mencadangkan hampir 10MB/s (antara 6,5MB dan 10MB per detik) sehingga batasnya tampaknya per koneksi ke API

Itu menarik, terima kasih telah melaporkan kembali!

Saya pikir saya menemukan masalah saya ketika saya mencoba ISP yang berbeda dan telah menerima hasil yang sangat berbeda. Saya bertanya-tanya, apakah ada logika dalam restic untuk mendeteksi koneksi "mati"?

B2 diketahui memiliki bandwidth terbatas per koneksi, saya juga melihat masalah yang sama dengan perangkat lunak cadangan lainnya. Solusinya adalah selalu menggunakan banyak koneksi untuk mengunggah. Saya senang saya menemukan utas ini karena saya tidak tahu tentang opsi b2.connections . Di mana semua opsi didokumentasikan?

Saya memberikan solusi kedua dengan b2.connections, dari 0,5 hingga 15 MB/s sangat melegakan :-)

Restic pasti memiliki potensi tetapi tidak yakin apakah sudah siap untuk prime time apalagi dengan Backblaze.
Ketika saya mencadangkan ke Backblaze B2 dengan duplikasi, itu sangat cepat.
--------------[ Statistik Cadangan ]--------------
Waktu Mulai 1511881648.02 (Selasa 28 Nov 10:07:28 2017)
Waktu Berakhir 1511881650.63 (Selasa 28 Nov 10:07:30 2017)
ElapsedTime 2,60 (2,60 detik)
SourceFiles 10915
SourceFileSize 7991047699 (7,44 GB)

Mencadangkan ke Azure menggunakan restic cepat tetapi tidak sebagus duplikat:
[0:00] 96 direktori, 10819 file, 7.441 GiB
memindai 96 direktori, 10819 file dalam 0:00
[0:08] 100.00% 0B/s 7.441 GiB / 7.441 GiB 10915 / 10915 item 0 kesalahan ETA 0:00
durasi: 0:08, 861.53MiB/dtk

Dan sekarang untuk grup yang paling lambat, mencadangkan ke Backblaze B2 menggunakan restic:
memindai 4 direktori, 2781 file dalam 0:00
[0:23] 100,00% 24,855 MiB/dtk 571,663 MiB / 571,663 MiB 2785 / 2785 item 0 kesalahan ETA 0:00
durasi: 0:23, 24.60MiB/dtk

Saya tidak memiliki cukup penyimpanan di akun saya untuk mencadangkan direktori 7.4GB pada pengujian terakhir seperti pada dua contoh pertama, tetapi bagaimanapun Anda dapat melihat bahwa menggunakan duplikasi untuk mencadangkan ke Backblaze adalah yang tercepat.

Dan bahkan untuk mendapatkan istirahat hingga 23 detik, saya harus menggunakan opsi koneksi dan menentukan koneksi 500 b2.

@CurtWarfield bisa tolong coba lagi dengan rclone dan laporkan kembali?

@CurtWarfield 2.6GiB/s ke B2 tampaknya agak tinggi. Bisakah Anda mengonfirmasi bahwa ini untuk kumpulan data yang belum dicadangkan sebagian? Dibutuhkan lebih dari 2,5 detik bagi saya hanya untuk berjalan di pohon direktori stat dengan ukuran itu.

Jika duplikasi benar-benar mendapatkan kinerja seperti itu, saya ingin menjalankan beberapa tes.

Tidak kurin, kecepatan dengan duplikasi sedang disinkronkan ulang tanpa data baru.

Saya baru saja menjalankan cadangan direktori 570MB baru ke B2 menggunakan rclone seperti yang diminta. Pencadangan baru membutuhkan total 10 menit yang tampaknya lebih cepat daripada dengan istirahat.

Apakah cadangan restic yang terdaftar juga disinkronkan ulang?

ya kurin. Hanya butuh duplicity 2,6 detik untuk re-sync dan restic di Azure butuh 8 detik dan restic di B2 butuh 23 detik.
Saya baru saja memeriksa sinkronisasi ulang B2 dengan rclone. rclone lebih sesuai dengan kinerja Azure.

2017/11/28 16:58:20 INFO :
Ditransfer: 0 Bytes (0 Bytes/s)
Kesalahan: 0
Cek: 2781
Ditransfer: 0
Waktu yang berlalu: 8.7 detik

Oke, mengerti. Saya bukan ahli dalam restic internal (saya di sini untuk B2 muckery). Saya pikir ada kinerja untuk keluar dari transfer data yang sebenarnya tetapi itu tidak akan membantu untuk contoh Anda.

Namun, contoh Anda mungkin menyoroti kasus penggunaan yang paling umum, yang mencadangkan kumpulan data yang 95%+ tidak berubah, dengan banyak file kecil. Alangkah baiknya jika restic dapat dengan cepat mengidentifikasi dan melewatkan file-file ini.

Kita mungkin harus membagi ini menjadi dua bug, satu khusus untuk bandwidth B2, yang lainnya adalah menangani data yang tidak berubah (jika itu belum ada).

Itu melewatkan file, hanya butuh istirahat 12 kali lebih lama pada B2 daripada duplikasi.
Sayangnya backup awal juga lambat. Bahkan menggunakan opsi koneksi b2.

Bandwidth B2 masih terlalu lambat menggunakan restic, tidak hanya untuk menangani data yang tidak berubah tetapi juga untuk backup awal.

Apakah kami memiliki data tentang berapa lama waktu yang dibutuhkan Duplicity untuk berbicara dengan B2? 570MB dalam 10 menit adalah ~8mbps, yang sudah sejalan dengan kecepatan yang saya lihat dari restic ke b2 hari ini.

Saya akan menjalankan tes yang sama untuk pencadangan baru dengan duplikasi dan memposting hasil di sini.

Terima kasih!

Buktinya ada di puding!!!!
Jadi saya mencadangkan direktori yang sama dari server saya ke bucket B2 SAMA menggunakan restic dan duplicity.
Restic sebenarnya membutuhkan waktu sekitar 12 menit untuk mencadangkan

Duplikat hanya membutuhkan waktu 4 menit untuk mencadangkan direktori yang sama ke ember B2 yang sama
Tanggal pencadangan penuh terakhir: tidak ada
Gunakan kembali PASSPHRASE yang dikonfigurasi sebagai SIGN_PASSPHRASE
Tidak ada tanda tangan yang ditemukan, beralih ke cadangan penuh.
--------------[ Statistik Cadangan ]--------------
Waktu Mulai 1511908655.75 (Selasa 28 Nov 17:37:35 2017)
Waktu Akhir 1511908907.31 (Selasa 28 Nov 17:41:47 2017)
ElapsedTime 251,57 (4 menit 11,57 detik)
SourceFiles 2785
SourceFileSize 599784317 (572 MB)
File Baru 2785
Ukuran File Baru 599784317 (572 MB)
File yang Dihapus 0
File yang Diubah 0
ChangedFileSize 0 (0 byte)
MengubahDeltaSize 0 (0 byte)
DeltaEntries 2785
RawDeltaSize 599432061 (572 MB)
TotalDestinationSizeChange 297380160 (284 MB)
Kesalahan 0

Menjalankan skrip cadangan saya untuk kedua kalinya di ember B2 sekali lagi jauh lebih cepat daripada restic. Jadi bukan Backblaze yang lambat. Dari semua layanan cloud yang saya gunakan, Backblaze lebih cepat dari semuanya. Itu termasuk AWS dan Google Cloud.

Tanggal pencadangan penuh terakhir: Sel 28 Nov 17:37:34 2017
Gunakan kembali PASSPHRASE yang dikonfigurasi sebagai SIGN_PASSPHRASE
--------------[ Statistik Cadangan ]--------------
Waktu Mulai 1511909417.28 (Selasa 28 Nov 17:50:17 2017)
Waktu Akhir 1511909417.76 (Selasa 28 Nov 17:50:17 2017)
ElapsedTime 0.48 (0.48 detik)
SourceFiles 2785
SourceFileSize 599784317 (572 MB)
File Baru 0
Ukuran File Baru 0 (0 byte)
File yang Dihapus 0
File yang Diubah 0
ChangedFileSize 0 (0 byte)
MengubahDeltaSize 0 (0 byte)
DeltaEntries 0
RawDeltaSize 0 (0 byte)
TotalDestinationSizeChange 716 (716 byte)
Kesalahan 0

Itu ~20Mbps, yang benar-benar dapat dicapai hari ini dalam restic dengan B2 (saya baru saja mendapatkan 750Mbps dari instance GCE pada satu file besar).

Saya percaya sebagian besar dari ini ada dalam penanganan pohon direktori restic. Tapi itu tidak menjelaskan perbedaan antara Azure dan B2.

@CurtWarfield maaf karena tidak menanyakan ini sebelumnya: Versi restic mana yang Anda gunakan dalam pengujian Anda? Apa output dari restic version ?

Latar belakangnya adalah bahwa dengan restic 0.8.0 yang dirilis beberapa hari yang lalu kami telah menambahkan cache lokal untuk metadata. Sebelum itu (misalnya dengan restic 0.7.3) ia akan secara default meminta API B2 untuk setiap direktori yang ditemuinya, setidaknya untuk pencadangan non-awal. Jadi itu lambat hanya karena B2 API memiliki latensi tinggi untuk mendapatkan potongan data yang kecil.

Maukah Anda menjalankan kembali pengujian Anda dengan restic 0.8.0 atau cabang master?
Anda dapat menemukan binari terkompilasi dari cabang master restic di sini: https://beta.restic.net/?sort=time&order=desc

@ fd0 cukup yakin dia menggunakan 0.8.0. Akan menarik untuk melihat apa yang dilakukannya ketika dia menggunakan build dari cabang master.

Halo,
Ya saya menggunakan 0.8.0 :-)

Hm, saya memiliki setidaknya satu tes integrasi di Travis yang gagal karena tes backend B2 yang terlalu lambat, jadi saya kira ada sesuatu di B2 yang salah.

Saya ingin mengalihkan semua cadangan saya dari duplicity ke restic tetapi B2 terlalu lambat sekarang :-(

Baru saja melakukan beberapa pengujian lagi. Duplikat dan rclone hampir sama di AWS, Google Cloud, Azure, dan B2. Hanya B2 yang memiliki kinerja restic lambat. Sejauh ini saya harus tetap menggunakan duplicity atau rclone untuk ember B2 saya. Tetapi untuk bucket AWS, Google cloud, dan Azure saya, saya dapat mengonversi ke restic.

Berapa banyak koneksi b2 yang Anda konfigurasikan restic untuk digunakan?

Pada 29 November 2017 20:29, "Curt Warfield" [email protected] menulis:

Baru saja melakukan beberapa pengujian lagi. Duplikat dan rclone semuanya hampir sama
AWS, Google Cloud, Azure, dan B2. Hanya B2 yang memiliki slow restic
pertunjukan. Sejauh ini saya harus tetap dengan duplicity atau rclone for
ember B2 saya. Tetapi untuk AWS dan Google cloud saya, saya dapat mengonversi ke restic.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/restic/restic/issues/1383#issuecomment-348053433 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AHuypeS33viZDG2ols54qpdD-4m9hLhBks5s7gTfgaJpZM4QFFnO
.

Saya sudah mencoba semuanya dari 1 hingga 500

@CurtWarfield dapatkah Anda menempelkan doa dan output restic untuk setiap layanan?

Oh, tunggu, saya melihat Anda memiliki satu dari Azure di atas.

Tidak yakin apakah ini membantu, tetapi ini adalah poin data tambahan
istirahat 0.8.0 (v0.8.0-35-g9d0f13c4)
dibangun dari sumber dengan go 1.9.2 linux/arm di rpi3 menggunakan opsi -p 4

./restic -o b2.connections=100 cadangan ~/bin
Dimulai dengan bandwidth unggahan jenuh (~2-3 MiB/dtk) dan dengan cepat turun ke 100-200 KiB/dtk untuk sisa unggahan.

_memindai 6 direktori, 68 file dalam 0:00[2:19] 100,00% 137,554 KiB/dtk 18,672 MiB / 18,672 MiB 74 / 74 item 0 kesalahan ETA 0:00durasi: 2:19, 0.13MiB/s_

Perilaku bursty di sana disebabkan oleh fakta bahwa lib klien b2 menyangga output sebelum mengirimnya (karena harus mengirim hash sha1 sebagai bagian dari permintaan). Untuk membatasi, ini terlihat seperti koneksi _sangat cepat_ dan kemudian satu Write() atau Close() yang memblokir untuk sementara waktu.

Untuk kasus saya ini berjalan pada kecepatan garis tepat 45 MB dan mereka menurunkan kecepatan. Saya mengerti bahwa ini adalah buffering, tetapi apakah ini batasan restic?

Saya tidak percaya begitu tapi saya tidak positif. Saya dapat mengatakan bahwa semua tes yang saya coba dari VPS saya (beberapa file besar, banyak file kecil, sejumlah file besar sedang) tidak dapat menghasilkan perbedaan yang nyata pada B2 dibandingkan dengan GCS, baik untuk unggahan baru atau data yang tidak berubah. B2 adalah yang lebih lambat, tetapi lebih lambat dengan jumlah yang konstan, biasanya 2-5 detik, karena bolak-balik ke B2 (misalnya untuk mengambil kunci, atau merekam snapshot) tidak secepat itu.

.13MiB/s hanya lebih dari 1Mbps, yang tidak bagus tetapi dapat dipercaya untuk koneksi rumah, dan angka ini seharusnya cukup akurat di akhir unggahan.

Mungkin juga ada masalah koneksi yang secara otomatis pulih dari restic. Jika Anda dapat menghasilkan log debug (ingat untuk menggosok PII) saya dapat melihatnya.

Bisakah Anda mengklarifikasi bagaimana log debug ini seharusnya dibuat?

Ya, maaf, jika Anda dapat membangun dari sumbernya, periksa tag "v0.8.0" dan kemudian ikuti petunjuk di https://github.com/restic/restic/blob/master/CONTRIBUTING.md untuk membuat men-debug biner,

• jalankan build.go -tags debug
• DEBUG_LOG=/tmp/restic-debug.log ./restic [...]

Ketahuilah bahwa file log akan memiliki informasi sensitif termasuk token autentikasi. Jalankan sed -i -e '/Authorization:.*/d' /tmp/restic-debug.log untuk menghapus info auth, dan sed -i -e 's/\(GET\|POST\) [^ ]\+/\1 <redacted>/' -e '/X-Bz-File-Name/d' restic-debug.log untuk menghapus nama file, jika sensitif.

restic-debug_clean_scrubbed.log

Kurin,
Saya telah melampirkan log debug yang menunjukkan kinerja B2 yang lambat.

Terima kasih Curt. @ fd0 harus melihat ini juga jika ada sesuatu yang terjadi dalam restic. Saya melihat banyak perjalanan pulang pergi B2 secara sekilas; sepertinya ada banyak potongan data yang dikirim.

Satu hal yang saya perhatikan adalah 282 permintaan untuk "Rentang: 0-0", yang saya duga secara efektif merupakan panggilan Stat. Saya bisa percaya bahwa beberapa ratus di antaranya bertanggung jawab untuk mendorong cadangan dari detik ke menit.

Saya tidak bisa melihat sesuatu yang luar biasa, maaf. Apakah Anda sudah mencoba --limit-upload ? Kami baru saja menggabungkan perubahan yang meningkatkan banyak pembatasan bandwidth... Mungkin ada beberapa bufferbloat di suatu tempat, jadi beberapa permintaan HTTP tertunda...

Bisakah Anda menjalankan tes bufferbloat di sini? http://www.dslreports.com/speedtest

fd0,
Bisakah Anda menentukan cara menggunakan opsi --limit-upload?

Uhm, seperti yang dikatakan bantuan:

      --limit-upload int       limits uploads to a maximum rate in KiB/s. (default: unlimited)

Untuk koneksi DSL di rumah saya memiliki bandwidth upstream 40Mbit (jadi ~5MiB/s), jadi saya dapat menentukan --limit-upload 4500 untuk membatasi bandwidth upstream hingga ~4.4MiB/s dan tidak memenuhi upstream sepenuhnya.

Saya mencoba berbagai kombinasi --limit-upload dan itu malah memperburuknya!

Saya ingin tahu apakah restic memicu semacam pembentukan lalu lintas ISP. Saya cukup kesal dan beralih dari penyedia DSL ke kabel dan tidak lagi memiliki masalah dengan pengunggahan.

Saya ragu ada bentuk lalu lintas ISP apa pun karena lambat di tempat kerja (internet kelas perusahaan) dan di rumah (300/20 TWC). Tidak ada perbedaan antara kedua lokasi. Plus ingat duplikasi sangat cepat untuk Backblaze (B2)

Apakah ada hal lain yang dapat dilakukan untuk menentukan mengapa ada perbedaan kinerja seperti itu?

Mungkin seseorang dapat melihat kode duplikat untuk melihat panggilan apa yang mereka lakukan untuk memiliki kinerja yang begitu cepat dengan B2

@curtwarfield Karena baik saya maupun @kurin tidak dapat mereproduksi apa yang Anda lihat, apakah mungkin untuk mendapatkan akses sementara ke VM Linux atau wadah di jaringan Anda sehingga saya dapat mencoba mereproduksinya di sana? Kalau tidak, saya tidak punya ide tentang cara men-debug ini lebih lanjut ...

Sayangnya saya tidak memiliki cara untuk mewujudkannya dari lokasi saya. Jadi dari lokasi Anda, sinkronisasi ke B2 berjalan normal?

Ya, saya dapat dengan mudah memenuhi bandwidth upstream saya (Jerman) ke B2 (di AS).

Saya kedua ini. Lokasi: Polandia, Oranye, FTTH.

@curtwarfield Apakah ada cara @ fd0 bisa mendapatkan akses sementara untuk mereproduksi masalah? Tidak yakin bagaimana lagi kami dapat melanjutkan debugging ini.

Cukup mendaftar ke BackBlaze , Anda mendapatkan penyimpanan gratis 10GB. Tidak yakin apakah mereka menagih Anda untuk Panggilan API tetapi bagaimanapun juga itu jauh lebih murah daripada AWS.

Saya khawatir ini masalah B2. Saya sudah mencoba hal yang sama dengan klien resmi mereka dan kecepatannya menyedihkan. Di luar AS tidak berguna.

er1z, saya dengan hormat tidak setuju karena ketika saya menggunakan duplikasi dengan enkripsi GPG untuk B2 itu sangat cepat. Jika itu adalah masalah B2, itu akan lambat dengan duplikasi juga. Jangan salah paham. Saya pikir restic adalah solusi yang bagus untuk back-end cloud lainnya, hanya saja belum siap untuk dukungan B2.

@er1z saya juga tidak setuju. Ini mungkin masalah dengan B2, mungkin juga kasus sudut yang tidak ditangani dengan benar di suatu tempat (library klien B2, pustaka standar Go, kernel Linux, ...) yang memicu perilaku ini, tetapi kami belum mengetahuinya.

Biarkan saya meringkas masalah ini:

• Dalam situasi tertentu (mungkin tergantung pada jaringan, tetapi mungkin juga pada lokasi geografis) pencadangan dengan restic ke B2 lambat
• Dengan duplikasi, di jaringan yang sama, pencadangan ke B2 cepat
• Dalam situasi lain (misalnya koneksi Internet di rumah saya di Jerman), saya dapat memenuhi uplink saya sebesar 40MBit/dtk saat mengunggah data cadangan baru ke B2, jadi ini juga cepat.

Jadi, kita perlu mencari tahu apa yang dilakukan duplicity berbeda dari restic dan faktor apa yang mempengaruhi (wilayah, jaringan, ...) yang ada. @kurin dan saya mencoba melakukan itu, tetapi tanpa memiliki akses ke situasi jaringan seperti itu dan dapat melakukan debug sedikit, kami tidak akan mendapatkan informasi lebih lanjut.

Adakah yang punya ide tentang cara men-debug ini lebih lanjut? Kalau tidak, saya cenderung menutup masalah ini untuk saat ini. Pikiran?

Saya di Inggris, dan bagi saya B2 bagi saya lebih cepat pada unggahan awal snapshot (yang pertama) sebesar 230GB tetapi jika saya CTRL+C unggahan dan kemudian memulainya lagi, kemajuannya sangat lambat setelah mendapat ke tahap pengunggahan.

Saya mengaktifkan debugging dan menggunakan DEBUG_FILES=b2.go, tetapi output dari debugging hanya berhenti dan prosesnya tampak hang (atau berjalan sangat lambat). Saya memiliki sistem yang sangat terbatas memori (512MB), jadi mungkin itu saja.

Saya mencoba menggunakan DEBUG_LOG=/tmp/restic-debug.log tetapi itu hanya membanjiri IO disk saya dan semuanya melambat sehingga sistem macet. Ini adalah ReadyNAS R102 jadi bukan kotak spesifikasi terbaik.

Saya menggunakan:

$ restic version
debug enabled
restic 0.8.1 (2debb5c)
compiled with go1.9.2 on linux/amd64

Selain b2.go file lain apa yang bisa saya dapatkan dari info debug yang relevan?

Yang mengatakan, saya memiliki kotak Ubuntu 16.04 yang diperbarui sepenuhnya dan itu ada di jaringan yang sama dan itu berjalan dengan baik ...

Saat saya memiliki terlalu sedikit memori, saya mengalami crash alih-alih hanya hang, jadi saya tidak tahu apakah ini relevan untuk Anda, tetapi Anda dapat mencoba membuat restic lebih agresif GC dengan mengatur variabel lingkungan GOGC ke misalnya 20 saat Anda menjalankan istirahat. Itulah yang saya gunakan dalam VM yang dibatasi memori tempat saya menjalankan restic.

Bagaimanapun juga, backup baru hari ini ke B2 berjalan dengan baik. Saya menghapus Bucket lama dan memulai dari yang baru. Bahkan dengan debug logging pergi ke file tmp, semuanya berjalan dengan baik. Saya memperbarui biner restsic saya dari master melalui jenkins build, jadi setiap kali Anda memperbarui kode, cadangan saya berikutnya akan menggunakan versi itu. Bisakah perubahan " Tes batas waktu backend santai " membantu??

Selama 18 jam terakhir, saya telah mengunggah 65GB, itu sekitar 8Mbps. Sejauh ini saya telah menghabiskan $0,24 untuk Transaksi Kelas B dan $0,10 untuk penyimpanan.

Dalam log debug saya, saya melihat banyak kesalahan "404 Tidak Ditemukan", diikuti dengan unggahan objek yang sama persis. Itu sama di log yang diposting sebelumnya di utas ini.

Pasti tidak bisa kan?

Itulah cara kami menggunakan pustaka klien B2 sekarang:
https://github.com/restic/restic/blob/4eb9df63cf416c9654224cffc841a8e16a179915/internal/backend/b2/b2.go#L199 -L205

Saya tidak yakin apakah ini cara yang paling efisien. Kami juga memastikan bahwa file tersebut belum ada sebelum menulis ke sana.

Mungkin @kurin bisa melihat dari mana asal transaksi kelas B...

24c pada transaksi kelas B adalah ~600 ribu transaksi, yang tampaknya tinggi. Saya tahu bahwa data potongan restic, tetapi jika Anda menganggap ~5MB/chunk seharusnya hanya ada ~13k potongan dalam kumpulan data 65GB. Satu-satunya transaksi kelas B adalah fungsi seperti "stat" (get_file_info atau download_file, yang kami gunakan sebagai ganti get_file_info untuk alasan bagus yang luput dari atm saya). Jadi mengeluarkan 600k dari mereka selama sesi unggah sepertinya banyak. @fd0 , apakah restic melakukan pemeliharaan latar belakang saat mengunggah potongan? Kunci juggling dll?

Selama pengunggahan, tidak banyak yang terjadi. Sedikit juggling kunci, tapi itu seperti satu file setiap lima menit atau lebih, harus diabaikan. Untuk setiap file yang akan diupload, Attrs() dipanggil, diikuti dengan penulisan file itu sendiri. Hm. Seharusnya tidak banyak transaksi ...

Saya mungkin telah menemukan panggilan yang berlebihan ke salah satu API kelas B. Saya akan mencoba mengkonfirmasi dan memperbaikinya malam ini.

Nightlies istirahat memiliki beberapa perbaikan di dalamnya yang dapat membantu dengan masalah ini: https://beta.restic.net/restic-v0.8.2-19-g9f060576/

Saya akan tertarik untuk melihat apa perbedaannya, jika ada.

Sebagai catatan, PR adalah: #1634 #1623

Saya pikir masalah ini diselesaikan dengan 0.8.2 atau lebih baru, jadi saya akan menutupnya untuk saat ini. Silakan tinggalkan komentar jika Anda masih mengalami unggahan yang sangat lambat dengan B2 dengan 0.8.2 atau lebih baru. Terima kasih!

Saya dapat mengonfirmasi bahwa 0.8.2 adalah yang tercepat untuk saya. Kecepatan unggah bervariasi dengan B2, sama seperti sekarang dengan S3.

Saat ini saya mengunggah 0,01% setiap 18 detik. Saya memiliki 224GB yang saya unggah.

Dibutuhkan 21 jam untuk mengunggah 62% yaitu sekitar 138GB.

Hei sekarang!!! Saya baru saja menguji 0.8.3 dan akhirnya berfungsi seperti yang diharapkan !!!! Kerja bagus untuk para pengembang.
Saya masih tidak yakin mengapa orang tidak memiliki masalah dengan 0.8.2 tetapi versi itu pasti lambat untuk B2. Tapi saya senang dengan 0.8.3. Saya baru saja mencadangkan 600MB yang terdiri dari 2800 file hanya dalam 3 menit 20 detik !!!!! Sekali lagi pujian dan PEKERJAAN BESAR untuk semua yang bertanggung jawab. Anda harus pemenang!

Luar biasa, terima kasih atas umpan baliknya :)

Saya menggunakan restic sejak sekitar dua minggu, mencadangkan ke B2 ( restic v0.8.3 ). Saya memiliki sekitar 300GB data di sekitar 41.000 file yang disimpan di Raspberry Pi 3 B+ yang memiliki disk USB Western Digital 2TB terpasang. Koneksi internet saya adalah LTE, saya memiliki kecepatan unggah sekitar 20-40 Mbit/s . 240GB pertama berjalan dengan baik dalam waktu kurang dari sehari. Karena saya sedang membangun kembali seluruh jaringan dan server saya, saya harus menghentikan pencadangan sekitar 240GB. Sejak itu saya mencoba untuk memulainya beberapa kali. 240GB pertama memakan waktu sekitar 3-4 jam, tidak ada unggahan yang dilakukan, saya pikir itu hanya memeriksa file dan jika ada di ember B2. Tidak apa-apa untuk raspberry saya pikir, karena saya kira ini semua tentang menghitung hash yang mungkin cukup lambat pada Pi. Begitu sampai ke file baru di mana unggahan selesai, itu sangat lambat. Itu berarti sekitar 15 jam untuk 1GB (240GB pertama membutuhkan waktu yang hampir bersamaan). Saya memeriksa file mana yang telah dibuka restic menggunakan lsof. Ada di mana beberapa file 3-5MB kecil, dan satu file 2,5GB besar. restic mengerjakan file-file kecil itu selama tiga hari terakhir, dan juga file 2,5GB selesai. Sekarang hanya bekerja pada file besar, masing-masing berukuran sekitar 3-6GB, dengan "kecepatan" yang sama.

Ini terdengar seperti komentar @ richard-scott: https://github.com/restic/restic/issues/1383#issuecomment -365862475 - pencadangannya juga lambat ketika mencapai unggahan. Saya kira saya bisa menyelesaikannya dengan menghapus semua snapshot dari server itu, dan memulai kembali seperti yang dilakukan richard-scott. Tetapi selama cadangan saya dalam perilaku lambat itu, mungkin saya dapat memberikan beberapa informasi debug?

Bisakah dstat 20 membantu?

240GB pertama memakan waktu sekitar 3-4 jam, tidak ada unggahan yang dilakukan, saya pikir itu hanya memeriksa file dan jika ada di ember B2.

Kira-kira, ya.

Ada di mana beberapa file 3-5MB kecil, dan satu file 2,5GB besar. restic mengerjakan file-file kecil itu selama tiga hari terakhir, dan juga file 2,5GB selesai. Sekarang hanya bekerja pada file besar, masing-masing berukuran sekitar 3-6GB, dengan "kecepatan" yang sama.

Ini mungkin disebabkan oleh beberapa hal yang berbeda:

• Pembacaan file restic yang besar mungkin memiliki banyak duplikasi di dalamnya (misalnya hanya berisi null byte), jadi restic membaca blok data, kemudian mendeteksi bahwa blok ini sudah ada di repo, sehingga pindah ke blok berikutnya tanpa mengunggah apa pun
• Terkadang B2 lambat, kami tidak tahu mengapa, jadi mungkin itu adalah batas penerima di B2...

Anda dapat menguji yang berikut ini:

• Amati bandwidth IO ke hard disk, misalnya menggunakan iostat . Apakah itu berubah seiring waktu, ketika restic mencapai titik di mana ia membaca file baru?
• Anda dapat membuat repo kedua di B2 dan mencadangkan beberapa data untuk melihat apakah unggahan restic lebih cepat
• Mungkin coba cabang master terbaru, kami telah mengerjakan ulang kode arsip sepenuhnya sejak 0.8.3. Anda dapat menemukan binari terkompilasi dari cabang master restic di sini: https://beta.restic.net/?sort=time&order=desc

Pengamatan Richards mungkin terkait, tetapi itu dengan versi restic yang jauh lebih lama (0.8.1), kami telah banyak meningkatkan penanganan B2 sejak saat itu.

Jika ini masih menjadi masalah, silakan buka masalah baru sehingga kami dapat mendiskusikannya.

@netdesk Sudahkah Anda mencoba mengatur ini:

--option b2.connections=50

Saya pikir defaultnya adalah sekitar 5 koneksi paralel.

Saya mencoba versi dev terbaru seperti yang disarankan oleh @ fd0. Itu sedikit lebih cepat (dan saya suka detail keluaran baru) dan sisa 300GB selesai sekarang setelah satu hari, jadi saya tidak bisa benar-benar mereproduksinya. Tapi sebelumnya (biasa 0.8.3) lsof menunjukkan sepuluh file yang terbuka, menggunakan versi dev hanya membuka 2-3 file pada waktu yang sama. Saya tidak tahu berapa banyak koneksi ke B2 yang dibuka. Saya melakukan log iostat dan vnstat setiap menit selama pencadangan dengan versi dev. Akan memeriksa file dan melaporkan dalam edisi baru jika saya menemukan sesuatu.

Baru saja saya mencoba restic check yang gagal karena dikatakan, bahwa ada kunci yang dibuat lima hari yang lalu. Itu tentang hari dan waktu ketika percobaan pertama pencadangan 300GB terputus. Tidak dapat membayangkan jika kunci itu dapat memperlambat proses pencadangan, hanya sesuatu yang saya temukan. Karena mungkin sulit untuk mereproduksi sekarang, saya kira menggali dalam kegelapan tidak sepadan dengan waktu. Seperti yang dikatakan @fd0 , saya akan membuka masalah lain jika itu terjadi lagi.

Hai,

Saya menggunakan restic untuk mencadangkan ke b2, dan itu sangat lambat. Cadangan yang saya mulai sekitar 24 jam yang lalu sebesar 300GB bahkan belum selesai. Saya menggunakan -o b2.connections=200 tetapi saya dapat melihat paling banyak 4 koneksi terbuka dan mereka sering menganggur.

Saya mencoba meretas sedikit dalam kode dan menemukan ini . Jadi saya telah melakukan beberapa benchmark.

Saya melakukan tolok ukur ini dalam kondisi berikut:

• fast.com mengukur kecepatan unggah saya pada 300Mbps
• Saya mencadangkan hard drive yang berputar pada 7200RPM. hdparm melaporkan 175MB/s untuk pembacaan yang tidak di-cache. Saya tidak tahu bagaimana mengukur latensi pencarian, tetapi saya dapat memeriksa apakah Anda mau.
• Saya mencadangkan 2.8GB, 2413 direktori, dan 16155 file. Saat diunggah ke ember, mereka hanya mengambil 1,2GB, saya kira ini karena kompresi restic.
• Saya tinggal di Prancis dan mengunggah ke b2 di wilayah AS mereka (saya tidak menjalankan tolok ukur menyeluruh di wilayah UE, tetapi jumlahnya tampaknya sama)
• Saya menggunakan -o b2.connections=200 karena meskipun dengan itu, restic menggunakan sangat sedikit koneksi
• Setiap tes dijalankan pada repositori kosong
• Saya menjalankan restic dengan --no-cache, tetapi saya diberitahu bahwa cache tidak dibagikan di antara repositori, jadi ini seharusnya tidak mengubah apa pun.
• Saya mengkompilasi komit 5a7c27dd dari master
• Saya menggunakan debian yang tidak stabil dengan linux 5.4.0

Saya mengubah dua variabel dalam kode yang ditautkan di atas dan mendapatkan hasil ini:

| FileBaca | SimpanBlob | SimpanPohon | Total waktu |
|---|---|---|---|
| 2 | 16 | 16 20 |
16 | 16 20 | 2 menit 27 detik |
| 16 | 64 | 64*20 | 2 menit 33 detik |

Tampaknya 2 bukan nilai yang bagus untuk parameter FileRead ini. Jika itu benar-benar sesuatu yang tergantung, mungkin itu harus dibuat dapat dikonfigurasi dari baris perintah. Atau mungkin itu dan saya melewatkannya, tolong beri tahu saya.

Saya melakukan beberapa tes pada SSD juga tetapi dengan kondisi yang berbeda, dan melihat perubahan yang serupa. Mengubahnya dari 2 menjadi 8 mengubah waktu pencadangan dari 52 menit menjadi 19 menit.

Akhirnya, saya memposting ini di sini karena kebetulan saya menggunakan b2 dan semua orang mengeluh tentang kecepatan menggunakan b2 juga, jadi saya pikir ini terkait. Jika seseorang dapat melakukan benchmark serupa pada layanan penyimpanan lain, kita dapat mengetahui apakah pengaturan ini benar-benar kurang optimal untuk semua orang dan bukan hanya pelanggan b2.

Tolong beri tahu saya jika alasan saya salah, atau jika Anda memiliki saran untuk membuat cadangan saya lebih cepat.

EDIT: menambahkan ukuran ember aktual setelah pencadangan
EDIT2: catatan tambahan tentang --no-cache
EDIT3: mengklarifikasi bahwa setiap proses dilakukan pada repositori baru

Apakah mencadangkan ke repositori cadangan lokal mengubah apa pun terkait waktu yang diperlukan untuk pencadangan?

@blastrock PL di sini dan mengubah DC ke UE meningkatkan kecepatan secara dramatis. Kecepatan AS untuk sistem saya adalah ~30 KiB/s (pada uplink 20 Mbps).

Jadi target DC adalah hal yang paling penting.

Apakah mencadangkan ke repositori cadangan lokal mengubah apa pun terkait waktu yang diperlukan untuk pencadangan?

Pencadangan lokal dari folder yang sama dari HDD ke HDD yang sama, dengan pengaturan default, membutuhkan waktu 27 detik. Dengan FileReadConcurrency disetel ke 16, dibutuhkan 19 detik. Perbedaannya lebih kecil di sini, dan pengujian ini juga membuktikan bahwa waktu untuk membaca file dapat diabaikan dibandingkan dengan waktu seluruh pencadangan ke b2.

@blastrock PL di sini dan mengubah DC ke UE meningkatkan kecepatan secara dramatis. Kecepatan AS untuk sistem saya adalah ~30 KiB/s (pada uplink 20 Mbps).

Sebenarnya, pencadangan yang saya bicarakan di paragraf pertama saya sedang dilakukan di wilayah UE. Saya bingung dengan akun dan melakukan benchmark di AS. Saya dapat mencoba menjalankan tolok ukur yang sama di wilayah UE, hanya untuk mendapatkan angka yang sebanding.

Perbedaannya lebih kecil di sini, dan pengujian ini juga membuktikan bahwa waktu untuk membaca file dapat diabaikan dibandingkan dengan waktu seluruh pencadangan ke b2.

Apa yang saya tidak mengerti dalam hal itu adalah bahwa untuk SaveBlob=16 jumlah FileReaders membuat perbedaan besar. Unggahan aktual ke B2 terjadi di utas SaveBlob, jadi jika unggahan B2 adalah hambatan maka saya berharap jumlah FileReaders tidak membuat perbedaan yang lebih besar.

Dalam hal apa --no-cache membantu memastikan berjalan yang sebanding? Jika Anda memulai dengan repositori baru maka tidak ada cache untuk repositori itu dan jika repositori sudah berisi data cadangan maka Anda cukup mengukur seberapa cepat restic dapat memindai kumpulan data cadangan, dalam hal ini unggahan ke B2 tidak akan lagi kemacetan. Apakah Anda membersihkan cache sistem file di antara varian cadangan atau apakah Anda menjalankan pencadangan pemanasan untuk menjalankan cache sistem file?

Apa yang saya tidak mengerti dalam hal itu adalah bahwa untuk SaveBlob=16 jumlah FileReaders membuat perbedaan besar. Unggahan aktual ke B2 terjadi di utas SaveBlob, jadi jika unggahan B2 adalah hambatan maka saya berharap jumlah FileReaders tidak membuat perbedaan yang lebih besar.

Saya setuju, tetapi saya tidak begitu tahu bagaimana restic bekerja secara internal. Dengan SaveBlob=16 dan b2.connections=200, saya hanya dapat melihat 4-5 koneksi dari restic, dan kebanyakan tidak digunakan. Jadi tebakan saya adalah bahwa bagian "menyimpan" tidak menerima data yang cukup, dan entah bagaimana bagian "membaca" menunggu bagian "menyimpan" untuk menyelesaikan pekerjaannya alih-alih hanya mengirim lebih banyak.

Jika Anda memulai dengan repositori baru maka tidak ada cache untuk repositori itu

Ya ampun, saya pikir beberapa bagian dari cache dibagikan di antara repositori, seperti stempel waktu modifikasi file. Saya memang mulai dengan repositori baru untuk setiap tes. Saya akan mengedit posting saya untuk memperjelas itu.

Apakah Anda membersihkan cache sistem file di antara varian cadangan atau apakah Anda menjalankan pencadangan pemanasan untuk menjalankan cache sistem file?

Saya belum memikirkannya sama sekali sebenarnya ^^
Saya baru saja menjalankan kembali tes yang sama dengan FileRead=2 dua kali (untuk memastikan cache dihangatkan) dan kali ini mendapatkan 6min12s dan 6min00s. Tidak tepat waktu yang sama seperti sebelumnya, tapi masih buruk. Saya telah menjalankan kembali tes setelah itu dengan FileRead=16 dan mendapat 2min00s.

Saya pikir ini sebenarnya masalah kinerja dalam restic. Setiap file_saver membagi file menjadi beberapa bagian dan meneruskannya ke blob_saver. File_saver hanya berlanjut dengan file berikutnya setelah semua potongan diunggah. Menyimpan blob bisa cepat, jika paket belum selesai atau lambat jika paket sudah selesai dan diunggah. Atau dengan kata lain file_saver dan blob_saver tidak sepenuhnya dipisahkan. Untuk file kecil paralelisme unggahan yang efektif dibatasi hingga FileRead .

Menurut pendapat saya ini menjamin masalah sendiri, bisakah Anda membuka masalah baru dan menambahkan pengamatan Anda ke dalamnya? Bisakah Anda juga mencoba berapa lama waktu yang dibutuhkan untuk mengunggah file 1GB yang berisi data acak (misalnya dd if=/dev/urandom of=test bs=1m count=1024 )? Saya berharap itu akan berakhir dalam kisaran 2 menit.