Cadangan, Bagian 3: Gambaran Umum dan Pengujian duplikasi, dupati

Artikel ini menjelaskan alat cadangan yang membuat cadangan dengan membuat arsip di server cadangan.

Dari mereka yang memenuhi persyaratan adalah duplikat (yang ada antarmuka yang bagus dalam bentuk deja dup) dan duplikat.

Alat cadangan lain yang sangat luar biasa adalah dar, tetapi karena ia memiliki daftar opsi yang sangat luas - metodologi pengujian mencakup hampir 10% dari kemampuannya - kami tidak mengujinya dalam siklus saat ini.

Hasil yang Diharapkan

Karena kedua kandidat membuat arsip dengan satu atau lain cara, Anda dapat menggunakan tar biasa sebagai pedoman.

Selain itu, kami mengevaluasi seberapa baik penyimpanan data pada server penyimpanan dioptimalkan dengan membuat cadangan yang hanya berisi perbedaan antara salinan lengkap dan kondisi file saat ini, atau antara arsip masa lalu dan saat ini (tambahan, pengurangan, dll.).

Perilaku Cadangan:

1. Jumlah file yang relatif kecil pada server penyimpanan cadangan (sebanding dengan jumlah cadangan atau ukuran data dalam GB), tetapi ukurannya cukup besar (puluhan hingga ratusan megabita).
2. Ukuran repositori hanya akan mencakup perubahan - duplikat tidak akan disimpan, sehingga ukuran repositori akan lebih kecil daripada dengan perangkat lunak berbasis rsync.
3. Beban berat pada prosesor diharapkan saat menggunakan kompresi dan / atau enkripsi, dan juga, mungkin, beban yang cukup besar pada subsistem jaringan dan disk jika proses pengarsipan dan / atau enkripsi akan bekerja pada server penyimpanan cadangan.

Sebagai nilai referensi, jalankan perintah berikut:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar" 

Hasil eksekusi adalah sebagai berikut:

Runtime 3m12s. Dapat dilihat bahwa kecepatan terletak pada subsistem disk server penyimpanan cadangan, seperti dalam contoh rsync . Hanya sedikit lebih cepat, karena catatan masuk ke satu file.

Juga, untuk mengevaluasi kompresi, kami akan menjalankan opsi yang sama, tetapi mengaktifkan kompresi di sisi server cadangan:

 cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz" 

Hasilnya adalah sebagai berikut:

Waktu tunggu adalah 10m11s. Kemungkinan besar, bottleneck adalah kompresor berulir tunggal di sisi penerima.

Perintah yang sama, tetapi dengan transfer kompresi ke server dengan sumber data untuk menguji hipotesis bahwa bottleneck adalah kompresor single-threaded.

 cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz" 

Ternyata seperti ini:

Waktu tunggu adalah 9m37s. Beban satu inti oleh kompresor terlihat jelas, seperti kecepatan dan beban transmisi jaringan pada subsistem disk sumber serupa.

Untuk mengevaluasi enkripsi, Anda dapat menggunakan openssl atau gpg dengan menghubungkan perintah openssl atau gpg opsional ke pipa. Untuk referensi, akan ada perintah seperti itu:

 cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc" 

Hasilnya keluar sebagai berikut:

Waktu pelaksanaan ternyata 10m30s, karena 2 proses diluncurkan pada sisi penerima - hambatannya lagi adalah kompresor berulir tunggal, ditambah overhead enkripsi kecil.

UPD: Atas permintaan bliznezz, saya menambahkan tes dengan pigz. Jika Anda hanya menggunakan kompresor - ternyata 6m30s, jika Anda juga menambahkan enkripsi - sekitar 7m. Kegagalan di grafik bawah adalah cache disk yang tidak terisi:

Menguji kepalsuan

Duplicity adalah perangkat lunak cadangan python dengan membuat arsip tar terenkripsi.

Untuk arsip tambahan, librsync digunakan, oleh karena itu, Anda dapat mengharapkan perilaku yang dijelaskan dalam catatan loop sebelumnya .

Cadangan dapat dienkripsi dan ditandatangani menggunakan gnupg, yang penting ketika menggunakan berbagai penyedia untuk menyimpan cadangan (s3, backblaze, gdrive, dll.)

Mari kita lihat hasilnya nanti:

Ukuran blok ditentukan - 512 megabyte, yang terlihat jelas pada grafik; sebenarnya beban prosesor tetap pada level 50%, yang berarti program menggunakan tidak lebih dari satu inti prosesor.

Prinsip kerja dari program ini juga cukup jelas terlihat: mereka mengambil sepotong data, mengocoknya, mengirimkannya ke server penyimpanan cadangan, yang bisa sangat lambat.
Fitur lain adalah runtime yang dapat diprediksi dari program, yang hanya tergantung pada ukuran data yang diubah.

Enkripsi yang diaktifkan tidak secara signifikan meningkatkan runtime program, tetapi meningkatkan beban prosesor sekitar 10%, yang bisa menjadi bonus yang cukup bagus.

Sayangnya, program ini tidak dapat mendeteksi situasi dengan benar dengan penggantian nama direktori, dan ukuran repositori yang dihasilkan ternyata sama dengan ukuran perubahan (mis., Semua 18GB), tetapi kemampuan untuk menggunakan server yang tidak dipercaya untuk cadangan pasti mencakup perilaku ini.

Menguji duplikat

Perangkat lunak ini ditulis dalam C #, diluncurkan menggunakan satu set perpustakaan dari Mono. Ada GUI serta versi cli.

Daftar sampel fitur utama dekat dengan bermuka dua, termasuk berbagai penyedia penyimpanan cadangan, namun, tidak seperti bermuka dua, sebagian besar fitur tersedia tanpa alat pihak ketiga. Plus atau minus - itu tergantung pada kasus spesifik, namun, untuk pemula, kemungkinan besar lebih mudah untuk memiliki daftar semua fitur sekaligus sebelum menginstal paket untuk python, seperti halnya dengan duplikat.

Nuansa kecil lainnya adalah bahwa program secara aktif menulis basis data sqlite lokal atas nama pengguna yang memulai pencadangan, jadi Anda perlu memonitor indikasi yang benar dari basis data yang diinginkan setiap kali proses mulai menggunakan cli. Saat bekerja melalui GUI atau WEBGUI, detailnya akan disembunyikan dari pengguna.

Seperti yang Anda lihat, program ini dapat bekerja di beberapa utas, tetapi ini bukan solusi yang lebih produktif, dan jika Anda membandingkan enkripsi, ia memulai program eksternal
ternyata lebih cepat daripada menggunakan perpustakaan dari Mono suite. Mungkin ini disebabkan oleh fakta bahwa program eksternal lebih dioptimalkan.

Saat yang menyenangkan adalah juga fakta bahwa ukuran repositori memakan waktu persis sama seperti data aktual diubah, mis. dupati mendeteksi penggantian nama direktori dan menangani situasi ini dengan benar. Ini bisa dilihat saat menjalankan tes kedua.

Secara umum, kesan program cukup positif, termasuk keramahan yang cukup untuk pemula.

Hasil

Kedua kandidat bekerja agak lambat, tetapi secara umum, dibandingkan dengan tar yang biasa, ada kemajuan, setidaknya duplikat. Harga kemajuan semacam itu juga bisa dipahami - beban yang nyata
prosesor. Secara umum, tidak ada penyimpangan khusus dalam memprediksi hasil.

Kesimpulan

Jika Anda tidak perlu terburu-buru ke mana pun, dan ada juga margin prosesor, salah satu solusi yang dipertimbangkan akan melakukan, dalam hal apa pun, banyak pekerjaan telah dilakukan, yang tidak boleh diulang dengan menulis skrip pembungkus di atas tar. Kehadiran enkripsi adalah properti yang sangat diperlukan jika server untuk menyimpan cadangan tidak dapat sepenuhnya dipercaya.

Dibandingkan dengan solusi berbasis rsync , kinerja dapat beberapa kali lebih buruk, meskipun pada kenyataannya tar dalam bentuk murni bekerja lebih cepat daripada rsync sebesar 20-30%.
Menyimpan pada ukuran repositori adalah, tetapi hanya untuk duplikat.

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, dup deja
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