Wąskie gardła procesu odtwarzania z backupu

mhh to akurat muszę u siebie zbadać by móc się dowiedzieć ;) ale bardzo często spotykam się również z problemami wykonywania kopi zapasowych. Wielu klientów których obsłóguje bardzo często nie patrzą na to czy można coś przyspieszyć a potem dziwią się że kopia zapasowa jednej z maszyn trwa co najmniej kilka dni. Po szybkiej weryfikacji i lekkiej modernizacji można ten wynik poprawić o co najmniej 50-60% w moim przypadku.

Jak najbardziej doceniam artykuł i porady w których miejscach można jeszcze szukać przyspieszenia :)

W tym roku testowałem wydajność odtwarzania backupów. Miałem styczność z różnymi storage (obiektówka, blokówka, deduplikator), różnymi prezentacjami danych pokazujących jak jeden produkt odtwarza szybko a inny “niby” wolno. 

Wszystko póki co sprawdzało się zawsze do szybkości odtwarzania pojedynczego strumienia, job itp

Zwielokrotnienie ilości strumieni dawało zawsze bardzo pozytywne efekty (o ile było to możliwe).

// Być może mam tu pewien zawężony obraz ponieważ nigdy nie miałem do czynienia z storage typu QNAP jako repozytorium backupowe - a przynajmniej nie testowałem wydajności. 

​@Tomasz.Magda z doświadczeń z odtwarzania infrastruktury, którą zarządzam, oraz środowisk klientów wybrałbym zdecydowanie „kilka rzeczy naraz”.

Najczęściej nie widzę jednego stałego winowajcy (no chyba, że ewidentnie coś po stronie Infra jest niedoskalowane do reszty). Przy lokalnym restore, najczęstszym ograniczeniem bywa repozytorium albo storage produkcyjny, szczególnie gdy równolegle pracują na nim normalne systemy (co często się zdarza). Przy odtwarzaniu z VCC częściej dochodzą przepustowość łącza, opóźnienia i zasoby dostępne po stronie klienta (tu rzadko Service Provider jest wąskim gardłem).

Sporo zależy też od skali. Pojedyncza maszyna potrafi odtwarzać się wyraźnie wolniej, niż sugerowałyby możliwości całej infrastruktury. Uruchomienie kilku strumieni często poprawia wynik sumaryczny, ale tylko do momentu, w którym wysycimy repozytorium, data movery albo storage docelowy.
A od strony praktycznej - przy większej awarii ważniejsze od maksymalnej liczby MB/s jest dla mnie ustalenie kolejności i jak najszybsze uruchomienie systemów krytycznych.

Dodałbym jeszcze, że szybkość samego transferu to tylko część RTO. W realnych odtworzeniach czas ucieka również na przygotowanie zasobów, mapowanie sieci i storage, uruchomienie systemów oraz sprawdzenie aplikacji. Dlatego wynik restore kończę mierzyć dopiero wtedy, kiedy działa usługa, a nie w momencie pojawienia się statusu Success (i takie parametry staram się wpisywac w dokumentacji).

I tu pełna zgoda z końcówką artykułu: bez regularnych testów trudno powiedzieć, gdzie naprawdę znajduje się wąskie gardło. Wykonywanie backupu może działać poprawnie przez lata, a ograniczenia wyjdą dopiero przy pierwszym większym odtwarzaniu.

No proszę, a myślałem, że ten wątek sprzed 4 miesięcy praktycznie umarł, a tu proszę. 🙂

Dzięki za przedstawienie swoich doświadczeń ​@Lukasz Goncikowski ​@MateuszPawlinski .