Artikel ini akan membandingkan alat pencadangan, tetapi pertama-tama Anda harus mencari tahu seberapa cepat dan baik alat tersebut mengatasi pemulihan data dari cadangan.
Untuk memudahkan perbandingan, kami akan mempertimbangkan memulihkan dari cadangan penuh, terutama karena semua kandidat mendukung mode operasi ini. Untuk mempermudah, angka-angka tersebut sudah dirata-ratakan (rata-rata aritmatika dari beberapa proses). Hasilnya akan dirangkum dalam sebuah tabel, yang juga berisi informasi tentang kemampuan: keberadaan antarmuka web, kemudahan pengaturan dan pengoperasian, kemampuan otomatisasi, adanya berbagai fitur tambahan (misalnya, pemeriksaan integritas data) , dll. Grafik akan menunjukkan beban pada server tempat data akan digunakan (bukan server untuk menyimpan salinan cadangan).
Pemulihan data
rsync dan tar akan digunakan sebagai titik referensi sejak itu skrip sederhana untuk membuat salinan cadangan.
Rsync diatasi dengan kumpulan data pengujian dalam 4 menit dan 28 detik, ditampilkan
beban seperti itu
Proses pemulihan mengalami keterbatasan subsistem disk dari server penyimpanan cadangan (grafik gigi gergaji). Anda juga dapat dengan jelas melihat pemuatan satu kernel tanpa masalah (iowait rendah dan softirq - masing-masing tidak ada masalah dengan disk dan jaringan). Karena dua program lainnya, yaitu rdiff-backup dan rsnapshot, didasarkan pada rsync dan juga menawarkan rsync biasa sebagai alat pemulihan, keduanya akan memiliki profil beban dan waktu pemulihan cadangan yang kurang lebih sama.
Ter menyelesaikannya sedikit lebih cepat
2 menit 43 detik:
Total beban sistem rata-rata lebih tinggi sebesar 20% karena peningkatan perangkat lunak - biaya overhead selama pengoperasian subsistem jaringan meningkat.
Jika arsip dikompresi lebih lanjut, waktu pemulihan bertambah menjadi 3 menit 19 detik.
dengan beban seperti itu di server utama (membongkar di sisi server utama):
Proses dekompresi memakan kedua inti prosesor karena ada dua proses yang berjalan. Secara umum, ini adalah hasil yang diharapkan. Selain itu, hasil yang sebanding (3 menit 20 detik) diperoleh ketika menjalankan gzip di sisi server dengan cadangan; profil beban di server utama sangat mirip dengan menjalankan tar tanpa kompresor gzip (lihat grafik sebelumnya).
В rdiff-cadangan Anda dapat menyinkronkan cadangan terakhir yang Anda buat menggunakan rsync biasa (hasilnya akan serupa), tetapi cadangan lama masih perlu dipulihkan menggunakan program cadangan rdiff, yang menyelesaikan pemulihan dalam 17 menit 17 detik, menunjukkan
beban ini:
Mungkin ini dimaksudkan, setidaknya untuk membatasi kecepatan penulis . Proses memulihkan salinan cadangan itu sendiri memakan waktu kurang dari setengah dari satu inti, dengan kinerja yang sebanding secara proporsional (yaitu 2-5 kali lebih lambat) melalui disk dan jaringan dengan rsync.
Gambaran singkat Untuk recovery disarankan menggunakan rsync biasa, sehingga hasilnya akan serupa. Secara umum, ternyata begini.
Sendawa Saya menyelesaikan tugas memulihkan cadangan dalam 7 menit 2 detik dengan
dengan beban ini:
Ini bekerja cukup cepat, dan setidaknya jauh lebih nyaman daripada rsync murni: Anda tidak perlu mengingat flag apa pun, antarmuka cli yang sederhana dan intuitif, dukungan bawaan untuk banyak salinan - meskipun dua kali lebih lambat. Jika Anda perlu memulihkan data dari cadangan terakhir yang Anda buat, Anda dapat menggunakan rsync, dengan beberapa peringatan.
Program ini menunjukkan kecepatan dan beban yang kira-kira sama Cadangan PC saat mengaktifkan mode transfer rsync, menyebarkan cadangan untuk
7 menit 42 detik:
Namun dalam mode transfer data, BackupPC mengatasi tar lebih lambat: dalam 12 menit dan 15 detik, beban prosesor secara umum lebih rendah
satu setengah kali:
Sikap bermuka dua tanpa enkripsi menunjukkan hasil yang sedikit lebih baik, memulihkan cadangan dalam 10 menit dan 58 detik. Jika Anda mengaktifkan enkripsi menggunakan gpg, waktu pemulihan bertambah menjadi 15 menit 3 detik. Selain itu, saat membuat repositori untuk menyimpan salinan, Anda dapat menentukan ukuran arsip yang akan digunakan saat memisahkan aliran data masuk. Secara umum, pada hard drive konvensional, juga karena mode operasi single-threaded, tidak banyak perbedaan. Ini mungkin muncul dalam ukuran blok yang berbeda ketika penyimpanan hibrid digunakan. Beban di server utama selama pemulihan adalah sebagai berikut:
tidak ada enkripsi
dengan enkripsi
Duplikat menunjukkan tingkat pemulihan yang sebanding, menyelesaikannya dalam 13 menit dan 45 detik. Diperlukan waktu sekitar 5 menit lagi untuk memeriksa kebenaran data yang dipulihkan (total sekitar 19 menit). Bebannya adalah
cukup tinggi:
Ketika enkripsi aes diaktifkan secara internal, waktu pemulihan adalah 21 menit 40 detik, dengan penggunaan CPU maksimum (kedua inti!) selama pemulihan; Saat memeriksa data, hanya satu thread yang aktif, menempati satu inti prosesor. Memeriksa data setelah pemulihan memakan waktu 5 menit yang sama (total hampir 27 menit).
Hasil
duplicati sedikit lebih cepat dengan pemulihan ketika menggunakan program gpg eksternal untuk enkripsi, namun secara umum perbedaan dari mode sebelumnya minimal. Waktu pengoperasian 16 menit 30 detik, dengan verifikasi data 6 menit. Bebannya adalah
seperti:
AMANDA, menggunakan tar, menyelesaikannya dalam 2 menit 49 detik, yang pada prinsipnya sangat mendekati tar biasa. Beban pada sistem pada prinsipnya
sama:
Saat memulihkan cadangan menggunakan zbackup diperoleh hasil sebagai berikut:
enkripsi, kompresi lzma
Waktu berjalan 11 menit 8 detik
Enkripsi AES, kompresi lzma
Waktu kerja 14 menit
Enkripsi AES, kompresi lzo
Waktu berjalan 6 menit, 19 detik
Secara keseluruhan, lumayan. Itu semua tergantung pada kecepatan prosesor di server cadangan, yang terlihat jelas dari waktu berjalannya program dengan kompresor yang berbeda-beda. Di sisi server cadangan, tar biasa diluncurkan, jadi jika Anda membandingkannya, pemulihannya 3 kali lebih lambat. Mungkin ada baiknya memeriksa operasi dalam mode multi-utas, dengan lebih dari dua utas.
Cadangan Borg dalam mode tidak terenkripsi, ini sedikit lebih lambat daripada tar, dalam 2 menit 45 detik, namun, tidak seperti tar, repositori dapat dihapus duplikatnya. Ternyata bebannya
Berikutnya:
Jika Anda mengaktifkan enkripsi berbasis blake, kecepatan pemulihan cadangan sedikit lebih lambat. Waktu pemulihan dalam mode ini adalah 3 menit 19 detik, dan beban hilang
seperti ini:
Enkripsi AES sedikit lebih lambat, waktu pemulihan 3 menit 23 detik, terutama bebannya
belum berubah:
Karena Borg dapat bekerja dalam mode multi-utas, beban prosesor menjadi maksimal, dan ketika fungsi tambahan diaktifkan, waktu pengoperasian bertambah. Tampaknya, ada baiknya menjelajahi multithreading dengan cara yang mirip dengan zbackup.
Istirahat mengatasi pemulihan sedikit lebih lambat, waktu pengoperasian 4 menit 28 detik. Bebannya tampak seperti itu
sebagai berikut:
Rupanya proses pemulihan bekerja di beberapa thread, tetapi efisiensinya tidak setinggi BorgBackup, tetapi waktunya sebanding dengan rsync biasa.
Dengan urBackup Dimungkinkan untuk memulihkan data dalam 8 menit 19 detik, bebannya besar
seperti:
Bebannya masih belum terlalu tinggi, bahkan lebih rendah dari tar. Di beberapa tempat ada semburan, tapi tidak lebih dari beban satu inti.
Seleksi dan pembenaran kriteria perbandingan
Seperti yang telah disampaikan pada salah satu artikel sebelumnya, sistem backup harus memenuhi kriteria berikut:
- Kemudahan penggunaan
- fleksibilitas
- Stabilitas
- Kecepatan
Ada baiknya mempertimbangkan setiap poin secara terpisah secara lebih rinci.
Kemudahan pengoperasian
Yang terbaik adalah jika ada satu tombol "Lakukan semuanya dengan baik", tetapi jika Anda kembali ke program sebenarnya, hal yang paling nyaman adalah prinsip operasi yang familiar dan standar.
Sebagian besar pengguna kemungkinan besar akan lebih baik jika mereka tidak perlu mengingat sekumpulan kunci untuk cli, mengonfigurasi sekumpulan opsi berbeda yang sering kali tidak jelas melalui web atau tui, atau mengatur pemberitahuan tentang operasi yang gagal. Hal ini juga mencakup kemampuan untuk dengan mudah “menyesuaikan” solusi pencadangan ke dalam infrastruktur yang ada, serta otomatisasi proses pencadangan. Ada juga kemungkinan instalasi menggunakan manajer paket, atau dalam satu atau dua perintah seperti “unduh dan buka paket”. curl ссылка | sudo bash - metode yang rumit, karena Anda perlu memeriksa apa yang masuk melalui tautan.
Misalnya, dari kandidat yang dipertimbangkan, solusi sederhananya adalah sendawa, rdiff-backup, dan restic, yang memiliki kunci mnemonik untuk mode pengoperasian berbeda. Yang sedikit lebih kompleks adalah borg dan duplikatitas. Yang paling sulit adalah AMANDA. Sisanya berada di tengah-tengah dalam hal kemudahan penggunaan. Bagaimanapun, jika Anda memerlukan lebih dari 30 detik untuk membaca panduan pengguna, atau Anda perlu membuka Google atau mesin pencari lainnya, dan juga menelusuri lembar bantuan yang panjang, keputusannya sulit, dengan satu atau lain cara.
Beberapa kandidat yang dipertimbangkan dapat mengirim pesan secara otomatis melalui e-mailjabber, sementara yang lain mengandalkan peringatan yang dikonfigurasi dalam sistem. Selain itu, seringkali solusi kompleks tidak memiliki pengaturan peringatan yang sepenuhnya jelas. Bagaimanapun, jika program pencadangan menghasilkan kode pengembalian bukan nol, yang akan dipahami dengan benar oleh layanan sistem untuk tugas berkala (pesan akan dikirim ke administrator sistem atau langsung ke pemantauan) - situasinya sederhana. Namun jika sistem pencadangan, yang tidak berjalan di server pencadangan, tidak dapat dikonfigurasi, cara yang jelas untuk mengatakan bahwa masalahnya adalah kompleksitasnya sudah berlebihan. Bagaimanapun, mengeluarkan peringatan dan pesan lain hanya ke antarmuka web atau ke log adalah praktik yang buruk, karena sering kali akan diabaikan.
Sedangkan untuk otomatisasi, program sederhana dapat membaca variabel lingkungan yang mengatur mode operasinya, atau memiliki cli yang dikembangkan yang dapat sepenuhnya menduplikasi perilaku saat bekerja melalui antarmuka web, misalnya. Ini juga mencakup kemungkinan operasi berkelanjutan, ketersediaan peluang ekspansi, dll.
fleksibilitas
Sebagian menggemakan sub-bagian sebelumnya mengenai otomatisasi, seharusnya tidak menjadi masalah khusus untuk “menyesuaikan” proses pencadangan ke dalam infrastruktur yang ada.
Perlu dicatat bahwa penggunaan port non-standar (yah, kecuali untuk antarmuka web) untuk bekerja, penerapan enkripsi dengan cara non-standar, pertukaran data menggunakan protokol non-standar adalah tanda-tanda non-standar -solusi universal. Umumnya, semua kandidat memilikinya karena alasan yang jelas: kesederhanaan dan keserbagunaan biasanya tidak berjalan bersamaan. Sebagai pengecualian - bersendawa, ada yang lain.
Sebagai tandanya - kemampuan untuk bekerja menggunakan ssh biasa.
Kecepatan kerja
Poin paling kontroversial dan kontroversial. Di satu sisi, kami meluncurkan prosesnya, bekerja secepat mungkin dan tidak mengganggu tugas pokok. Di sisi lain, terjadi lonjakan lalu lintas dan beban prosesor selama periode pencadangan. Perlu juga dicatat bahwa program tercepat untuk membuat salinan biasanya yang paling buruk dalam hal fungsi yang penting bagi pengguna. Sekali lagi: jika untuk mendapatkan satu file teks malang berukuran beberapa puluh byte dengan kata sandi, dan karena itu seluruh layanan dikenai biaya (ya, ya, saya mengerti bahwa proses pencadangan paling sering tidak bisa disalahkan di sini), dan Anda perlu membaca ulang semua file di repositori secara berurutan atau memperluas seluruh arsip - sistem pencadangan tidak pernah cepat. Hal lain yang sering menjadi batu sandungan adalah kecepatan penerapan cadangan dari arsip. Ada keuntungan yang jelas di sini bagi mereka yang dapat dengan mudah menyalin atau memindahkan file ke lokasi yang diinginkan tanpa banyak manipulasi (rsync, misalnya), tetapi seringkali masalahnya harus diselesaikan dengan cara yang terorganisir, secara empiris: dengan mengukur waktu pemulihan cadangan dan secara terbuka memberi tahu pengguna tentang hal ini.
Stabilitas
Hal ini harus dipahami sebagai berikut: di satu sisi, salinan cadangan harus dapat disebarkan kembali dengan cara apa pun, di sisi lain, salinan tersebut harus tahan terhadap berbagai masalah: gangguan jaringan, kegagalan disk, penghapusan sebagian dari gudang.
Perbandingan alat cadangan
Salin waktu pembuatan
Salin waktu pemulihan
Instalasi mudah
Pengaturan yang mudah
Penggunaan sederhana
Otomatisasi sederhana
Apakah Anda memerlukan server klien?
Memeriksa integritas repositori
Salinan diferensial
Bekerja melalui pipa
fleksibilitas
Kemerdekaan
Transparansi repositori
Enkripsi
Kompresi
Deduplikasi
Antarmuka web
Mengisi ke awan
dukungan Windows
Skor
Rsync
4m15 detik
4m28 detik
ya
tidak
tidak
tidak
ya
tidak
tidak
ya
tidak
ya
ya
tidak
tidak
tidak
tidak
tidak
ya
6
Ter
murni
3m12 detik
2m43 detik
ya
tidak
tidak
tidak
tidak
tidak
ya
ya
tidak
ya
tidak
tidak
tidak
tidak
tidak
tidak
ya
8,5
gzip
9m37 detik
3m19 detik
ya
Cadangan Rdiff
16m26 detik
17m17 detik
ya
ya
ya
ya
ya
tidak
ya
tidak
ya
tidak
ya
tidak
ya
ya
ya
tidak
ya
11
Gambaran singkat
4m19 detik
4m28 detik
ya
ya
ya
ya
tidak
tidak
ya
tidak
ya
tidak
ya
tidak
tidak
ya
ya
tidak
ya
12,5
Sendawa
11m9 detik
7m2 detik
ya
tidak
ya
ya
ya
ya
ya
tidak
ya
ya
tidak
tidak
ya
tidak
ya
tidak
ya
10,5
Sikap bermuka dua
tidak ada enkripsi
16m48 detik
10m58 detik
ya
ya
tidak
ya
tidak
ya
ya
tidak
tidak
ya
tidak
ya
ya
tidak
ya
tidak
ya
11
gpg
17m27 detik
15m3 detik
Duplikat
tidak ada enkripsi
20m28 detik
13m45 detik
tidak
ya
tidak
tidak
tidak
ya
ya
tidak
tidak
ya
tidak
ya
ya
ya
ya
ya
ya
11
aes
29m41 detik
21m40 detik
gpg
26m19 detik
16m30 detik
zbackup
tidak ada enkripsi
40m3 detik
11m8 detik
ya
ya
tidak
tidak
tidak
ya
ya
ya
tidak
ya
tidak
ya
ya
ya
tidak
tidak
tidak
10
aes
42m0 detik
14m1 detik
aes+lzo
18m9 detik
6m19 detik
Cadangan Borg
tidak ada enkripsi
4m7 detik
2m45 detik
ya
ya
ya
ya
ya
ya
ya
ya
ya
ya
tidak
ya
ya
ya
ya
tidak
ya
16
aes
4m58 detik
3m23 detik
blake2
4m39 detik
3m19 detik
Istirahat
5m38 detik
4m28 detik
ya
ya
ya
ya
tidak
ya
ya
ya
ya
ya
tidak
ya
tidak
ya
tidak
ya
ya
15,5
urBackup
8m21 detik
8m19 detik
ya
ya
ya
tidak
ya
tidak
ya
tidak
ya
ya
tidak
ya
ya
ya
ya
tidak
ya
12
Amanda
9m3 detik
2m49 detik
ya
tidak
tidak
ya
ya
ya
ya
tidak
ya
ya
ya
ya
ya
tidak
ya
ya
ya
13
Cadangan PC
rsync
12m22 detik
7m42 detik
ya
tidak
ya
ya
ya
ya
ya
tidak
ya
tidak
tidak
ya
ya
tidak
ya
tidak
ya
10,5
ter
12m34 detik
12m15 detik
Legenda tabel:
- Hijau, waktu pengoperasian kurang dari lima menit, atau jawaban “Ya” (kecuali kolom “Butuh server klien?”), 1 poin
- Kuning, waktu pengoperasian lima hingga sepuluh menit, 0.5 poin
- Merah, waktu kerja lebih dari sepuluh menit, atau jawabannya “Tidak” (kecuali kolom “Apakah Anda memerlukan server klien?”), 0 poin
Berdasarkan tabel di atas, alat pencadangan yang paling sederhana, tercepat, sekaligus nyaman dan kuat adalah BorgBackup. Restic menempati posisi kedua, kandidat lainnya yang dipertimbangkan ditempatkan kira-kira sama dengan selisih satu atau dua poin di akhir.
Saya berterima kasih kepada semua orang yang membaca seri ini sampai akhir, saya mengundang Anda untuk mendiskusikan pilihan dan menawarkan pilihan Anda sendiri, jika ada. Seiring berjalannya diskusi, tabel dapat diperluas.
Hasil dari seri ini akan menjadi artikel terakhir, di mana akan ada upaya untuk mengembangkan alat pencadangan yang ideal, cepat, dan mudah dikelola yang memungkinkan Anda menyebarkan salinan kembali dalam waktu sesingkat mungkin dan pada saat yang sama nyaman dan mudah. untuk mengkonfigurasi dan memelihara.
Pengumuman
Cadangan Bagian 6: Membandingkan Alat Cadangan
Cadangan Bagian 7: Kesimpulan
Sumber: www.habr.com