Skip to main content
Question

Veeam i "grubasy".


Cześć,

Jestem w trakcie wdrożenia VB&R 13.x. Powoli sobie z wykonawca to konfigurujemy, ale nachodzą  nie wątpliwości dotyczące obciążenia sieci.
Jak dobrze kojarzę to redukcja danych (dalej będę nazywał to deduplikacja) w Veeam działa w ramach jednego JOBa (savesetu). Deduplikacja nie działa na źródle, na kliencie backupu tylko na serwerach proxy więc od klienta do proxy muszą przejść wszystkie dane zaznaczone do backupu, na proxy jest deduplikacja i do storage leci już jakiś ułamek tych danych.

Wątpliwość 1: Czy ruch pomiędzy klientem a proxy "nie zabije sieci"?
// Fizycznie to te same inerface co produkcja, logicznie jest rozdzielone. Taki backup agentowy klienta, który ma 50 TB (a takich klientów ma z 8) w dyskach to backup typu full może trwać kilka dni. W wypadku rtych klientów mam tak, że każdy jest sam na wykrojonym datastore.

Wątpliwość 2: Jakiej deduplikacji można się spodziewać pomiędzy proxy a storage? 
// Powiedzmy, że na kliencie jest każdy typ danych: 60% dokumentów docx, pdf xlsx, 20% to jakieś instaklki msi, exe, rpm, 20% to multimedia.

 

Zastanawiam się jak podejść do wątpliwości 1, czy macie jakąś praktykę w backupie dużych klientów?

 

Pozdrawiam, Łukasz

4 comments

Tomek Krajewski
Forum|alt.badge.img

Ja wiem, że już od dawna się nie znam, ale żebyśmy zrozumieli: robisz backup dużej VMki agentem w środku, tak? Wnioskuje po “W wypadku tych klientów mam tak, że każdy jest sam na wykrojonym datastore.”. Jakiś szczególny powód czemu akurat takie podejście? Jaki hypervisor?


Sorka za nieścisłości, dopiero wdrażam się w “filozofię” Veeama. 11 lat na innym backupie robi swoje :)

Te serwery to VM. Backup planuje volume level. Agent zainstalowany jest na tym kliencie.

VMware. VMki są bardzo duże dlatego każda jest na oddzielnym datasotre.

Jak kolega dał mi znać to deduplikacja w ramach joba wykona już zainstalowany agent?

Jeżeli tak to agent ma jakąś bazę zdeduplikownych plików?

 

Mam też klientów na któych planuje backup File Level ponieważ mam do zabrania 1-2 pliki, ale “klocki” po 5 TB. 

A! Pisząc proxy mam na myśli General purpose. Ogólnie proxy pełnią u mnie podwójną rolę: general purpose + snapshoty


Tomek Krajewski
Forum|alt.badge.img

Znowu - pewnie lepsi ode mnie też coś dorzucą, ale

 

Nie ma powodu, żeby robić VMki (nawet duże) agentem. Jedyne przeciwwskazanie, to czy jest miejsce na Datastorze na snapshot VMware, plus czy zrobi się commit tego snapshotu. Nawet jeżeli będzie backup całej VMki to i tak przecież możesz odtwarzać pojedyńcze pliki, czy dyski - nie widzę (bez większej ilości informacji) powodu żeby używać agenta. Co do oddzielnych datastorow per-VM - widziałem pare razy takie rozwiązania, nie wnikam teraz bez większej wiedzy co do powodów, ale było z tym więcej kłopotów niż pożytku. Chociażby brak miejsca na snapshoty VMware. I to nie tylko dla tych które generuje VBR przed backupem. 

 

Co do samego agenta - jeżeli backupujesz całą maszynę albo volumen - backup nawet agentem jest block-level. Działa wtedy nasz Change Block Tracking i zabieramy tylko zmienione bloki. Pliki zabieramy tylko w momencie, kiedy wybierzesz file-level backup, ale wtedy też śledzimy zmiany. Możesz poczytać o tym tutaj: https://helpcenter.veeam.com/docs/agentforwindows/userguide/backup_cbt.html?ver=13

 

Generalnie w przypadku VMki, nawet dużej, bardzo mało przesłanek jest żeby robić backup agentem. Żeby to ocenić jeszcze za mało info :) Czemu zdecydowałeś się na agenta w VM? Jakie powody?


Powody wyboru backupu agentowego?

Raczej przyjęło się u mnie, że snapy są do VM aplikacyjnych nie do takich co trzymają repozytorium lub z całej VM np 20 TB backupuje tylko 1 z wielu plików z jakiegoś dysku. Agentem, file level backup zabezpieczałem tylko ten 1 plik. Snapem tego nie robliliśmy by nie backupować pozostałych danych/dysków, które zapychają storage.

Backup agentowy nie jest przesądzony. Mogę sobie przetestować na krótkiej retencji backup snapem i volume level.

Teraz nasuwa mi się pytanie: Do czego przydaje się backup agentowy w Veeam