Serep Part 3: Review lan Testing saka duplikat, duplikat

Cathetan iki mbahas alat serep sing nindakake serep kanthi nggawe arsip ing server serep.

Antarane sing nyukupi syarat kasebut yaiku duplikat (sing nduweni antarmuka sing apik ing wangun deja dup) lan duplikat.

Alat serep liyane sing luar biasa yaiku dar, nanging amarga duwe dhaptar pilihan sing akeh banget - metode tes meh ora 10% saka kemampuane - kita ora nyoba minangka bagean saka siklus saiki.

Asil sing diarepake

Amarga loro calon nggawe arsip kanthi cara siji utawa liyane, tar biasa bisa digunakake minangka pandhuan.

Kajaba iku, kita bakal ngira-ngira carane panyimpenan data ing server panyimpenan dioptimalake kanthi nggawe salinan serep sing mung ngemot prabédan antarane salinan lengkap lan kahanan file saiki, utawa ing antarane arsip sadurunge lan saiki (tambahan, dekremental, lsp.) .

Prilaku nalika nggawe serep:

1. Jumlah file sing relatif cilik ing server panyimpenan serep (dibandhingake karo jumlah salinan serep utawa ukuran data ing GB), nanging ukurane cukup gedhe (puluhan nganti atusan megabyte).
2. Ukuran repositori mung bakal kalebu owah-owahan - ora ana duplikat sing bakal disimpen, saengga ukuran repositori bakal luwih cilik tinimbang piranti lunak berbasis rsync.
3. Nyana beban CPU abot nalika nggunakake komprèsi lan / utawa enkripsi, lan kamungkinan jaringan cukup dhuwur lan mbukak disk yen arsip lan / utawa proses enkripsi mlaku ing server panyimpenan serep.

Ayo mbukak printah ing ngisor iki minangka nilai referensi:

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

Asil eksekusi kaya ing ngisor iki:

Wektu eksekusi 3m12s. Sampeyan bisa ndeleng sing kacepetan diwatesi dening subsistem disk saka server panyimpenan serep, kaya ing conto karo rsync. Mung luwih cepet, amarga ... ngrekam menyang siji file.

Uga, kanggo ngevaluasi kompresi, ayo mbukak pilihan sing padha, nanging aktifake kompresi ing sisih server serep:

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

Hasile yaiku:

Wektu eksekusi 10m11s. Paling kamungkinan bottleneck punika kompresor aliran siji ing mburi nampa.

Printah padha, nanging karo komprèsi ditransfer menyang server karo data asli kanggo test hipotesis sing bottleneck kompresor single-threaded.

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

Ternyata kaya mangkene:

Wektu eksekusi yaiku 9m37s. Beban ing siji inti dening kompresor katon cetha, amarga Kacepetan transfer jaringan lan beban ing subsistem disk sumber padha.

Kanggo ngevaluasi enkripsi, sampeyan bisa nggunakake openssl utawa gpg kanthi nyambungake printah tambahan openssl utawa gpg ing pipa. Kanggo referensi bakal ana printah kaya iki:

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

Asil metu kaya iki:

Wektu eksekusi dadi 10m30s, amarga 2 pangolahan mlaku ing sisih panrima - bottleneck maneh kompresor siji-Utas, plus overhead enkripsi cilik.

UPD: Ing panjalukan saka bliznezz aku nambahake tes karo pigz. Yen sampeyan nggunakake mung kompresor, iku bakal njupuk 6m30s, yen sampeyan uga nambah enkripsi, iku bakal bab 7m. Dip ing grafik ngisor iki cache disk unflushed:

Pengujian duplikat

Duplicity minangka piranti lunak python kanggo serep kanthi nggawe arsip sing dienkripsi ing format tar.

Kanggo arsip tambahan, librsync digunakake, supaya sampeyan bisa nyana prilaku sing diterangake ing kirim sadurunge ing seri.

Serep bisa dienkripsi lan ditandatangani nggunakake gnupg, sing penting nalika nggunakake panyedhiya sing beda kanggo nyimpen serep (s3, backblaze, gdrive, lsp.)

Ayo ndeleng apa asile:

Iki minangka asil sing ditampa nalika mlaku tanpa enkripsi

ngrusak

Wektu mlaku saben test run:

Bukak 1
Bukak 2
Bukak 3

16m33
17m20
16m30

8m29
9m3
8m45

5m21
6m04
5m53

Lan iki minangka asil nalika enkripsi gnupg diaktifake, kanthi ukuran kunci 2048 bit:

Wektu operasi ing data sing padha, kanthi enkripsi:

Bukak 1
Bukak 2
Bukak 3

17m22
17m32
17m28

8m52
9m13
9m3

5m48
5m40
5m30

Ukuran blok kasebut dituduhake - 512 megabyte, sing katon kanthi jelas ing grafik; Beban prosesor tetep ing 50%, tegese program kasebut ora nggunakake luwih saka siji inti prosesor.

Prinsip operasi program kasebut uga katon kanthi jelas: dheweke njupuk sepotong data, dikompres, lan dikirim menyang server panyimpenan serep, sing bisa uga alon banget.
Fitur liyane yaiku wektu mlaku program sing bisa ditebak, sing mung gumantung saka ukuran data sing diganti.

Nerjemahake isoh enkripsi ora Ngartekno nambah wektu mlaku program, nanging nambah beban prosesor udakara 10%, sing bisa dadi bonus sing apik.

Sayange, program iki ora bisa ndeteksi kahanan kanthi bener kanthi ngganti jeneng direktori, lan ukuran gudang sing diasilake padha karo ukuran owah-owahan (yaiku kabeh 18GB), nanging kemampuan kanggo nggunakake server sing ora dipercaya kanggo serep kanthi jelas. nyakup prilaku iki.

Pengujian duplikat

Piranti lunak iki ditulis ing C # lan nganggo sakumpulan perpustakaan saka Mono. Ana GUI uga versi CLI.

Dhaptar kira-kira fitur utama meh padha karo duplikat, kalebu macem-macem panyedhiya panyimpenan serep, nanging ora kaya duplikat, umume fitur kasedhiya tanpa piranti pihak katelu. Apa iki plus utawa minus gumantung ing kasus tartamtu, nanging kanggo pamula, iku paling gampang kanggo duwe dhaptar kabeh fitur ing ngarepe bebarengan, tinimbang kudu nginstal paket tambahan kanggo python, minangka kasus karo duplikat.

Nuansa cilik liyane - program kasebut kanthi aktif nulis database sqlite lokal atas jenenge pangguna sing miwiti serep, dadi sampeyan kudu mesthekake yen database sing dibutuhake wis ditemtokake kanthi bener saben proses diwiwiti nggunakake cli. Nalika nggarap GUI utawa WEBGUI, rincian bakal didhelikake saka pangguna.

Ayo ndeleng indikator apa sing bisa diasilake solusi iki:

Yen sampeyan mateni enkripsi (lan WEBGUI ora nyaranake nindakake iki), asile kaya ing ngisor iki:

Jam kerja:

Bukak 1
Bukak 2
Bukak 3

20m43
20m13
20m28

5m21
5m40
5m35

7m36
7m54
7m49

Kanthi enkripsi diaktifake, nggunakake aes, katon kaya iki:

Jam kerja:

Bukak 1
Bukak 2
Bukak 3

29m9
30m1
29m54

5m29
6m2
5m54

8m44
9m12
9m1

Lan yen sampeyan nggunakake program eksternal gnupg, asil ing ngisor iki metu:

Bukak 1
Bukak 2
Bukak 3

26m6
26m35
26m17

5m20
5m48
5m40

8m12
8m42
8m15

Kaya sing sampeyan ngerteni, program kasebut bisa digunakake ing pirang-pirang utas, nanging iki ora nggawe solusi sing luwih produktif, lan yen sampeyan mbandhingake karya enkripsi, mula mbukak program eksternal.
diaktifake metu dadi luwih cepet saka nggunakake perpustakaan saka Mono pesawat. Iki bisa uga amarga kasunyatan manawa program eksternal luwih dioptimalake.

Liyane sing apik yaiku kasunyatan manawa ukuran repositori njupuk persis kaya data sing diganti, yaiku. duplicati ndeteksi ganti jeneng direktori lan nangani kahanan iki kanthi bener. Iki bisa dideleng nalika nindakake tes kapindho.

Sakabèhé, kesan sing cukup positif saka program kasebut, kalebu cukup ramah karo pemula.

Результаты

Loro-lorone calon makarya rada alon, nanging ing umum, dibandhingake tar biasa, ana kemajuan, paling karo duplikat. Rega kemajuan kasebut uga jelas - beban sing katon
prosesor. Umumé, ora ana panyimpangan khusus kanggo prédhiksi asil.

temonan

Yen sampeyan ora perlu cepet-cepet ing ngendi wae, lan uga duwe prosesor cadangan, solusi apa wae sing dianggep bakal ditindakake, ing kasus apa wae, cukup akeh karya sing ora kudu diulang kanthi nulis skrip bungkus ing ndhuwur tar. . Anane enkripsi minangka properti sing dibutuhake banget yen server kanggo nyimpen salinan serep ora bisa dipercaya.

Dibandhingake solusi adhedhasar rsync - kinerja bisa kaping pirang-pirang Samsaya Awon, senadyan kasunyatan sing ing wangun murni tar makarya 20-30% luwih cepet saka rsync.
Ana tabungan ing ukuran repositori, nanging mung karo duplikat.

Pengumuman

Gawe serep, bagean 1: Napa serep dibutuhake, ringkesan metode, teknologi
Bagean Serep 2: Priksa lan nguji alat serep basis rsync
Bagean Gawe serep 3: Priksa lan nguji duplikat, duplikat, duplikat deja
Backup Part 4: Reviewing lan testing zbackup, restic, borgbackup
Backup Part 5: Testing bacula lan veeam backup kanggo linux
Serep Part 6: Mbandhingaké Serep Tools
Serep Part 7: Kesimpulan

Dikirim dening: Pavel Demkovich

Source: www.habr.com