Nota ini membincangkan alat sandaran yang melakukan sandaran dengan mencipta arkib pada pelayan sandaran.
Antara yang memenuhi keperluan adalah duplicity (yang mempunyai antara muka yang bagus dalam bentuk deja dup) dan duplicati.
Satu lagi alat sandaran yang sangat luar biasa ialah dar, tetapi kerana ia mempunyai senarai pilihan yang sangat luas - metodologi ujian merangkumi hampir 10% daripada kemampuannya - kami tidak mengujinya sebagai sebahagian daripada kitaran semasa.
Keputusan yang dijangka
Memandangkan kedua-dua calon membuat arkib dalam satu cara atau yang lain, tar biasa boleh digunakan sebagai panduan.
Selain itu, kami akan menilai sejauh mana storan data pada pelayan storan dioptimumkan dengan mencipta salinan sandaran yang mengandungi hanya perbezaan antara salinan penuh dan keadaan semasa fail, atau antara arkib sebelumnya dan semasa (bertambah, menurun, dsb.) .
Kelakuan semasa membuat sandaran:
- Sebilangan kecil fail pada pelayan storan sandaran (setanding dengan bilangan salinan sandaran atau saiz data dalam GB), tetapi saiznya agak besar (berpuluh hingga ratusan megabait).
- Saiz repositori hanya akan merangkumi perubahan - tiada pendua akan disimpan, jadi saiz repositori akan lebih kecil daripada perisian berasaskan rsync.
- Jangkakan beban CPU yang berat apabila menggunakan pemampatan dan/atau penyulitan, dan kemungkinan beban rangkaian dan cakera yang agak tinggi jika proses pengarkiban dan/atau penyulitan berjalan pada pelayan storan sandaran.
Mari jalankan arahan berikut sebagai nilai rujukan:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Keputusan pelaksanaan adalah seperti berikut:
Masa pelaksanaan 3m12s. Ia boleh dilihat bahawa kelajuan dihadkan oleh subsistem cakera pelayan storan sandaran, seperti dalam contoh dengan . Hanya lebih cepat sedikit, kerana... rakaman pergi ke satu fail.
Selain itu, untuk menilai pemampatan, mari jalankan pilihan yang sama, tetapi dayakan pemampatan pada bahagian pelayan sandaran:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Hasilnya ialah:
Masa pelaksanaan 10m11s. Kemungkinan besar kesesakan adalah pemampat aliran tunggal pada hujung penerima.
Perintah yang sama, tetapi dengan mampatan dipindahkan ke pelayan dengan data asal untuk menguji hipotesis bahawa kesesakan adalah pemampat satu benang.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Ternyata begini:
Masa pelaksanaan ialah 9m37s. Beban pada satu teras oleh pemampat jelas kelihatan, kerana Kelajuan pemindahan rangkaian dan beban pada subsistem cakera sumber adalah serupa.
Untuk menilai penyulitan, anda boleh menggunakan openssl atau gpg dengan menyambungkan arahan tambahan openssl atau gpg dalam paip. Untuk rujukan akan ada arahan seperti ini:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Hasilnya keluar seperti ini:
Masa pelaksanaan ternyata menjadi 10m30s, kerana 2 proses sedang berjalan di bahagian penerima - kesesakan sekali lagi ialah pemampat satu benang, ditambah dengan overhed penyulitan kecil.
UPD: Atas permintaan bliznezz saya menambah ujian dengan pigz. Jika anda hanya menggunakan pemampat, ia akan mengambil masa 6m30s, jika anda juga menambah penyulitan, ia akan menjadi kira-kira 7m. Penurunan dalam graf bawah ialah cache cakera yang tidak disiram:
Ujian pendua
Duplicity ialah perisian python untuk sandaran dengan mencipta arkib yang disulitkan dalam format tar.
Untuk arkib tambahan, librsync digunakan, jadi anda boleh mengharapkan tingkah laku yang diterangkan dalam .
Sandaran boleh disulitkan dan ditandatangani menggunakan gnupg, yang penting apabila menggunakan pembekal yang berbeza untuk menyimpan sandaran (s3, backblaze, gdrive, dsb.)
Mari lihat apa hasilnya:
Ini adalah hasil yang kami dapat apabila berjalan tanpa penyulitan
spoiler
Masa berjalan setiap ujian dijalankan:
Pelancaran 1
Pelancaran 2
Pelancaran 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Dan berikut ialah keputusan apabila penyulitan gnupg didayakan, dengan saiz kunci 2048 bit:
Masa operasi pada data yang sama, dengan penyulitan:
Pelancaran 1
Pelancaran 2
Pelancaran 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Saiz blok ditunjukkan - 512 megabait, yang jelas kelihatan dalam graf; Beban pemproses sebenarnya kekal pada 50%, yang bermaksud bahawa program ini menggunakan tidak lebih daripada satu teras pemproses.
Prinsip operasi program juga agak jelas kelihatan: mereka mengambil sekeping data, memampatkannya, dan menghantarnya ke pelayan storan sandaran, yang boleh menjadi agak perlahan.
Ciri lain ialah masa berjalan program yang boleh diramal, yang bergantung hanya pada saiz data yang diubah.
Mendayakan penyulitan tidak meningkatkan masa berjalan program dengan ketara, tetapi ia meningkatkan beban pemproses sebanyak kira-kira 10%, yang boleh menjadi bonus yang cukup bagus.
Malangnya, program ini tidak dapat mengesan keadaan dengan betul dengan penamaan semula direktori, dan saiz repositori yang terhasil ternyata sama dengan saiz perubahan (iaitu, semua 18GB), tetapi keupayaan untuk menggunakan pelayan yang tidak dipercayai untuk sandaran dengan jelas meliputi tingkah laku ini.
Ujian pendua
Perisian ini ditulis dalam C# dan dijalankan menggunakan satu set perpustakaan daripada Mono. Terdapat GUI dan juga versi CLI.
Senarai anggaran ciri utama adalah serupa dengan pendua, termasuk pelbagai penyedia storan sandaran, namun, tidak seperti pendua, kebanyakan ciri tersedia tanpa alat pihak ketiga. Sama ada ini tambah atau tolak bergantung pada kes tertentu, tetapi untuk pemula, kemungkinan besar lebih mudah untuk mempunyai senarai semua ciri di hadapannya sekaligus, daripada perlu memasang pakej tambahan untuk python, seperti yang ada. kes dengan pendua.
Satu lagi nuansa kecil - program secara aktif menulis pangkalan data sqlite tempatan bagi pihak pengguna yang memulakan sandaran, jadi anda perlu memastikan bahawa pangkalan data yang diperlukan dinyatakan dengan betul setiap kali proses dimulakan menggunakan cli. Apabila bekerja melalui GUI atau WEBGUI, butiran akan disembunyikan daripada pengguna.
Mari lihat apakah penunjuk yang boleh dihasilkan oleh penyelesaian ini:
Jika anda mematikan penyulitan (dan WEBGUI tidak mengesyorkan melakukan ini), hasilnya adalah seperti berikut:
Jam:
Pelancaran 1
Pelancaran 2
Pelancaran 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Dengan penyulitan didayakan, menggunakan aes, ia kelihatan seperti ini:
Jam:
Pelancaran 1
Pelancaran 2
Pelancaran 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Dan jika anda menggunakan gnupg program luaran, hasil berikut keluar:
Pelancaran 1
Pelancaran 2
Pelancaran 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Seperti yang anda lihat, program ini boleh berfungsi dalam beberapa utas, tetapi ini tidak menjadikannya penyelesaian yang lebih produktif, dan jika anda membandingkan kerja penyulitan, ia melancarkan program luaran
ternyata lebih pantas daripada menggunakan perpustakaan dari set Mono. Ini mungkin disebabkan oleh fakta bahawa program luaran lebih dioptimumkan.
Satu lagi perkara yang menarik ialah hakikat bahawa saiz repositori mengambil masa sama seperti data yang diubah sebenar, i.e. duplicati mengesan nama semula direktori dan mengendalikan situasi ini dengan betul. Ini dapat dilihat semasa menjalankan ujian kedua.
Secara keseluruhan, tanggapan yang agak positif terhadap program ini, termasuk agak mesra kepada pemula.
Penemuan
Kedua-dua calon bekerja agak perlahan, tetapi secara umum, berbanding tar biasa, terdapat kemajuan, sekurang-kurangnya dengan pendua. Harga kemajuan sedemikian juga jelas - beban yang ketara
pemproses. Secara umum, tiada sisihan khas dalam meramalkan keputusan.
Penemuan
Jika anda tidak perlu tergesa-gesa ke mana-mana, dan juga mempunyai pemproses ganti, mana-mana penyelesaian yang dipertimbangkan akan berjaya, dalam apa jua keadaan, agak banyak kerja telah dilakukan yang tidak boleh diulang dengan menulis skrip pembalut di atas tar . Kehadiran penyulitan adalah harta yang sangat diperlukan jika pelayan untuk menyimpan salinan sandaran tidak boleh dipercayai sepenuhnya.
Berbanding dengan penyelesaian berasaskan - prestasi boleh menjadi beberapa kali lebih teruk, walaupun pada hakikatnya dalam bentuk tulen tar berfungsi 20-30% lebih cepat daripada rsync.
Terdapat penjimatan pada saiz repositori, tetapi hanya dengan pendua.
Pengumuman
Sandaran Bahagian 3: Semak dan menguji kesduaan, pendua, penduaan deja
Sandaran Bahagian 4: Menyemak dan menguji zbackup, restic, borgbackup
Sandaran Bahagian 5: Menguji bacula dan sandaran veeam untuk linux
Sandaran Bahagian 6: Membandingkan Alat Sandaran
Sandaran Bahagian 7: Kesimpulan
Dihantar oleh: Pavel Demkovich
Sumber: www.habr.com