Catatan ini membahas alat pencadangan yang melakukan pencadangan dengan membuat arsip di server pencadangan.
Di antara yang memenuhi syarat adalah duplicity (yang memiliki antarmuka bagus berupa deja dup) dan duplicati.
Alat pencadangan lain yang sangat luar biasa adalah dar, tetapi karena alat ini memiliki daftar opsi yang sangat luas - metodologi pengujian hanya mencakup 10% dari kemampuannya - kami tidak mengujinya sebagai bagian dari siklus saat ini.
Hasil yang diharapkan
Karena kedua kandidat membuat arsip dengan satu atau lain cara, tar biasa dapat digunakan sebagai panduan.
Selain itu, kami akan mengevaluasi seberapa baik penyimpanan data di server penyimpanan dioptimalkan dengan membuat salinan cadangan yang hanya berisi perbedaan antara salinan lengkap dan status file saat ini, atau antara arsip sebelumnya dan arsip saat ini (inkremental, dekremental, dll.) .
Perilaku saat membuat cadangan:
- Jumlah file yang relatif kecil di server penyimpanan cadangan (sebanding dengan jumlah salinan cadangan atau ukuran data dalam GB), namun ukurannya cukup besar (puluhan hingga ratusan megabita).
- Ukuran repositori hanya akan mencakup perubahan - tidak ada duplikat yang akan disimpan, sehingga ukuran repositori akan lebih kecil dibandingkan dengan perangkat lunak berbasis rsync.
- Harapkan beban CPU yang berat saat menggunakan kompresi dan/atau enkripsi, dan kemungkinan beban jaringan dan disk yang cukup tinggi jika proses pengarsipan dan/atau enkripsi berjalan di server penyimpanan cadangan.
Mari jalankan perintah berikut sebagai nilai referensi:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Hasil eksekusinya adalah sebagai berikut:
Waktu eksekusi 3m12s. Dapat dilihat bahwa kecepatannya dibatasi oleh subsistem disk dari server penyimpanan cadangan, seperti pada contoh dengan . Hanya sedikit lebih cepat, karena... rekaman masuk ke satu file.
Selain itu, untuk mengevaluasi kompresi, mari jalankan opsi yang sama, namun aktifkan kompresi di sisi server cadangan:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Hasilnya adalah:
Waktu eksekusi 10m11s. Kemungkinan besar hambatannya adalah kompresor aliran tunggal di sisi penerima.
Perintah yang sama, tetapi dengan kompresi ditransfer ke server dengan data asli untuk menguji hipotesis bahwa hambatannya adalah kompresor berulir tunggal.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Ternyata seperti ini:
Waktu eksekusi adalah 9m37s. Beban pada satu inti kompresor terlihat jelas, karena Kecepatan transfer jaringan dan beban pada subsistem disk sumber serupa.
Untuk mengevaluasi enkripsi, Anda dapat menggunakan openssl atau gpg dengan menghubungkan perintah tambahan openssl ΠΈΠ»ΠΈ gpg dalam pipa. Sebagai referensi akan ada perintah seperti ini:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Hasilnya seperti ini:
Waktu eksekusi ternyata 10 menit 30 detik, karena 2 proses berjalan di sisi penerima - hambatannya lagi-lagi adalah kompresor berulir tunggal, ditambah overhead enkripsi yang kecil.
UPD: Atas permintaan bliznezz saya menambahkan tes dengan pigz. Jika Anda hanya menggunakan kompresor, dibutuhkan waktu 6m30s, jika Anda juga menambahkan enkripsi, akan memakan waktu sekitar 7m. Penurunan pada grafik di bawah adalah cache disk yang tidak dibersihkan:
Pengujian duplikat
Duplicity adalah software python untuk backup dengan membuat arsip terenkripsi dalam format tar.
Untuk arsip tambahan, librsync digunakan, sehingga Anda dapat mengharapkan perilaku yang dijelaskan dalam .
Cadangan dapat dienkripsi dan ditandatangani menggunakan gnupg, yang penting ketika menggunakan penyedia berbeda untuk menyimpan cadangan (s3, backblaze, gdrive, dll.)
Mari kita lihat apa hasilnya:
Ini adalah hasil yang kami dapatkan saat menjalankan tanpa enkripsi
bocoran
Waktu berjalan dari setiap uji coba:
Luncurkan 1
Luncurkan 2
Luncurkan 3
16m33 detik
17m20 detik
16m30 detik
8m29 detik
9m3 detik
8m45 detik
5m21 detik
6m04 detik
5m53 detik
Dan berikut hasilnya ketika enkripsi gnupg diaktifkan, dengan ukuran kunci 2048 bit:
Waktu pengoperasian pada data yang sama, dengan enkripsi:
Luncurkan 1
Luncurkan 2
Luncurkan 3
17m22 detik
17m32 detik
17m28 detik
8m52 detik
9m13 detik
9m3 detik
5m48 detik
5m40 detik
5m30 detik
Ukuran blok ditunjukkan - 512 megabyte, yang terlihat jelas dalam grafik; Beban prosesor sebenarnya tetap pada 50%, yang berarti program ini menggunakan tidak lebih dari satu inti prosesor.
Prinsip pengoperasian program ini juga terlihat cukup jelas: mereka mengambil sebagian data, mengompresnya, dan mengirimkannya ke server penyimpanan cadangan, yang bisa jadi sangat lambat.
Fitur lainnya adalah waktu berjalan program yang dapat diprediksi, yang hanya bergantung pada ukuran data yang diubah.
Mengaktifkan enkripsi tidak meningkatkan waktu berjalan program secara signifikan, namun meningkatkan beban prosesor sekitar 10%, yang bisa menjadi bonus yang cukup bagus.
Sayangnya, program ini tidak dapat mendeteksi dengan benar situasi penggantian nama direktori, dan ukuran repositori yang dihasilkan ternyata sama dengan ukuran perubahan (yaitu, semuanya 18GB), tetapi kemampuan untuk menggunakan server yang tidak tepercaya untuk cadangan jelas mencakup perilaku ini.
Pengujian duplikat
Perangkat lunak ini ditulis dalam C# dan dijalankan menggunakan sekumpulan perpustakaan dari Mono. Ada versi GUI dan CLI.
Daftar perkiraan fitur utama mirip dengan duplikat, termasuk berbagai penyedia penyimpanan cadangan, namun, tidak seperti duplikat, sebagian besar fitur tersedia tanpa alat pihak ketiga. Apakah ini plus atau minus tergantung pada kasus spesifiknya, tetapi untuk pemula, kemungkinan besar lebih mudah untuk memiliki daftar semua fitur di depannya sekaligus, daripada harus menginstal paket tambahan untuk python, seperti apa adanya. kasus ini bermuka dua.
Nuansa kecil lainnya - program ini secara aktif menulis database sqlite lokal atas nama pengguna yang memulai pencadangan, jadi Anda juga perlu memastikan bahwa database yang diperlukan ditentukan dengan benar setiap kali proses dimulai menggunakan cli. Saat bekerja melalui GUI atau WEBGUI, detailnya akan disembunyikan dari pengguna.
Mari kita lihat indikator apa yang dapat dihasilkan oleh solusi ini:
Jika Anda mematikan enkripsi (dan WEBGUI tidak menyarankan melakukan hal ini), hasilnya adalah sebagai berikut:
jam:
Luncurkan 1
Luncurkan 2
Luncurkan 3
20m43 detik
20m13 detik
20m28 detik
5m21 detik
5m40 detik
5m35 detik
7m36 detik
7m54 detik
7m49 detik
Dengan enkripsi diaktifkan, menggunakan aes, tampilannya seperti ini:
jam:
Luncurkan 1
Luncurkan 2
Luncurkan 3
29m9 detik
30m1 detik
29m54 detik
5m29 detik
6m2 detik
5m54 detik
8m44 detik
9m12 detik
9m1 detik
Dan jika menggunakan program eksternal gnupg maka akan keluar hasil sebagai berikut:
Luncurkan 1
Luncurkan 2
Luncurkan 3
26m6 detik
26m35 detik
26m17 detik
5m20 detik
5m48 detik
5m40 detik
8m12 detik
8m42 detik
8m15 detik
Seperti yang Anda lihat, program ini dapat bekerja di beberapa thread, tetapi ini tidak menjadikannya solusi yang lebih produktif, dan jika Anda membandingkan pekerjaan enkripsi, program eksternal akan diluncurkan.
ternyata lebih cepat dibandingkan menggunakan perpustakaan dari set Mono. Hal ini mungkin disebabkan oleh fakta bahwa program eksternal lebih optimal.
Hal menyenangkan lainnya adalah kenyataan bahwa ukuran repositori sama persis dengan data aktual yang diubah, yaitu. duplicati mendeteksi penggantian nama direktori dan menangani situasi ini dengan benar. Hal ini terlihat saat menjalankan pengujian kedua.
Secara keseluruhan, kesan program ini cukup positif, termasuk cukup ramah terhadap pemula.
Temuan
Kedua kandidat bekerja agak lambat, namun secara umum dibandingkan tar biasa, ada kemajuan, setidaknya dengan duplikat. Harga dari kemajuan tersebut juga jelas - sebuah beban yang nyata
prosesor. Secara umum, tidak ada penyimpangan khusus dalam memprediksi hasil.
Temuan
Jika Anda tidak perlu terburu-buru ke mana pun, dan juga memiliki prosesor cadangan, salah satu solusi yang dipertimbangkan akan berhasil, dalam hal apa pun, cukup banyak pekerjaan yang telah dilakukan yang tidak boleh diulangi dengan menulis skrip pembungkus di atas tar . Kehadiran enkripsi merupakan properti yang sangat diperlukan jika server untuk menyimpan salinan cadangan tidak dapat dipercaya sepenuhnya.
Dibandingkan dengan solusi berbasis - kinerjanya bisa beberapa kali lebih buruk, meskipun tar dalam bentuknya yang murni bekerja 20-30% lebih cepat daripada rsync.
Ada penghematan pada ukuran repositori, tetapi hanya dengan duplikat.
Pengumuman
Cadangan Bagian 3: Meninjau dan menguji duplikat, duplikat, deja dup
Cadangan Bagian 4: Meninjau dan menguji zbackup, restic, borgbackup
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