Artikel ini akan mempertimbangkan perisian sandaran yang, dengan memecahkan aliran data kepada komponen berasingan (ketulan), membentuk repositori.
Komponen repositori boleh dimampatkan dan disulitkan lagi, dan yang paling penting - semasa proses sandaran berulang - digunakan semula.
Salinan sandaran dalam repositori sedemikian ialah rantaian komponen bernama yang disambungkan antara satu sama lain, contohnya, berdasarkan pelbagai fungsi cincang.
Terdapat beberapa penyelesaian yang serupa, saya akan memberi tumpuan kepada 3: zbackup, borgbackup dan restic.
Keputusan yang dijangka
Memandangkan semua pemohon memerlukan penciptaan repositori dalam satu cara atau yang lain, salah satu faktor yang paling penting adalah untuk menganggarkan saiz repositori. Sebaik-baiknya, saiznya hendaklah tidak lebih daripada 13 GB mengikut metodologi yang diterima, atau bahkan kurang - tertakluk kepada pengoptimuman yang baik.
Ia juga sangat diingini untuk dapat membuat salinan sandaran fail secara langsung, tanpa menggunakan pengarkib seperti tar, serta berfungsi dengan ssh/sftp tanpa alat tambahan seperti rsync dan sshfs.
Kelakuan semasa membuat sandaran:
- Saiz repositori akan sama dengan saiz perubahan, atau kurang.
- Beban CPU yang berat dijangka apabila menggunakan pemampatan dan/atau penyulitan, dan beban rangkaian dan cakera yang agak tinggi berkemungkinan jika proses pengarkiban dan/atau penyulitan berjalan pada pelayan storan sandaran.
- Jika repositori rosak, ralat tertunda mungkin berlaku semasa membuat sandaran baharu dan semasa cuba memulihkan. Adalah perlu untuk merancang langkah tambahan untuk memastikan integriti repositori atau menggunakan alat terbina dalam untuk menyemak integritinya.
Bekerja dengan tar diambil sebagai nilai rujukan, seperti yang ditunjukkan dalam salah satu artikel sebelumnya.
Menguji zbackup
Mekanisme umum zbackup ialah program mencari dalam kawasan aliran data input yang mengandungi data yang sama, kemudian secara pilihan memampatkan dan menyulitkannya, menyimpan setiap kawasan hanya sekali.
Penyahduplikasian menggunakan fungsi cincang gelang 64-bit dengan tetingkap gelongsor untuk menyemak padanan bait demi bait terhadap blok data sedia ada (sama seperti cara rsync melaksanakannya).
lzma dan lzo berbilang benang digunakan untuk pemampatan, dan aes untuk penyulitan. Versi terkini mempunyai keupayaan untuk memadam data lama daripada repositori pada masa hadapan.
Program ini ditulis dalam C++ dengan kebergantungan minimum. Pengarang nampaknya diilhamkan oleh cara unix, jadi program ini menerima data pada stdin semasa membuat sandaran, menghasilkan aliran data yang serupa pada stdout apabila memulihkan. Oleh itu, zbackup boleh digunakan sebagai "blok binaan" yang sangat baik apabila menulis penyelesaian sandaran anda sendiri. Sebagai contoh, pengarang artikel telah menggunakan program ini sebagai alat sandaran utama untuk mesin rumah sejak kira-kira 2014.
Aliran data akan menjadi tar biasa melainkan dinyatakan sebaliknya.
Mari lihat apa hasilnya:
Kerja telah disemak dalam 2 pilihan:
- repositori dibuat dan zbackup dilancarkan pada pelayan dengan data sumber, kemudian kandungan repositori dipindahkan ke pelayan storan sandaran.
- repositori dibuat pada pelayan storan sandaran, zbackup dilancarkan melalui ssh pada pelayan storan sandaran, dan data dihantar kepadanya melalui paip.
Keputusan pilihan pertama adalah seperti berikut: 43m11s - apabila menggunakan repositori yang tidak disulitkan dan pemampat lzma, 19m13s - apabila menggantikan pemampat dengan lzo.
Beban pada pelayan dengan data asal adalah seperti berikut (contoh dengan lzma ditunjukkan; dengan lzo terdapat kira-kira gambar yang sama, tetapi bahagian rsync adalah kira-kira satu perempat daripada masa):
Adalah jelas bahawa proses sandaran sedemikian hanya sesuai untuk perubahan yang agak jarang dan kecil. Ia juga sangat dinasihatkan untuk mengehadkan zbackup kepada 1 utas, jika tidak akan terdapat beban CPU yang sangat tinggi, kerana Program ini sangat baik untuk berfungsi dalam pelbagai utas. Beban pada cakera adalah kecil, yang secara amnya tidak akan kelihatan dengan subsistem cakera berasaskan ssd moden. Anda juga boleh melihat dengan jelas permulaan proses menyegerakkan data repositori ke pelayan jauh; kelajuan operasi adalah setanding dengan rsync biasa dan bergantung pada prestasi subsistem cakera pelayan storan sandaran. Kelemahan pendekatan ini ialah penyimpanan repositori tempatan dan, akibatnya, pertindihan data.
Lebih menarik dan boleh digunakan dalam amalan ialah pilihan kedua, menjalankan zbackup terus pada pelayan storan sandaran.
Pertama, kami akan menguji operasi tanpa menggunakan penyulitan dengan pemampat lzma:
Masa berjalan setiap ujian dijalankan:
Pelancaran 1
Pelancaran 2
Pelancaran 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Jika anda mendayakan penyulitan menggunakan aes, hasilnya agak hampir:
Masa operasi pada data yang sama, dengan penyulitan:
Pelancaran 1
Pelancaran 2
Pelancaran 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Jika penyulitan digabungkan dengan pemampatan menggunakan lzo, ia kelihatan seperti ini:
Jam:
Pelancaran 1
Pelancaran 2
Pelancaran 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Saiz repositori yang terhasil adalah agak sama pada 13GB. Ini bermakna deduplikasi berfungsi dengan betul. Selain itu, pada data yang sudah dimampatkan, menggunakan lzo memberikan kesan yang ketara; dari segi jumlah masa operasi, zbackup hampir kepada pendua/pendua, tetapi ketinggalan di belakang yang berdasarkan librsync sebanyak 2-5 kali.
Kelebihannya adalah jelas - menjimatkan ruang cakera pada pelayan storan sandaran. Bagi alat semakan repositori, pengarang zbackup tidak menyediakannya; adalah disyorkan untuk menggunakan tatasusunan cakera toleran kesalahan atau pembekal awan.
Secara keseluruhan, kesan yang sangat baik, walaupun pada hakikatnya projek itu telah berdiri diam selama kira-kira 3 tahun (permintaan ciri terakhir adalah kira-kira setahun yang lalu, tetapi tanpa jawapan).
Menguji borgbackup
Borgbackup ialah garpu loteng, sistem lain yang serupa dengan zbackup. Ditulis dalam python, ia mempunyai senarai keupayaan yang serupa dengan zbackup, tetapi juga boleh:
- Lekapkan sandaran melalui fius
- Semak kandungan repositori
- Bekerja dalam mod pelayan-pelanggan
- Gunakan pelbagai pemampat untuk data, serta penentuan heuristik jenis fail semasa memampatkannya.
- 2 pilihan penyulitan, aes dan blake
- Alat terbina dalam untuk
semakan prestasi
borgbackup penanda aras crud ssh://backup_server/repo/path local_dir
Hasilnya adalah seperti berikut:
CZ-BIG 96.51 MB/s (10 100.00 MB fail semua-sifar: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB fail semua-sifar: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB fail semua-sifar: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB fail semua-sifar: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB fail rawak: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB fail rawak: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB fail rawak: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB fail rawak: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB fail semua-sifar: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB fail semua-sifar: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB fail semua-sifar: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB fail semua-sifar: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB fail rawak: 26.45s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB fail rawak: 14.51s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB fail rawak: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB fail rawak: 20.49s)
CZ-KECIL 11.72 MB/s (10000 10.00 kB fail semua-sifar: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB fail semua-sifar: 3.07s)
UZ-KECIL 19.37 MB/s (10000 10.00 kB fail semua-sifar: 5.16s)
DZ-KECIL 33.71 MB/s (10000 10.00 kB fail semua-sifar: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB fail rawak: 14.60s)
RR-KECIL 31.27 MB/s (10000 10.00 kB fail rawak: 3.20s)
UR-SMALL 12.28 MB/s (10000 10.00 kB fail rawak: 8.14s)
DR-SMALL 18.78 MB/s (10000 10.00 kB fail rawak: 5.32s)
Semasa ujian, heuristik mampatan akan digunakan untuk menentukan jenis fail (auto mampatan), dan keputusannya adalah seperti berikut:
Mula-mula, mari kita semak cara ia berfungsi tanpa penyulitan:
Jam:
Pelancaran 1
Pelancaran 2
Pelancaran 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Jika anda mendayakan kebenaran repositori (mod disahkan), hasilnya akan ditutup:
Jam:
Pelancaran 1
Pelancaran 2
Pelancaran 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Apabila penyulitan aes diaktifkan, hasilnya tidak banyak merosot:
Pelancaran 1
Pelancaran 2
Pelancaran 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Dan jika anda menukar aes kepada blake, keadaan akan bertambah baik sepenuhnya:
Jam:
Pelancaran 1
Pelancaran 2
Pelancaran 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Seperti dalam kes zbackup, saiz repositori ialah 13GB malah lebih sedikit, yang biasanya dijangkakan. Saya sangat gembira dengan masa berjalan; ia setanding dengan penyelesaian berdasarkan librsync, memberikan keupayaan yang lebih luas. Saya juga gembira dengan keupayaan untuk menetapkan pelbagai parameter melalui pembolehubah persekitaran, yang memberikan kelebihan yang sangat serius apabila menggunakan borgbackup dalam mod automatik. Saya juga berpuas hati dengan beban semasa sandaran: berdasarkan beban pemproses, borgbackup berfungsi dalam 1 utas.
Tidak ada kelemahan tertentu semasa menggunakannya.
ujian rehat
Walaupun fakta bahawa restic adalah penyelesaian yang agak baru (2 calon pertama diketahui pada tahun 2013 dan lebih lama), ia mempunyai ciri yang agak baik. Ditulis dalam Go.
Apabila dibandingkan dengan zbackup, ia juga memberikan:
- Memeriksa integriti repositori (termasuk menyemak bahagian).
- Senarai besar protokol dan pembekal yang disokong untuk menyimpan sandaran, serta sokongan untuk rclone - rsync untuk penyelesaian awan.
- Membandingkan 2 sandaran antara satu sama lain.
- Memasang repositori melalui fius.
Secara umum, senarai ciri agak hampir dengan borgbackup, di beberapa tempat lebih banyak, di tempat lain kurang. Salah satu cirinya ialah tiada cara untuk melumpuhkan penyulitan, dan oleh itu salinan sandaran akan sentiasa disulitkan. Mari kita lihat dalam amalan apa yang boleh diperah daripada perisian ini:
Hasilnya adalah seperti berikut:
Jam:
Pelancaran 1
Pelancaran 2
Pelancaran 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Hasil prestasi juga setanding dengan penyelesaian berasaskan rsync dan, secara amnya, sangat hampir dengan borgbackup, tetapi beban CPU lebih tinggi (berbilang benang berjalan) dan gigi gergaji.
Kemungkinan besar, program ini dihadkan oleh prestasi subsistem cakera pada pelayan storan data, seperti yang telah berlaku dengan rsync. Saiz repositori ialah 13GB, sama seperti zbackup atau borgbackup, tidak ada kelemahan yang jelas apabila menggunakan penyelesaian ini.
Penemuan
Malah, semua calon mencapai keputusan yang sama, tetapi pada harga yang berbeza. Borgbackup menunjukkan prestasi terbaik, restic sedikit perlahan, zbackup mungkin tidak berbaloi untuk mula digunakan,
dan jika ia sudah digunakan, cuba tukar kepada borgbackup atau restic.
Penemuan
Penyelesaian yang paling menjanjikan nampaknya tenang, kerana... dialah yang mempunyai nisbah keupayaan terbaik kepada kelajuan operasi, tetapi jangan tergesa-gesa membuat kesimpulan umum buat masa ini.
Borgbackup pada dasarnya tidak lebih teruk, tetapi zbackup mungkin lebih baik diganti. Benar, zbackup masih boleh digunakan untuk memastikan peraturan 3-2-1 berfungsi. Sebagai contoh, sebagai tambahan kepada (lib) kemudahan sandaran berasaskan rsync.
Pengumuman
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