Ĉi tiu noto diskutas rezervajn ilojn, kiuj faras sekurkopiojn kreante arkivojn sur rezerva servilo.
Inter tiuj, kiuj plenumas la postulojn, estas duplicity (kiu havas belan interfacon en formo de deja dup) kaj duplico.
Alia tre rimarkinda rezerva ilo estas dar, sed ĉar ĝi havas tre ampleksan liston de opcioj - la testa metodo kovras apenaŭ 10% de tio, kion ĝi kapablas - ni ne testas ĝin kiel parto de la nuna ciklo.
Atenditaj rezultoj
Ĉar ambaŭ kandidatoj kreas arkivojn laŭ unu maniero aŭ alia, regula gudro povas esti uzata kiel gvidilo.
Aldone, ni taksos kiom bone la stokado de datumoj sur la stokado-servilo estas optimumigita kreante sekurkopiojn enhavantajn nur la diferencon inter plena kopio kaj la nuna stato de la dosieroj, aŭ inter la antaŭaj kaj aktualaj arkivoj (pliigaj, malkreskaj, ktp.) .
Konduto dum kreado de sekurkopioj:
- Relative malgranda nombro da dosieroj sur la rezerva stokado-servilo (komparebla al la nombro da rezervaj kopioj aŭ al la grandeco de datumoj en GB), sed ilia grandeco estas sufiĉe granda (dekoj ĝis centoj da megabajtoj).
- La deponeja grandeco nur inkluzivos ŝanĝojn - neniuj duplikatoj estos stokitaj, do la deponeja grandeco estos pli malgranda ol kun rsync-bazita programaro.
- Atendu pezan CPU-ŝarĝon kiam vi uzas kunpremadon kaj/aŭ ĉifradon, kaj verŝajne sufiĉe altan retan kaj diskŝarĝon se la arkivado kaj/aŭ ĉifrada procezo funkcias sur rezerva stokadservilo.
Ni rulu la sekvan komandon kiel referenca valoro:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"La ekzekutrezultoj estis kiel sekvas:
Tempo de ekzekuto 3m12s. Videblas, ke la rapideco estas limigita de la disksubsistemo de la rezerva stokadservilo, kiel en la ekzemplo kun . Nur iom pli rapide, ĉar... registrado iras al unu dosiero.
Ankaŭ, por taksi kunpremadon, ni rulu la saman opcion, sed ebligu kunpremadon ĉe la rezerva servilo:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"La rezultoj estas:
Tempo de ekzekuto 10m11s. Plej verŝajne la proplemkolo estas la unuflua kompresoro ĉe la riceva fino.
La sama komando, sed kun kunpremo transdonita al la servilo kun la originaj datumoj por testi la hipotezon, ke la botelkolo estas unu-fadena kompresoro.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Ĝi rezultis jene:
La ekzekuttempo estis 9m37s. La ŝarĝo sur unu kerno de la kompresoro estas klare videbla, ĉar La reto-transiga rapido kaj la ŝarĝo sur la fontdiska subsistemo estas similaj.
Por taksi ĉifradon, vi povas uzi openssl aŭ gpg konektante plian komandon openssl aŭ gpg en pipo. Por referenco estos komando kiel ĉi tio:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"La rezultoj aperis jene:
La ekzekuttempo montriĝis 10m30s, ĉar 2 procezoj funkciis ĉe la riceva flanko - la botelkolo denove estas unufadena kompresoro, krom malgranda ĉifrado supre.
UPS: Laŭ peto de bliznezz mi aldonas testojn kun pigz. Se vi uzas nur la kompresoron, ĝi bezonus 6m30s, se vi ankaŭ aldonas ĉifradon, ĝi estus ĉirkaŭ 7m. La trempiĝo en la malsupra grafeo estas nefluigita diskkaŝmemoro:
Duoblaj provoj
Duplicity estas python-programaro por sekurkopio kreante ĉifritajn arkivojn en gudra formato.
Por pliigaj arkivoj, librsync estas uzata, do vi povas atendi la konduton priskribitan en .
Sekurkopioj povas esti ĉifritaj kaj subskribitaj per gnupg, kio estas grava kiam vi uzas malsamajn provizantoj por stoki sekurkopiojn (s3, backblaze, gdrive, ktp.)
Ni vidu, kiaj estas la rezultoj:
Ĉi tiuj estas la rezultoj, kiujn ni ricevis dum funkciado sen ĉifrado
spoiler
Kura tempo de ĉiu provo:
Lanĉo 1
Lanĉo 2
Lanĉo 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Kaj jen la rezultoj kiam gnupg-ĉifrado estas ebligita, kun ŝlosila grandeco de 2048 bitoj:
Funkcia tempo sur la samaj datumoj, kun ĉifrado:
Lanĉo 1
Lanĉo 2
Lanĉo 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
La blokgrandeco estis indikita - 512 megabajtoj, kio estas klare videbla en la grafikaĵoj; La procesoro-ŝarĝo fakte restis je 50%, kio signifas, ke la programo uzas ne pli ol unu procesoran kernon.
La principo de funkciado de la programo ankaŭ estas sufiĉe klare videbla: ili prenis pecon da datumoj, kunpremis ĝin kaj sendis ĝin al rezerva stokado-servilo, kiu povas esti sufiĉe malrapida.
Alia trajto estas la antaŭvidebla rultempo de la programo, kiu dependas nur de la grandeco de la ŝanĝitaj datumoj.
Ebligi ĉifradon ne signife pliigis la rultempon de la programo, sed ĝi pliigis la procesoran ŝarĝon je ĉirkaŭ 10%, kio povas esti sufiĉe bela gratifiko.
Bedaŭrinde, ĉi tiu programo ne povis ĝuste detekti la situacion kun la dosierujo renomado, kaj la rezulta deponejo grandeco montriĝis esti egala al la grandeco de la ŝanĝoj (t.e., ĉiuj 18GB), sed la kapablo uzi nefidinda servilo por sekurkopio klare. kovras ĉi tiun konduton.
Duoblaj provoj
Ĉi tiu programaro estas skribita en C# kaj funkcias per aro de bibliotekoj de Mono. Estas GUI kaj ankaŭ CLI-versio.
La proksimuma listo de la ĉefaj funkcioj similas al dupleco, inkluzive de diversaj rezerva stokadprovizantoj, tamen, male al dupleco, la plej multaj funkcioj estas haveblaj sen triaj iloj. Ĉu tio estas pluso aŭ minuso dependas de la specifa kazo, sed por komencantoj, plej verŝajne estas pli facile havi liston de ĉiuj funkcioj antaŭ ili samtempe, anstataŭ devi aldone instali pakaĵojn por python, kiel estas. la kazo kun dupleco.
Alia malgranda nuanco - la programo aktive skribas lokan sqlite-datumbazon nome de la uzanto, kiu komencas la sekurkopion, do vi devas aldone certigi, ke la bezonata datumbazo estas ĝuste specifita ĉiufoje kiam la procezo komenciĝas per la cli. Kiam vi laboras per GUI aŭ WEBGUI, detaloj estos kaŝitaj de la uzanto.
Ni vidu kiajn indikilojn povas produkti ĉi tiu solvo:
Se vi malŝaltas ĉifradon (kaj WEBGUI ne rekomendas fari tion), la rezultoj estas jenaj:
Laboraj horoj:
Lanĉo 1
Lanĉo 2
Lanĉo 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Kun ĉifrado ebligita, uzante aes, ĝi aspektas jene:
Laboraj horoj:
Lanĉo 1
Lanĉo 2
Lanĉo 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Kaj se vi uzas la eksteran programon gnupg, la sekvaj rezultoj aperas:
Lanĉo 1
Lanĉo 2
Lanĉo 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Kiel vi povas vidi, la programo povas funkcii en pluraj fadenoj, sed ĉi tio ne faras ĝin pli produktiva solvo, kaj se vi komparas la ĉifradan laboron, ĝi lanĉas eksteran programon.
montriĝis pli rapida ol uzi la bibliotekon de la Mono-aro. Ĉi tio povas esti pro la fakto, ke la ekstera programo estas pli optimumigita.
Alia bela afero estis la fakto, ke la grandeco de la deponejo prenas ekzakte tiom kiom la realaj ŝanĝitaj datumoj, t.e. duplicati detektis dosierujon renomon kaj traktis ĉi tiun situacion ĝuste. Ĉi tio povas esti vidita dum rulado de la dua testo.
Ĝenerale, sufiĉe pozitivaj impresoj de la programo, inkluzive de esti sufiĉe amika al novuloj.
Результаты
Ambaŭ kandidatoj laboris sufiĉe malrapide, sed ĝenerale, kompare kun regula gudro, estas progreso, almenaŭ kun duplicati. La prezo de tia progreso ankaŭ estas klara - rimarkinda ŝarĝo
procesoro. Ĝenerale, ne estas specialaj devioj en antaŭdiro de la rezultoj.
trovoj
Se vi ne bezonas rapidi ie ajn, kaj ankaŭ havas rezervan procesoron, iu ajn el la pripensitaj solvoj faros, ĉiukaze, sufiĉe multe da laboro estas farita, kiu ne devas esti ripetita skribante envolvaĵajn skriptojn sur gudro. . La ĉeesto de ĉifrado estas tre necesa posedaĵo se la servilo por stoki rezervajn kopiojn ne povas esti plene fidinda.
Kompare kun solvoj bazitaj - rendimento povas esti plurfoje pli malbona, malgraŭ tio, ke en sia pura formo gudro funkciis 20-30% pli rapide ol rsync.
Estas ŝparaĵoj sur la grandeco de la deponejo, sed nur kun duplikatoj.
Anonco
Rezerva Parto 3: Revizio kaj testado de dupleco, duobligo, jam dup
Rezerva Parto 4: Revizio kaj testado de zbackup, restic, borgbackup
Rezerva Parto 5: Testado de bacula kaj veeam sekurkopio por Linukso
Rezerva Parto 6: Komparante Rezervaj Iloj
Rezerva Parto 7: Konkludoj
Afiŝita de: Paŭlo Demkoviĉ
fonto: www.habr.com