Оваа белешка за преглед продолжува
Преглед на UrBackup.
На барање на учесникот
Во режимот на целосна резервна копија, беа добиени следниве резултати:
Време:
Прв почеток
Второ лансирање
Трето лансирање
Првиот тест
8м20с
8м19с
8м24с
Втор тест
8м30с
8м34с
8м20с
Трет тест
8м10с
8м14с
8м12с
Во режим на постепена резервна копија:
Време:
Прв почеток
Второ лансирање
Трето лансирање
Првиот тест
8м10с
8м10с
8м12с
Втор тест
3м50с
4м12с
3м34с
Трет тест
2м50с
2м35с
2м38с
Големината на складиштето во двата случаи беше приближно 14 GB, што укажува на работна дедупликација на страната на серверот. Исто така, треба да се забележи дека постои несовпаѓање помеѓу времето потребно за создавање резервна копија на серверот и на клиентот, што е сосема јасно видливо од графиконите и е многу пријатен бонус, бидејќи веб-интерфејсот го покажува времето на работа на процесот на резервна копија на страната на серверот без да се земе предвид
состојбата на клиентот. Генерално, графиконите за целосните и поединечните копии не се разликуваат. Единствената разлика е веројатно како се постапува на страната на серверот. Бев задоволен и од ниското оптоварување на процесорот на вишокот систем.
BackupPC Преглед
На барање на учесникот
Во режимот на креирање целосни резервни копии со rsync, се добиени следниве резултати:
Прв почеток
Второ лансирање
Трето лансирање
Првиот тест
12м25с
12м14с
12м27с
Втор тест
7м41с
7м44с
7м35с
Трет тест
10м11с
10м0с
9м54с
Ако користите целосни бекап и тар:
Прв почеток
Второ лансирање
Трето лансирање
Првиот тест
12м41с
12м25с
12м45с
Втор тест
12м35с
12м45с
12м14с
Трет тест
12м43с
12м25с
12м5с
Во режимот на поединечна резервна копија, морав да го напуштам катранот бидејќи не беа креирани резервни копии со овие поставки.
Резултатите од создавањето поединечни резервни копии со помош на rsync се:
Прв почеток
Второ лансирање
Трето лансирање
Првиот тест
11м55с
11м50с
12м25с
Втор тест
2м42с
2м50с
2м30с
Трет тест
6м00с
5м35с
5м30с
Општо земено, rsync има мала предност во брзината; rsync исто така работи поекономично со мрежата. Ова може делумно да се компензира со помала употреба на процесорот со tar како резервна програма. Друга предност на rsync е тоа што работи со инкрементални копии. Големината на складиштето при креирање на целосни резервни копии е иста, 16 GB, во случај на поединечни копии - 14 GB по извршување, што значи работна дедупликација.
Преглед на AMANDA
На барање на учесникот
Резултатите од тестот со катран како овозможен архивер и компресија се како што следува:
Прв почеток
Второ лансирање
Трето лансирање
Првиот тест
9м5с
8м59с
9м6с
Втор тест
0м5с
0м5с
0м5с
Трет тест
2м40с
2м47с
2м45с
Програмата целосно вчитува едно процесорско јадро, но поради ограничениот IOPS диск на страната на серверот за складирање резервни копии, не може да постигне високи брзини на пренос на податоци. Во принцип, поставувањето беше малку попроблематично отколку за другите учесници, бидејќи авторот на програмата не користи ssh како транспорт, туку спроведува слична шема со клучеви, создавајќи и одржувајќи полноправна CA. Можно е широко да се ограничат клиентот и резервниот сервер: на пример, ако не можат целосно да си веруваат еден на друг, тогаш можете, како опција, да го спречите серверот да започне враќање на резервната копија со поставување на вредноста на соодветната променлива на нула во датотеката за поставки. Можно е да се поврзе веб-интерфејс за управување, но генерално конфигурираниот систем може целосно да се автоматизира со користење на мали баш скрипти (или SCM, на пример ansible). Постои донекаде нетривијален систем за поставување на складиштето, што очигледно се должи на поддршката за широк список на различни уреди за складирање податоци (LTO касети, хард дискови итн.). Исто така, вреди да се напомене дека од сите програми што се дискутирани во овој напис, AMANDA е единствената што успеа да открие преименување на директориумот. Големината на складиштето за едно извршување беше 13 GB.
Соопштение
Резервна копија Дел 6: Споредување на алатките за резервна копија
Бекап Дел 7: Заклучоци
Извор: www.habr.com