Cadangan, Bagian 6: Membandingkan Alat Cadangan

Artikel ini akan membandingkan alat cadangan, tetapi pertama-tama Anda perlu mengetahui cara mereka dengan cepat dan baik memulihkan data dari cadangan.
Untuk memudahkan perbandingan, pemulihan dari cadangan penuh akan dipertimbangkan, terutama karena semua kandidat mendukung mode operasi ini. Untuk kesederhanaan, jumlahnya sudah rata-rata (rata-rata aritmatika beberapa awal). Hasilnya akan dirangkum dalam sebuah tabel, yang juga akan berisi informasi tentang fitur-fitur: keberadaan antarmuka web, kemudahan pengaturan dan operasi, kemampuan untuk mengotomatisasi, kehadiran berbagai fitur tambahan (misalnya, memeriksa integritas data), dll. Grafik akan menunjukkan beban server, tempat data akan digunakan (bukan server untuk menyimpan cadangan).

Pemulihan data

Rsync dan tar akan digunakan sebagai titik referensi, karena di sinilah biasanya skrip cadangan paling sederhana didasarkan .

Rsync menyelesaikan set data uji dalam 4 menit dan 28 detik dengan menunjukkan


Proses pemulihan mengalami keterbatasan subsistem disk dari server penyimpanan cadangan (grafis gigi gergaji). Anda juga dapat dengan jelas melihat pemuatan satu inti 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, mereka akan memiliki kira-kira profil beban yang sama dan waktu pemulihan cadangan.

Tar ditangani sedikit lebih cepat


Beban sistem penuh lebih tinggi dengan rata-rata 20% karena peningkatan softirq - peningkatan overhead selama pengoperasian subsistem jaringan.

Jika arsip dikompresi tambahan, waktu pemulihan meningkat menjadi 3 menit 19 detik dengan

Proses membongkar menempati kedua inti prosesor, karena dua proses bekerja. Secara umum, hasil yang diharapkan. Juga, hasil yang sebanding (3 menit dan 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).

Di rdiff-backup, Anda dapat menyinkronkan cadangan terakhir yang dibuat menggunakan rsync biasa (hasilnya akan serupa), tetapi cadangan yang lebih lama masih harus dipulihkan menggunakan program cadangan rdiff, yang berhasil memulihkan dalam 17 menit dan 17 detik, menunjukkan


Mungkin ini sudah direncanakan, dalam hal apa pun, penulis mengusulkan solusi semacam itu untuk membatasi kecepatan. Proses memulihkan cadangan membutuhkan waktu kurang dari setengah dari satu inti, dengan kinerja yang sebanding secara proporsional (mis., 2-5 kali lebih lambat) pada disk dan jaringan dengan rsync.

Rsnapshot untuk pemulihan menyarankan menggunakan rsync biasa, sehingga hasilnya akan serupa. Secara umum, itulah yang terjadi.

Bersendawa diatasi dengan tugas mengembalikan cadangan dalam 7 menit dan 2 detik dengan

Ini bekerja cukup cepat, dan setidaknya jauh lebih nyaman daripada rsync murni: Anda tidak perlu mengingat bendera apa pun, sebuah antarmuka cli-interface yang sederhana dan intuitif, dukungan bawaan untuk banyak salinan - benar dua kali lebih lambat. Jika Anda perlu mengembalikan data dari cadangan terakhir yang dibuat, Anda dapat menggunakan rsync, dengan beberapa peringatan.

BackupPC menunjukkan kecepatan dan pemuatan yang sama ketika mengaktifkan mode transfer rsync dengan menggunakan cadangan untuk


Tetapi dalam mode transfer data dengan tar BackupPC diatasi lebih lambat: dalam 12 menit dan 15 detik, beban prosesor umumnya lebih rendah


Duplikasi tanpa enkripsi menunjukkan hasil yang sedikit lebih baik, setelah berhasil memulihkan cadangan dalam 10 menit dan 58 detik. Jika Anda mengaktifkan enkripsi menggunakan gpg - waktu pemulihan meningkat menjadi 15 menit dan 3 detik. Juga, saat membuat repositori untuk menyimpan salinan, Anda dapat menentukan ukuran arsip, yang akan digunakan saat memisahkan aliran data yang masuk. Secara umum, pada hard drive biasa, juga karena mode operasi single-threaded, tidak ada banyak perbedaan. Ini mungkin muncul dengan ukuran blok yang berbeda saat menggunakan penyimpanan hybrid. Beban di server utama selama pemulihan adalah sebagai berikut:



Duplicati menunjukkan kecepatan pemulihan yang sebanding, bertahan dalam 13 menit dan 45 detik. 5 menit lainnya mengambil verifikasi kebenaran data yang dipulihkan (total sekitar 19 menit). Bebannya adalah


Ketika enkripsi aes diaktifkan secara internal, waktu pemulihan adalah 21 menit dan 40 detik, dan beban prosesor maksimum (kedua inti!) Selama pemulihan; saat memeriksa data, hanya satu utas yang aktif, menempati satu inti prosesor. Verifikasi data setelah pemulihan berlangsung 5 menit yang sama (totalnya hampir 27 menit).


Duplicati menangani pemulihan sedikit lebih cepat ketika menggunakan program gpg eksternal untuk enkripsi, tetapi secara umum perbedaan dari mode sebelumnya minimal. Waktu operasi adalah 16 menit 30 detik, dengan verifikasi data dalam 6 menit. Bebannya adalah


AMANDA , menggunakan tar, dikelola dalam 2 menit 49 detik, yang, pada prinsipnya, sangat dekat dengan tar biasa. Beban sistem pada prinsipnya


Saat mengembalikan cadangan menggunakan zbackup , hasil berikut diperoleh:




Semua dalam semua, tidak buruk. Semuanya tergantung pada kecepatan prosesor di server cadangan, yang cukup jelas terlihat pada saat program berjalan dengan kompresor yang berbeda. Dari sisi server cadangan, tar biasa diluncurkan, jadi jika Anda membandingkannya, pemulihan berfungsi 3 kali lebih lambat. Mungkin perlu memeriksa pekerjaan dalam mode multi-utas, dengan lebih dari dua utas.

BorgBackup dalam mode non-terenkripsi berhasil sedikit lebih lambat daripada tar, dalam 2 menit 45 detik, namun, tidak seperti tar yang sama, menjadi mungkin untuk menduplikat repositori. Beban pada saat yang sama ternyata


Jika Anda mengaktifkan enkripsi berbasis blake, kecepatan memulihkan cadangan sedikit melambat. Waktu pemulihan dalam mode ini adalah 3 menit 19 detik, dan beban dilepaskan


Enkripsi AES bekerja sedikit lebih lambat, waktu pemulihan 3 menit 23 detik, terutama memuat


Karena Borg dapat bekerja dalam mode multi-utas - beban prosesor maksimum, sementara ketika Anda mengaktifkan fungsi tambahan, waktu pengoperasian meningkat. Tampaknya, ada baiknya mengeksplorasi pekerjaan multithreading yang mirip dengan zbackup.

Restic diatasi dengan pemulihan sedikit lebih lambat, waktu operasi adalah 4 menit 28 detik. Beban tampak


Tampaknya, proses pemulihan bekerja di beberapa utas, tetapi efisiensinya tidak setinggi BorgBackup, tetapi sebanding dengan waktu pada rsync yang biasa.

Dengan menggunakan UrBackup, saya dapat memulihkan data dalam 8 menit dan 19 detik, sementara bebannya


Masih beban yang tidak terlalu tinggi terlihat, bahkan lebih rendah dari tar. Di beberapa tempat, semburan, tetapi tidak lebih dari memuat satu inti.

Seleksi dan justifikasi kriteria untuk perbandingan

Seperti disebutkan dalam artikel sebelumnya, sistem cadangan harus memenuhi kriteria berikut:

• Kesederhanaan dalam bekerja
• Keserbagunaan
• Stabilitas
• Kecepatan

Perlu mempertimbangkan setiap item secara terpisah lebih terinci.

Kesederhanaan kerja

Yang terbaik adalah ketika ada satu tombol "Jadikan semuanya baik", tetapi jika Anda kembali ke program nyata, akan lebih mudah untuk memiliki beberapa prinsip operasi yang akrab dan standar.
Sebagian besar pengguna kemungkinan besar akan lebih baik jika mereka tidak perlu menghafal banyak kunci untuk klien, mengkonfigurasi banyak pilihan yang berbeda, seringkali tidak jelas melalui web atau internet, dan mengatur peringatan tentang kegagalan operasi. Ini juga mencakup kemampuan untuk dengan mudah "memasukkan" solusi cadangan ke dalam infrastruktur yang ada, serta mengotomatiskan proses pencadangan. Segera kemampuan untuk menginstal manajer paket, atau dalam satu atau dua perintah dari jenis "unduh dan unzip". curl | sudo bash curl | sudo bash adalah metode yang rumit karena Anda perlu memverifikasi bahwa itu datang dengan referensi.

Misalnya, dari kandidat yang dipertimbangkan, solusi sederhana adalah sendawa, rdiff-backup dan restic, yang secara mnemonically mengingat kunci untuk mode operasi yang berbeda. Sedikit lebih rumit adalah borg dan bermuka dua. Yang paling sulit adalah AMANDA. Sisa kemudahan penggunaan ada di antara keduanya. Bagaimanapun, jika Anda perlu lebih dari 30 detik untuk membaca manual, atau Anda harus pergi ke Google atau mesin pencari lainnya, dan juga menggulir lembar bantuan yang panjang, solusinya rumit, dengan satu atau lain cara.

Beberapa kandidat yang dipertimbangkan dapat secara otomatis mengirim pesan melalui e-mail \ jabber, sementara yang lain mengandalkan peringatan yang dikonfigurasi dalam sistem. Selain itu, keputusan yang paling kompleks seringkali tidak memiliki pengaturan pemberitahuan yang jelas. Dalam kasus apa pun, jika program cadangan memberikan kode pengembalian tidak nol, yang akan dipahami dengan benar oleh layanan sistem tugas berkala (pesan akan terbang ke administrator sistem atau langsung ke pemantauan) - situasinya sederhana. Tetapi jika sistem cadangan, yang tidak berfungsi pada server cadangan, tidak dapat diatur dengan cara yang jelas, kerumitannya sudah berlebihan. Dalam hal apa pun, mengeluarkan peringatan dan pesan lain hanya ke antarmuka web dan / atau ke log adalah praktik yang buruk, karena seringkali akan diabaikan.

Adapun otomatisasi, program sederhana dapat membaca variabel lingkungan yang menentukan mode operasinya, atau memiliki cli yang dikembangkan yang dapat sepenuhnya menduplikasi perilaku ketika bekerja melalui antarmuka web, misalnya. Ini juga mencakup kemungkinan kerja berkelanjutan, ketersediaan peluang untuk ekspansi, dll.

Keserbagunaan

Sebagian menggaungkan subbagian sebelumnya dalam hal otomatisasi, seharusnya tidak menjadi masalah khusus untuk "menyesuaikan" proses pencadangan ke dalam infrastruktur yang ada.
Perlu dicatat bahwa penggunaan port non-standar (baik, kecuali untuk antarmuka web) untuk bekerja, implementasi enkripsi dengan cara non-standar, pertukaran data dengan protokol non-standar adalah tanda-tanda solusi non-universal. Sebagian besar, semua kandidat memiliki satu atau lain cara karena alasan yang jelas: kesederhanaan dan fleksibilitas biasanya tidak cocok. Bersendawa adalah pengecualian, ada yang lain.

Sebagai tanda - kemampuan bekerja menggunakan ssh biasa.

Kecepatan kerja

Poin paling kontroversial dan kontroversial. Di satu sisi, mereka memulai proses, itu bekerja secepat mungkin dan tidak mengganggu tugas-tugas utama. Di sisi lain, ada lonjakan lalu lintas dan beban CPU selama pencadangan. Perlu juga dicatat bahwa program penyalinan tercepat biasanya yang paling buruk dalam fitur yang penting bagi pengguna. Sekali lagi: jika untuk mendapatkan satu file teks malang ukuran beberapa puluh byte dengan kata sandi, dan karena itu seluruh biaya layanan (ya, saya mengerti bahwa di sini proses pencadangan paling sering tidak bersalah), dan Anda perlu membaca kembali secara berurutan semua file dalam repositori atau menyebarkan seluruh arsip - sistem cadangan tidak pernah cepat. Poin lain yang sering menjadi batu sandungan adalah kecepatan penggelaran cadangan dari arsip. Ada keuntungan yang jelas bagi mereka yang hanya dapat menyalin atau memindahkan file ke tempat yang tepat tanpa manipulasi khusus (misalnya rsync), tetapi paling sering masalah perlu dipecahkan dengan cara organisasi, secara empiris: mengukur waktu pemulihan cadangan dan secara terbuka menginformasikan pengguna tentang hal itu.

Stabilitas

Ini harus dipahami sebagai berikut: di satu sisi, harus mungkin untuk menggunakan cadangan kembali dengan cara apa pun, di sisi lain, resistensi terhadap berbagai masalah: kerusakan jaringan, kegagalan disk, menghapus bagian dari repositori.

Perbandingan alat cadangan

Legenda meja:

• Hijau, waktu pengoperasian kurang dari lima menit, atau jawabannya adalah "Ya" (kecuali untuk kolom "Butuh klien \ server?"), 1 poin
• Kuning, waktu pengoperasian lima hingga sepuluh menit, 0,5 poin
• Merah, waktu operasi lebih dari sepuluh menit, atau jawabannya adalah "Tidak" (kecuali untuk kolom "Butuh klien \ server?"), 0 poin

Menurut tabel di atas, alat cadangan yang paling sederhana, cepat, dan pada saat yang sama nyaman dan kuat adalah BorgBackup. Restic mengambil tempat kedua, sisanya dari kandidat yang dipertimbangkan ditempatkan kira-kira sama dengan sebaran satu atau dua poin di akhir.

Saya berterima kasih kepada semua orang yang membaca siklus sampai akhir, saya sarankan mendiskusikan opsi, menyarankan Anda sendiri, jika ada. Saat diskusi berlangsung, tabel dapat ditambahkan.

Hasil siklus akan menjadi artikel terakhir, di mana akan ada upaya untuk mengeluarkan alat cadangan yang ideal, cepat dan mudah dikelola, yang memungkinkan Anda untuk dengan cepat menggunakan salinan kembali dan pada saat yang sama memiliki kemudahan dan kesederhanaan konfigurasi dan pemeliharaan.

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 cadangan bacula dan veeam untuk linux
Cadangan: bagian yang diminta oleh pembaca: ulasan AMANDA, UrBackup, BackupPC
Cadangan, Bagian 6: Membandingkan Alat Cadangan
Cadangan Bagian 7: Kesimpulan