Ky shënim rishikues vazhdon , shkruar sipas kërkesës së lexuesve, në të do të flasim për UrBackup, BackupPC, si dhe AMANDA.
Rishikimi i UrBackup.
Sipas kĂ«rkesĂ«s sĂ« pjesĂ«marrĂ«sit po shtoj rishikimin e UrBackup, njĂ« sistem klient-server pĂ«r rezervimin. Ai lejon krijimin e kopjeve tĂ« plota dhe inkrementale, mund tĂ« punojĂ« me snapshots tĂ« pajisjeve (vetĂ«m Win?), si dhe mund tĂ« krijojĂ« kopje rezervĂ« tĂ« skedarĂ«ve. Klienti mund tĂ« gjendet nĂ« tĂ« njĂ«jtĂ«n rrjet si serveri, ose tĂ« lidhet nĂ«pĂ«rmjet Internetit. ĂshtĂ« shpallur ndjekja e ndryshimeve, qĂ« lejon gjetjen e shpejtĂ« tĂ« dallimeve midis kopjeve rezervĂ«. Gjithashtu, ka mbĂ«shtetje pĂ«r deduplikimin e ruajtjes sĂ« tĂ« dhĂ«nave nĂ« anĂ«n e serverit, qĂ« lejon ruajtjen e hapĂ«sirĂ«s. Konekcionet rrjetĂ«sh janĂ« tĂ« enkriptuara, gjithashtu ka njĂ« ndĂ«rfaqe web pĂ«r menaxhimin e serverit. Le tĂ« shohim se çfarĂ« Ă«shtĂ« e aftĂ«:
Në modin e krijimit të një kopjeje të plotë rezervë, rezultatet ishin si më poshtë:
Koha e punës:
Ăelja e parĂ«
Ăelja e dytĂ«
Ăelja e tretĂ«
Testi i parë
8m20s
8m19s
8m24s
Testi i dytë
8m30s
8m34s
8m20s
Testi i tretë
8m10s
8m14s
8m12s
Në modin e krijimit të kopjeve rezervë inkrementale:
Koha e punës:
Ăelja e parĂ«
Ăelja e dytĂ«
Ăelja e tretĂ«
Testi i parë
8m10s
8m10s
8m12s
Testi i dytë
3m50s
4m12s
3m34s
Testi i tretë
2m50s
2m35s
2m38s
Madhësia e depozitës në të dy rastet ishte rreth 14 GB, që tregon për funksionimin e deduplikimit në anën e serverit. Gjithashtu, duhet theksuar mosmiratimi i kohës së krijimit të kopjes rezervë në server dhe në klient, që është mjaft qartë e dukshme në grafikë dhe është një bonus shumë i këndshëm, pasi ndërfaqja web tregon kohën e punës së procesit të rezervimit në anën e serverit pa marrë parasysh
gjendjen e klientit. Në tërësi, grafikët për kopjen e plotë dhe inkrementale janë të pandashme. Probabiliteti është se ndryshimi është vetëm se si trajtohet në anën e serverit. Gjithashtu, më gëzoi ngarkesa e ulët e procesorit në sistemin në rezervim.
Rishikimi i BackupPC
Sipas kĂ«rkesĂ«s sĂ« pjesĂ«marrĂ«sit Po shtoj njĂ« rishikim tĂ« BackupPC. Ky program instalohet nĂ« serverin e ruajtjes sĂ« kopjeve rezervĂ«, Ă«shtĂ« shkruar nĂ« Perl, punon mbi mjete tĂ« ndryshme pĂ«r kopjimin â kryesisht rsync dhe tar. Si transport pĂ«rdoren ssh dhe smb, gjithashtu ka njĂ« ndĂ«rfaqe web bazuar nĂ« cgi (qĂ« vendoset mbi apache). NĂ« ndĂ«rfaqen web ka njĂ« listĂ« tĂ« gjerĂ« opsionesh. NjĂ« karakteristikĂ« Ă«shtĂ« mundĂ«sia pĂ«r tĂ« caktuar kohĂ«n minimale midis kopjeve rezervĂ«, si dhe periudhĂ«n gjatĂ« sĂ« cilĂ«s kopjet rezervĂ« nuk do tĂ« krijohen. Kur zgjidhni sistemin e skedarĂ«ve pĂ«r serverin e kopjeve rezervĂ«, duhet tĂ« kontrolloni mbĂ«shtetje pĂ«r lidhjet e forta. KĂ«shtu, sistemi i skedarĂ«ve pĂ«r ruajtjen nuk mund tĂ« ndahet nĂ« pika tĂ« montimit. NĂ« pĂ«rgjithĂ«si, Ă«shtĂ« njĂ« pĂ«rshtypje mjaft e kĂ«ndshme, le tĂ« shohim se çfarĂ« mund tĂ« bĂ«jĂ« ky program:
Në modin e krijimit të kopjeve rezervë të plota me rsync janë arritur këto rezultate:
Ăelja e parĂ«
Ăelja e dytĂ«
Ăelja e tretĂ«
Testi i parë
12m25s
12m14s
12m27s
Testi i dytë
7m41s
7m44s
7m35s
Testi i tretë
10m11s
10m0s
9m54s
Nëse përdoren kopje rezervë të plota dhe tar:
Ăelja e parĂ«
Ăelja e dytĂ«
Ăelja e tretĂ«
Testi i parë
12m41s
12m25s
12m45s
Testi i dytë
12m35s
12m45s
12m14s
Testi i tretë
12m43s
12m25s
12m5s
Në modin e krijimit të kopjeve rezervë inkrementale duhej të hiqej dorë nga tar, pasi me këto konfigurime kopjet rezervë nuk u krijuan.
Rezultatet e krijimit të kopjeve rezervë inkrementale me rsync janë këto:
Ăelja e parĂ«
Ăelja e dytĂ«
Ăelja e tretĂ«
Testi i parë
11m55s
11m50s
12m25s
Testi i dytë
2m42s
2m50s
2m30s
Testi i tretë
6m00s
5m35s
5m30s
NĂ« pĂ«rgjithĂ«si, duket njĂ« avantazh i vogĂ«l nĂ« shpejtĂ«si pĂ«r rsync, gjithashtu rsync punon mĂ« kursyeshĂ«m me rrjetin. NĂ« njĂ« pjesĂ« tĂ« madhe, kjo mund tĂ« kompensohet me pĂ«rdorimin mĂ« tĂ« ulĂ«t tĂ« CPU me tar si program pĂ«r krijimin e kopjeve rezervĂ«. NjĂ« avantazh tjetĂ«r i rsync Ă«shtĂ« puna me kopjet inkrementale. MadhĂ«sia e depozitĂ«s gjatĂ« krijimit tĂ« kopjeve rezervĂ« tĂ« plota Ă«shtĂ« e njĂ«jtĂ«, 16 GB, ndĂ«rsa nĂ« rastin e kopjeve inkrementale â 14 GB pĂ«r njĂ« kalim, qĂ« do tĂ« thotĂ« se funksionon deduplifikimin.
Rishikimi i AMANDA
Sipas kërkesës së pjesëmarrësit Po shtoj testet e AMANDA,
Rezultatet e kalimit testues me tar si arkivues dhe aktivizimi i kompresimit janë këto:
Ăelja e parĂ«
Ăelja e dytĂ«
Ăelja e tretĂ«
Testi i parë
9m5s
8m59s
9m6s
Testi i dytë
0m5s
0m5s
0m5s
Testi i tretë
2m40s
2m47s
2m45s
Programi ngarkon plotësisht një bërthamë procesori, por për shkak të diskut të kufizuar në iops në anën e serverit që ruan kopjet rezervë, nuk mund të arrijë një shpejtësi të madhe transferimi të të dhënave. Në përgjithësi, konfigurimi solli pak më shumë shqetësime se sa pjesëmarrësit e tjerë, pasi autori i programit nuk përdor ssh si transport, por realizon një skemë të ngjashme me çelësa, duke krijuar dhe mbajtur një CA të plotë. Ekziston mundësia për të kufizuar në mënyrë të gjerë klientin dhe serverin e kopjave rezervë: për shembull, nëse ata nuk mund të besojnë plotësisht njëri-tjetrit, mund të ndaloni iniciimin e rikthimit të kopjes rezervë nga ana e serverit duke caktuar vlerën përkatëse në zero në dosjen e konfigurimit. Ekziston mundësia për të lidhur një ndërfaqe web për menaxhim, por përgjithësisht, sistemi i konfiguruar mund të automatizohet plotësisht me ndihmën e skripteve të vogla në bash (ose SCM, si ansible për shembull). Ka një sistem mjaft të ndërlikuar për konfigurimin e depozitave, që duket se është e lidhur me mbështetje për një listë të gjerë të pajisjeve të ndryshme për ruajtjen e të dhënave (kasetat LTO, disqet e forta etj.). gjithashtu është e rëndësishme të theksohet se nga të gjitha programet e shqyrtuara në këtë artikull, AMANDA është e vetmja që arriti të zbulojë rinovimin e katalogut. Madhësia e depozitës gjatë një kalimi ishte 13 GB.
Njoftim
Kopjimi i rezervave, pjesa 6: Krahasimi i mjeteve për kopje rezervë
Kopjimi i rezervave, pjesa 7: PĂ«rfundime
Burimi: habr.com
