Ĉi tiu revizia noto daŭras
Revizio de UrBackup.
Laŭ peto de la partoprenanto
En la plena rezerva reĝimo, la sekvaj rezultoj estis akiritaj:
Laboraj horoj:
Unua komenco
Dua lanĉo
Tria lanĉo
Unua provo
8m20s
8m19s
8m24s
Dua provo
8m30s
8m34s
8m20s
Tria provo
8m10s
8m14s
8m12s
En pliiga rezerva reĝimo:
Laboraj horoj:
Unua komenco
Dua lanĉo
Tria lanĉo
Unua provo
8m10s
8m10s
8m12s
Dua provo
3m50s
4m12s
3m34s
Tria provo
2m50s
2m35s
2m38s
La deponejo en ambaŭ kazoj estis proksimume 14 GB, kio indikas funkciantan deduplikadon ĉe la servilo. Oni devas ankaŭ rimarki, ke ekzistas diferenco inter la sekurkopio-kreadtempo sur la servilo kaj la kliento, kiu estas sufiĉe klare videbla el la grafikaĵoj kaj estas tre agrabla gratifiko, ĉar la retinterfaco montras la rultempon de la rezerva procezo sur la servila flanko sen konsideri
stato de kliento. Ĝenerale, la grafikaĵoj por la plenaj kaj pliigaj kopioj estas nedistingeblaj. La nura diferenco verŝajne estas kiel ĝi estas pritraktata ĉe la servilo. Mi ankaŭ estis kontenta pri la malalta procesoroŝarĝo sur la redunda sistemo.
BackupPC-Revizio
Laŭ peto de la partoprenanto
En la maniero krei plenajn sekurkopiojn kun rsync, la sekvaj rezultoj estis akiritaj:
Unua komenco
Dua lanĉo
Tria lanĉo
Unua provo
12m25s
12m14s
12m27s
Dua provo
7m41s
7m44s
7m35s
Tria provo
10m11s
10m0s
9m54s
Se vi uzas plenajn sekurkopiojn kaj gudron:
Unua komenco
Dua lanĉo
Tria lanĉo
Unua provo
12m41s
12m25s
12m45s
Dua provo
12m35s
12m45s
12m14s
Tria provo
12m43s
12m25s
12m5s
En pliiga rezerva reĝimo, mi devis forlasi gudron ĉar sekurkopioj ne estis kreitaj kun ĉi tiuj agordoj.
La rezultoj de kreado de pliigaj sekurkopioj uzante rsync estas:
Unua komenco
Dua lanĉo
Tria lanĉo
Unua provo
11m55s
11m50s
12m25s
Dua provo
2m42s
2m50s
2m30s
Tria provo
6m00s
5m35s
5m30s
Ĝenerale, rsync havas iometan rapidecan avantaĝon; rsync ankaŭ funkcias pli ekonomie kun la reto. Ĉi tio povas esti kompensita parte per malpli da CPU-uzado kun gudro kiel rezerva programo. Alia avantaĝo de rsync estas ke ĝi funkcias kun pliigaj kopioj. La grandeco de la deponejo dum kreado de plenaj sekurkopioj estas la sama, 16 GB, en la kazo de pliigaj kopioj - 14 GB per kuro, kio signifas laboran deduplikadon.
AMANDA recenzo
Laŭ peto de la partoprenanto
La rezultoj de provkuro kun gudro kiel la arĥivisto kaj kunpremado ebligita estas kiel sekvas:
Unua komenco
Dua lanĉo
Tria lanĉo
Unua provo
9m5s
8m59s
9m6s
Dua provo
0m5s
0m5s
0m5s
Tria provo
2m40s
2m47s
2m45s
La programo plene ŝarĝas unu procesoran kernon, sed pro la limigita IOPS-disko ĉe la rezerva stokada servilo, ĝi ne povas atingi altajn transigajn rapidojn. Ĝenerale, la aranĝo estis iom pli ĝena ol por aliaj partoprenantoj, ĉar la aŭtoro de la programo ne uzas ssh kiel transportilon, sed efektivigas similan skemon per ŝlosiloj, kreante kaj konservante plenkreskan CA. Eblas vaste limigi la klienton kaj rezervan servilon: ekzemple, se ili ne povas tute fidi unu la alian, tiam vi povas, kiel opcio, malhelpi la servilon komenci rezervan restarigon fiksante la valoron de la responda variablo al nulo en. la agorda dosiero. Eblas konekti retan interfacon por administrado, sed ĝenerale la agordita sistemo povas esti plene aŭtomatigita uzante malgrandajn bash-skriptojn (aŭ SCM, ekzemple ansible). Estas iom ne-triviala sistemo por agordi la stokadon, kiu ŝajne estas pro la subteno de ampleksa listo de diversaj aparatoj por konservi datumojn (LTO-kasedoj, malmolaj diskoj ktp.). Estas ankaŭ notinde, ke el ĉiuj programoj priparolitaj en ĉi tiu artikolo, AMANDA estas la sola, kiu povis detekti dosierujon renomadon. La deponejo grandeco por unu kuro estis 13 GB.
Anonco
Rezerva Parto 6: Komparante Rezervaj Iloj
Rezerva Parto 7: Konkludoj
fonto: www.habr.com