Artikel ini akan membahas alat perangkat lunak cadangan yang, dengan memecah aliran data menjadi komponen terpisah (potongan), membentuk repositori.
Komponen repositori juga dapat dikompresi dan dienkripsi, dan yang paling penting - dengan proses pencadangan berulang - digunakan kembali.
Cadangan dalam repositori serupa adalah rantai bernama komponen terkait, misalnya, berdasarkan berbagai fungsi hash.
Ada beberapa solusi serupa, saya akan fokus pada 3: zbackup, borgbackup dan restic.
Hasil yang Diharapkan
Karena semua pelamar dalam satu atau lain cara memerlukan pembuatan repositori, salah satu faktor paling penting akan menilai ukuran repositori. Dalam kasus yang ideal, ukurannya tidak boleh lebih dari 13 GB sesuai dengan metodologi yang diterima, atau bahkan kurang - tergantung pada optimasi yang baik.
Ini juga sangat diinginkan untuk dapat membuat cadangan file secara langsung tanpa menggunakan pengarsip tar, serta bekerja dengan ssh / sftp tanpa alat tambahan seperti rsync dan sshfs.
Perilaku Cadangan:
- Ukuran repositori akan sama dengan ukuran perubahan, atau kurang.
- Beban prosesor yang besar diharapkan saat menggunakan kompresi dan / atau enkripsi, dan beban yang agak besar pada jaringan dan subsistem disk mungkin jika proses pengarsipan dan / atau enkripsi akan bekerja pada server penyimpanan cadangan.
- Jika Anda merusak repositori, kesalahan tertunda kemungkinan terjadi saat membuat cadangan baru, dan saat mencoba memulihkan. Penting untuk merencanakan tindakan tambahan untuk memastikan integritas repositori atau menggunakan cara bawaan untuk memeriksa integritasnya.
Bekerja dengan tar diterima sebagai nilai referensi, seperti yang ditunjukkan pada salah satu artikel sebelumnya.
Pengujian Zbackup
Mekanisme umum operasi zbackup adalah bahwa program tersebut menemukan area yang berisi data yang sama dalam aliran data yang disediakan pada input, kemudian mengompres dan mengenkripsi mereka secara opsional, menghemat setiap area hanya 1 kali.
Untuk deduplikasi, fungsi hash ring 64-bit dengan jendela geser digunakan untuk memeriksa-byte untuk kebetulan dengan blok data yang ada (mirip dengan bagaimana itu diterapkan dalam rsync).
Untuk kompresi, lzma dan lzo digunakan dalam eksekusi multi-threaded, dan untuk enkripsi - aes. Di versi terbaru ada peluang di masa depan untuk menghapus data lama dari repositori.
Program ini ditulis dalam C ++ dengan dependensi minimal. Penulis tampaknya terinspirasi oleh cara unix, sehingga program menerima data pada stdin saat membuat cadangan, memberikan aliran data yang serupa ke stdout saat memulihkan. Dengan demikian, zbackup dapat digunakan sebagai "batu bata" yang cukup bagus saat menulis solusi cadangan Anda sendiri. Misalnya, penulis artikel, program ini adalah alat cadangan utama untuk mesin rumahan sejak sekitar 2014.
Tar reguler akan digunakan sebagai aliran data, kecuali dinyatakan lain.
Mari kita lihat hasilnya nanti:Verifikasi karya dilakukan dalam 2 versi:
- repositori dibuat dan zbackup diluncurkan pada server dengan sumber data, lalu isi repositori ditransfer ke server penyimpanan cadangan.
- repositori dibuat pada server penyimpanan cadangan, zbackup diluncurkan melalui ssh pada server penyimpanan cadangan, data diberikan melalui pipa.
Hasil opsi pertama adalah sebagai berikut: 43m11s - saat menggunakan repositori dan lzma kompresor yang tidak terenkripsi, 19m13s - saat mengganti kompresor dengan lzo.
Beban pada server dengan sumber data adalah sebagai berikut (contoh dengan lzma ditunjukkan, dengan lzo ada sekitar gambar yang sama, tetapi proporsi rsync sekitar seperempat dari waktu):
Jelas bahwa proses pencadangan seperti itu hanya cocok untuk perubahan yang relatif jarang dan kecil. Juga sangat diinginkan untuk membatasi operasi zbackup menjadi 1 utas, jika tidak akan ada beban yang sangat tinggi pada prosesor, karena program ini sangat bagus untuk bekerja di banyak utas. Beban disk kecil, yang, secara umum, dengan subsistem disk berbasis SSD modern, tidak akan terlihat. Anda juga dapat dengan jelas melihat awal proses sinkronisasi data repositori ke server jauh, kecepatannya sebanding dengan rsync biasa dan tergantung pada kinerja subsistem disk server penyimpanan cadangan. Kelemahan dari pendekatan ini adalah penyimpanan repositori lokal dan, sebagai akibatnya, duplikasi data.
Lebih menarik dan praktis dalam praktiknya adalah opsi kedua dengan menjalankan zbackup segera di server penyimpanan cadangan.
Pertama, kami akan memeriksa operasi tanpa menggunakan enkripsi dengan kompresor lzma:
Waktu berjalan dari setiap percobaan:
Jika Anda mengaktifkan enkripsi menggunakan aes, hasilnya cukup dekat:
Waktu pengoperasian pada data yang sama, dengan enkripsi:
Jika enkripsi digabungkan dengan kompresi pada lzo, akan seperti ini:
Waktu kerja:
Ukuran repositori yang dihasilkan relatif sama dan sebesar 13GB. Ini berarti bahwa deduplikasi berfungsi dengan benar. Juga, pada data yang sudah dikompresi, penggunaan lzo memberikan efek nyata, dalam hal total waktu operasi, zbackup mendekati duplikasi / dupati, namun, ia tertinggal 2-5 kali di belakang yang berbasis librsync.
Manfaatnya jelas - menghemat ruang disk di server penyimpanan cadangan. Adapun alat untuk memeriksa repositori - mereka tidak disediakan oleh zbackup, disarankan untuk menggunakan array disk gagal-aman atau penyedia cloud.
Secara umum, kesan yang sangat baik, terlepas dari kenyataan bahwa proyek ini sekitar 3 tahun di tempat (permintaan fitur terakhir adalah sekitar setahun yang lalu, tetapi tanpa jawaban).
Menguji borgbackup
Borgbackup adalah cabang loteng, sistem lain yang mirip zbackup. Itu ditulis dalam python, memiliki daftar fitur yang mirip dengan zbackup, tetapi juga tahu caranya:
- Pasang cadangan melalui sekering
- Periksa konten repositori
- Bekerja dalam mode client-server
- Gunakan berbagai kompresor untuk data, serta definisi heuristik dari tipe file saat mengompresnya.
- 2 pilihan untuk enkripsi, aes dan blake
- Alat bawaan untuk
pemeriksaan kinerjaborgbackup benchmark crud ssh: // backup_server / repo / path local_dir
Hasilnya adalah sebagai berikut:
CZ-BIG 96.51 MB / s (10 100.00 MB semua file nol: 10.36d)
RZ-BIG 57,22 MB / s (10 100,00 MB semua file nol: 17,48 dtk)
UZ-BIG 253,63 MB / s (10 100,00 MB file semua-nol: 3,94s)
DZ-BIG 351,06 MB / s (10 100,00 MB file semua-nol: 2,85)
CR-BIG 34.30 MB / s (10 100.00 MB file acak: 29.15s)
RR-BIG 60.69 MB / s (10 100.00 MB file acak: 16.48s)
UR-BIG 311,06 MB / s (10 100,00 MB file acak: 3,21d)
DR-BIG 72.63 MB / s (10 100.00 MB file acak: 13.77d)
CZ-MEDIUM 108,59 MB / s (1000 1,00 MB semua-nol file: 9,21)
RZ-MEDIUM 76,16 MB / s (1000 1,00 MB semua-nol file: 13,13d)
UZ-MEDIUM 331.27 MB / s (1000 1.00 MB semua-nol file: 3.02s)
DZ-MEDIUM 387,36 MB / dtk (1000 1,00 MB semua-nol file: 2,58 dtk)
CR-MEDIUM 37.80 MB / s (1000 1.00 MB file acak: 26.45s)
RR-MEDIUM 68,90 MB / s (1000 1,00 MB file acak: 14,51d)
UR-MEDIUM 347.24 MB / s (1000 1.00 MB file acak: 2.88s)
DR-MEDIUM 48,80 MB / s (1000 1,00 MB file acak: 20,49d)
CZ-SMALL 11,72 MB / s ( 10.000,00 kB semua-nol file: 8,53s)
RZ-SMALL 32,57 MB / s (10.000,00 kB semua-nol file: 3.07s)
UZ-SMALL 19,37 MB / s ( 10.000,00 kB semua-nol file: 5.16d)
DZ-SMALL 33,71 MB / s (10.000,00 kB semua-nol file: 2,97s)
CR-SMALL 6.85 MB / s ( 10000,00 kB file acak: 14.60d)
RR-SMALL 31,27 MB / s ( 10000,00 kB file acak: 3,20s)
UR-SMALL 12,28 MB / s ( file acak 10000,00 kB: 8,14d)
DR-SMALL 18,78 MB / s ( 10000,00 kB file acak: 5,32d)
Selama pengujian, heuristik akan digunakan dalam kompresi dengan definisi tipe file (kompresi otomatis), dan hasilnya adalah sebagai berikut:
Pertama, periksa operasi tanpa enkripsi:
Waktu kerja:
Jika Anda mengaktifkan otorisasi repositori (mode dikonfirmasi), hasilnya akan ditutup:
Waktu kerja:
Ketika enkripsi aes diaktifkan, hasilnya tidak memburuk banyak:
Dan jika Anda mengubah aes menjadi blake, situasinya akan membaik sepenuhnya:
Waktu kerja:
Seperti dalam kasus zbackup, ukuran repositori adalah 13GB dan bahkan sedikit lebih sedikit, yang, secara umum, diharapkan. Waktu bekerja sangat menyenangkan, ini sebanding dengan solusi berdasarkan librsync, memberikan kemungkinan yang jauh lebih luas. Saya juga senang dengan kemampuan untuk mengatur berbagai parameter melalui variabel lingkungan, yang memberikan keuntungan yang sangat serius ketika menggunakan borgbackup dalam mode otomatis. Juga senang dengan beban selama pencadangan: dilihat dari beban prosesor - borgbackup bekerja dalam 1 utas.
Tidak ada minus khusus saat menggunakan.
Menguji pengujian
Terlepas dari kenyataan bahwa restic adalah solusi yang cukup baru (2 kandidat pertama telah dikenal sejak 2013 dan lebih tua), ia memiliki karakteristik yang cukup baik. Ditulis dalam Go.
Jika dibandingkan dengan zbackup, itu juga memberikan:
- Memeriksa integritas repositori (termasuk bagian check in).
- Daftar besar protokol dan penyedia yang didukung untuk menyimpan cadangan, serta dukungan rclone - rsync untuk solusi cloud.
- Perbandingan 2 backup di antara mereka sendiri.
- Memasang repositori melalui sekering.
Secara umum, daftar kemungkinan cukup dekat dengan borgbackup, di beberapa tempat lebih banyak, di beberapa tempat kurang. Dari fitur - kurangnya kemampuan untuk menonaktifkan enkripsi, dan karenanya, cadangan akan selalu dienkripsi. Mari kita lihat dalam praktiknya apa yang dapat Anda peras dari perangkat lunak ini:
Hasilnya adalah sebagai berikut:
Waktu kerja:
Hasilnya juga sebanding dengan solusi berbasis rsync dan, secara umum, sangat dekat dengan borgbackup, tetapi beban prosesor lebih tinggi (beberapa thread bekerja) dan gigi gergaji.
Kemungkinan besar, program ini tergantung pada kinerja subsistem disk pada server penyimpanan, seperti halnya dengan rsync. Ukuran repositori adalah 13GB, sama seperti zbackup atau borgbackup, tidak ada minus yang jelas saat menggunakan solusi ini.
Hasil
Bahkan, semua kandidat mendapat indikator dekat, tetapi dengan harga yang berbeda. Borgbackup telah menunjukkan dirinya sebagai yang terbaik, sedikit lebih lambat - restic, zbackup, mungkin Anda seharusnya tidak mulai mendaftar,
dan jika sudah digunakan, coba ganti ke borgbackup atau restic.
Kesimpulan
Solusi yang paling menjanjikan adalah restic, seperti dialah yang memiliki rasio kemampuan terbaik untuk kecepatan, tetapi untuk saat ini kami tidak akan terburu-buru untuk kesimpulan umum.
Borgbackup, pada prinsipnya, tidak lebih buruk, tetapi zbackup mungkin lebih baik untuk diganti. Namun, untuk memastikan bahwa aturan 3-2-1 berfungsi, zbackup masih dapat digunakan. Misalnya, di samping alat cadangan berdasarkan (lib) rsync.
Pengumuman
Cadangan, bagian 1: Mengapa Anda memerlukan cadangan, tinjauan umum metode, teknologi
Cadangan, Bagian 2: Tinjauan Umum dan Pengujian alat pencadangan berbasis rsync
Cadangan, Bagian 3: Gambaran Umum dan Pengujian duplikasi, dupati
Cadangan, Bagian 4: Tinjauan Umum dan Pengujian zbackup, restic, borgbackup
Cadangan, Bagian 5: Menguji Bacula dan Cadangan Veeam untuk Linux
Cadangan: bagian yang diminta oleh pembaca: ulasan AMANDA, UrBackup, BackupPC
Cadangan, Bagian 6: Membandingkan Alat Cadangan
Cadangan Bagian 7: Kesimpulan
Diposting oleh Finnix