Artikel ini akan membahas perangkat lunak cadangan yang, dengan memecah aliran data menjadi komponen-komponen terpisah (potongan), membentuk repositori.
Komponen repositori dapat dikompresi dan dienkripsi lebih lanjut, dan yang terpenting - selama proses pencadangan berulang - digunakan kembali.
Salinan cadangan dalam repositori semacam itu adalah rangkaian komponen bernama yang terhubung satu sama lain, misalnya, berdasarkan berbagai fungsi hash.
Ada beberapa solusi serupa, saya akan fokus pada 3: zbackup, borgbackup dan restic.
Hasil yang diharapkan
Karena semua pelamar memerlukan pembuatan repositori dengan satu atau lain cara, salah satu faktor terpenting adalah memperkirakan ukuran repositori. Idealnya, ukurannya tidak boleh lebih dari 13 GB sesuai dengan metodologi yang diterima, atau bahkan kurang - tergantung pada optimasi yang baik.
Juga sangat diinginkan untuk dapat membuat salinan cadangan file secara langsung, tanpa menggunakan pengarsip seperti tar, serta bekerja dengan ssh/sftp tanpa alat tambahan seperti rsync dan sshfs.
Perilaku saat membuat cadangan:
- Ukuran repositori akan sama dengan ukuran perubahannya, atau lebih kecil.
- Beban CPU yang berat diperkirakan terjadi saat menggunakan kompresi dan/atau enkripsi, dan beban jaringan dan disk yang cukup tinggi mungkin terjadi jika proses pengarsipan dan/atau enkripsi dijalankan di server penyimpanan cadangan.
- Jika repositori rusak, kemungkinan besar terjadi kesalahan tertunda baik saat membuat cadangan baru maupun saat mencoba memulihkan. Penting untuk merencanakan tindakan tambahan untuk memastikan integritas repositori atau menggunakan alat bawaan untuk memeriksa integritasnya.
Bekerja dengan tar diambil sebagai nilai referensi, seperti yang ditunjukkan di salah satu artikel sebelumnya.
Menguji zbackup
Mekanisme umum zbackup adalah program menemukan area aliran data input yang berisi data yang sama, kemudian secara opsional mengompresi dan mengenkripsinya, menyimpan setiap area hanya sekali.
Deduplikasi menggunakan fungsi hash ring 64-bit dengan jendela geser untuk memeriksa kecocokan byte demi byte dengan blok data yang ada (mirip dengan cara rsync mengimplementasikannya).
lzma dan lzo multi-utas digunakan untuk kompresi, dan aes untuk enkripsi. Versi terbaru memiliki kemampuan untuk menghapus data lama dari repositori di masa mendatang.
Program ini ditulis dalam C++ dengan ketergantungan minimal. Penulis rupanya terinspirasi oleh cara unix, sehingga program menerima data di stdin saat membuat cadangan, menghasilkan aliran data serupa di stdout saat memulihkan. Dengan demikian, zbackup dapat digunakan sebagai βblok penyusunβ yang sangat baik saat menulis solusi pencadangan Anda sendiri. Misalnya, penulis artikel telah menggunakan program ini sebagai alat cadangan utama untuk mesin rumahan sejak sekitar tahun 2014.
Aliran data akan menjadi tar biasa kecuali dinyatakan lain.
Mari kita lihat apa hasilnya:
Pekerjaan diperiksa dalam 2 pilihan:
- repositori dibuat dan zbackup diluncurkan di server dengan data sumber, kemudian konten repositori ditransfer ke server penyimpanan cadangan.
- repositori dibuat di server penyimpanan cadangan, zbackup diluncurkan melalui ssh di server penyimpanan cadangan, dan data dikirim ke sana melalui pipa.
Hasil dari opsi pertama adalah sebagai berikut: 43m11s - saat menggunakan repositori tidak terenkripsi dan kompresor lzma, 19m13s - saat mengganti kompresor dengan lzo.
Pemuatan di server dengan data asli adalah sebagai berikut (contoh dengan lzma ditampilkan; dengan lzo gambarnya kira-kira sama, tetapi bagian rsync sekitar seperempat dari waktu):
Jelas bahwa proses pencadangan seperti itu hanya cocok untuk perubahan yang relatif jarang dan kecil. Juga sangat disarankan untuk membatasi zbackup ke 1 thread, jika tidak maka akan ada beban CPU yang sangat tinggi, karena Program ini sangat baik dalam bekerja di banyak thread. Beban pada disk kecil, yang secara umum tidak akan terlihat dengan subsistem disk modern berbasis SSD. Anda juga dapat dengan jelas melihat dimulainya proses sinkronisasi data repositori ke server jarak jauh; kecepatan operasinya sebanding dengan rsync biasa dan bergantung pada kinerja subsistem disk dari server penyimpanan cadangan. Kerugian dari pendekatan ini adalah penyimpanan repositori lokal dan, sebagai akibatnya, duplikasi data.
Yang lebih menarik dan dapat diterapkan dalam praktiknya adalah opsi kedua, menjalankan zbackup langsung di server penyimpanan cadangan.
Pertama, kami akan menguji operasi tanpa menggunakan enkripsi dengan kompresor lzma:
Waktu berjalan dari setiap uji coba:
Luncurkan 1
Luncurkan 2
Luncurkan 3
39m45 detik
40m20 detik
40m3 detik
7m36 detik
8m3 detik
7m48 detik
15m35 detik
15m48 detik
15m38 detik
Jika Anda mengaktifkan enkripsi menggunakan aes, hasilnya cukup mirip:
Waktu pengoperasian pada data yang sama, dengan enkripsi:
Luncurkan 1
Luncurkan 2
Luncurkan 3
43m40 detik
44m12 detik
44m3 detik
8m3 detik
8m15 detik
8m12 detik
15m0 detik
15m40 detik
15m25 detik
Jika enkripsi digabungkan dengan kompresi menggunakan lzo, tampilannya seperti ini:
jam:
Luncurkan 1
Luncurkan 2
Luncurkan 3
18m2 detik
18m15 detik
18m12 detik
5m13 detik
5m24 detik
5m20 detik
8m48 detik
9m3 detik
8m51 detik
Ukuran repositori yang dihasilkan pun relatif sama yaitu 13GB. Ini berarti deduplikasi berfungsi dengan benar. Selain itu, pada data yang sudah dikompresi, penggunaan lzo memberikan efek yang nyata; dalam hal total waktu pengoperasian, zbackup mendekati duplikasi/duplikasi, tetapi tertinggal 2-5 kali lipat dari yang berbasis librsync.
Keuntungannya jelas - menghemat ruang disk di server penyimpanan cadangan. Sedangkan untuk alat pemeriksaan repositori, pembuat zbackup tidak menyediakannya; disarankan untuk menggunakan array disk atau penyedia cloud yang toleran terhadap kesalahan.
Secara keseluruhan, kesan yang sangat baik, meskipun proyek ini telah berdiri selama sekitar 3 tahun (permintaan fitur terakhir adalah sekitar setahun yang lalu, tetapi tidak ada tanggapan).
Menguji cadangan borg
Borgbackup adalah cabang dari loteng, sistem lain yang mirip dengan zbackup. Ditulis dengan python, ia memiliki daftar kemampuan yang mirip dengan zbackup, namun selain itu dapat:
- Pasang cadangan melalui sekering
- Periksa isi repositori
- Bekerja dalam mode klien-server
- Gunakan berbagai kompresor untuk data, serta penentuan heuristik jenis file saat mengompresinya.
- 2 opsi enkripsi, AES dan Blake
- Alat bawaan untuk
pemeriksaan kinerja
patokan borgbackup mentah ssh://backup_server/repo/path local_dir
Hasilnya adalah sebagai berikut:
CZ-BESAR 96.51 MB/dtk (10 100.00 MB file semuanya nol: 10.36 detik)
RZ-BESAR 57.22 MB/dtk (10 100.00 MB file semuanya nol: 17.48 detik)
UZ-BESAR 253.63 MB/dtk (10 100.00 MB file semuanya nol: 3.94 detik)
DZ-BESAR 351.06 MB/dtk (10 100.00 MB file semuanya nol: 2.85 detik)
CR-BESAR 34.30 MB/dtk (10 100.00 MB file acak: 29.15 detik)
RR-BESAR 60.69 MB/dtk (10 100.00 MB file acak: 16.48 detik)
UR-BESAR 311.06 MB/s (10 100.00 MB file acak: 3.21 detik)
DR-BESAR 72.63 MB/dtk (10 100.00 MB file acak: 13.77 detik)
CZ-MEDIUM 108.59 MB/dtk (1000 1.00 MB file semuanya nol: 9.21 detik)
RZ-MEDIUM 76.16 MB/dtk (1000 1.00 MB file semuanya nol: 13.13 detik)
UZ-MEDIUM 331.27 MB/dtk (1000 1.00 MB file semuanya nol: 3.02 detik)
DZ-MEDIUM 387.36 MB/dtk (1000 1.00 MB file semuanya nol: 2.58 detik)
CR-MEDIUM 37.80 MB/dtk (1000 1.00 MB file acak: 26.45 detik)
RR-SEDANG 68.90 MB/dtk (1000 1.00 MB file acak: 14.51 detik)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB file acak: 2.88 detik)
DR-MEDIUM 48.80 MB/dtk (1000 1.00 MB file acak: 20.49 detik)
CZ-Kecil 11.72 MB/dtk (10000 File semua-nol 10.00 kB: 8.53 detik)
RZ-Kecil 32.57 MB/dtk (10000 File semua-nol 10.00 kB: 3.07 detik)
UZ-Kecil 19.37 MB/dtk (10000 File semua-nol 10.00 kB: 5.16 detik)
DZ-Kecil 33.71 MB/s (10000 File semua-nol 10.00 kB: 2.97 detik)
CR-Kecil 6.85 MB/dtk (10000 File acak 10.00 kB: 14.60 detik)
RR-Kecil 31.27 MB/dtk (10000 File acak 10.00 kB: 3.20 detik)
UR-KECIL 12.28 MB/s (10000 File acak 10.00 kB: 8.14 detik)
DR-Kecil 18.78 MB/dtk (10000 File acak 10.00 kB: 5.32 detik)
Saat pengujian, heuristik kompresi akan digunakan untuk menentukan jenis file (kompresi otomatis), dan hasilnya adalah sebagai berikut:
Pertama, mari kita periksa cara kerjanya tanpa enkripsi:
jam:
Luncurkan 1
Luncurkan 2
Luncurkan 3
4m6 detik
4m10 detik
4m5 detik
56s
58s
54s
1m26 detik
1m34 detik
1m30 detik
Jika Anda mengaktifkan otorisasi repositori (mode terotentikasi), hasilnya akan mendekati:
jam:
Luncurkan 1
Luncurkan 2
Luncurkan 3
4m11 detik
4m20 detik
4m12 detik
1m0 detik
1m3 detik
1m2 detik
1m30 detik
1m34 detik
1m31 detik
Ketika enkripsi aes diaktifkan, hasilnya tidak banyak menurun:
Luncurkan 1
Luncurkan 2
Luncurkan 3
4m55 detik
5m2 detik
4m58 detik
1m0 detik
1m2 detik
1m0 detik
1m49 detik
1m50 detik
1m50 detik
Dan jika Anda mengubah aes menjadi blake, situasinya akan membaik sepenuhnya:
jam:
Luncurkan 1
Luncurkan 2
Luncurkan 3
4m33 detik
4m43 detik
4m40 detik
59s
1m0 detik
1m0 detik
1m38 detik
1m43 detik
1m40 detik
Seperti halnya zbackup, ukuran repositori adalah 13GB dan bahkan lebih kecil lagi, seperti yang diharapkan secara umum. Saya sangat senang dengan waktu berjalannya; ini sebanding dengan solusi berdasarkan librsync, memberikan kemampuan yang jauh lebih luas. Saya juga senang dengan kemampuan untuk mengatur berbagai parameter melalui variabel lingkungan, yang memberikan keuntungan yang sangat serius saat menggunakan borgbackup dalam mode otomatis. Saya juga senang dengan beban selama pencadangan: dilihat dari beban prosesor, borgbackup berfungsi dalam 1 thread.
Tidak ada kerugian khusus saat menggunakannya.
pengujian istirahat
Terlepas dari kenyataan bahwa restic adalah solusi yang cukup baru (2 kandidat pertama dikenal pada tahun 2013 ke atas), namun memiliki karakteristik yang cukup baik. Ditulis dalam Pergi.
Jika dibandingkan dengan zbackup, ini juga memberikan:
- Memeriksa integritas repositori (termasuk memeriksa bagian-bagiannya).
- Daftar besar protokol dan penyedia yang didukung untuk menyimpan cadangan, serta dukungan untuk rclone - rsync untuk solusi cloud.
- Membandingkan 2 cadangan satu sama lain.
- Memasang repositori melalui sekering.
Secara umum, daftar fiturnya cukup mirip dengan borgbackup, di beberapa tempat lebih banyak, di tempat lain lebih sedikit. Salah satu fiturnya adalah tidak ada cara untuk menonaktifkan enkripsi, sehingga salinan cadangan akan selalu dienkripsi. Mari kita lihat dalam praktiknya apa yang dapat diperoleh dari perangkat lunak ini:
Hasilnya adalah sebagai berikut:
jam:
Luncurkan 1
Luncurkan 2
Luncurkan 3
5m25 detik
5m50 detik
5m38 detik
35s
38s
36s
1m54 detik
2m2 detik
1m58 detik
Hasil kinerjanya juga sebanding dengan solusi berbasis rsync dan, secara umum, sangat mirip dengan borgbackup, tetapi beban CPU lebih tinggi (beberapa thread berjalan) dan gigi gergaji.
Kemungkinan besar, program ini dibatasi oleh kinerja subsistem disk di server penyimpanan data, seperti yang telah terjadi pada rsync. Ukuran repositori adalah 13GB, sama seperti zbackup atau borgbackup, tidak ada kerugian yang jelas saat menggunakan solusi ini.
Temuan
Faktanya, semua kandidat mencapai hasil yang sama, namun dengan harga yang berbeda. Borgbackup memiliki performa terbaik, restic sedikit lebih lambat, zbackup mungkin tidak layak untuk mulai digunakan,
dan jika sudah terpakai coba ganti ke borgbackup atau restic.
Temuan
Solusi yang paling menjanjikan nampaknya bersifat diam, karena... dialah yang memiliki rasio kemampuan dan kecepatan pengoperasian terbaik, namun jangan terburu-buru mengambil kesimpulan umum untuk saat ini.
Borgbackup pada dasarnya tidak lebih buruk, tetapi zbackup mungkin lebih baik diganti. Benar, zbackup masih dapat digunakan untuk memastikan aturan 3-2-1 berfungsi. Misalnya saja, selain fasilitas backup berbasis (lib)rsync.
Pengumuman
Cadangan Bagian 5: Menguji cadangan bacula dan veeam untuk linux
Cadangan Bagian 6: Membandingkan Alat Cadangan
Cadangan Bagian 7: Kesimpulan
Diposting oleh: Pavel Demkovich
Sumber: www.habr.com