To, czym backup jest, a czym nie, jak jest wykonywany oraz czemu ostatecznie służy, nieustannie się zmienia. Dzieje się tak przede wszystkim dlatego, że backup musi stale nadążać za zmianami w innych obszarach – skalą biznesu, architekturą rozwiązań podlegających ochronie, wzrostem ilości i różnorodności danych, zmianami technologicznymi, możliwymi technikami wykonywania kopii i tak dalej. Wszystkie te zagadnienia mają bezpośredni wpływ na niezawodność i wydajność backupu, a także na związane z nim koszty. Odpowiedzi na pytania o cele, metody i architektury systemów backupowych z roku na rok wyglądają więc inaczej. Na co zwrócić uwagę, szykując się do budowy systemu backupowego w 2015 r.?

W wyniku zmian biznesowych i technologicznych granica między wysoką dostępnością, backupem i archiwizacją, niegdyś bardzo czytelna, ulega rozmyciu, a w zasadzie kategorie te ulegają scaleniu w ramach coraz bardziej spójnej, jednolitej strategii ochrony systemów i danych. Nie może być zresztą inaczej, skoro liczba systemów wymagających wysokiej dostępności stale się wydłuża, a technologie zapewniające wysoką dostępność coraz silniej integrują się z rozwiązaniami backupowymi i archiwizacyjnymi. Ponadto, systemy, które kiedyś uważaliśmy za mało istotne z punktu widzenia odtwarzania, stały się niejednokrotnie krytyczne dla biznesu, np. analityczno-raportowe czy webowe. Wzrosła także rola wymogów regulacyjnych tworzących obowiązki związane z niezawodnością i pewnością przetwarzania danych – nie zawsze tych, które są najważniejsze z perspektywy biznesowej.

Czy to jeszcze backup, czy już…

Kluczem do myślenia o backupie od zawsze były dwa parametry – to, ile danych jesteśmy skłonni utracić w wyniku awarii, czyli RPO, a także to, jak szybko środowisko powinno zostać przywrócone do pełnej sprawności, czyli RTO. Na drugiej szali leżą zwykle pieniądze – im mniej danych chcemy utracić i im szybciej systemy mają wrócić do stanu pożądanego, tym kwoty są wyższe. Akurat pod tym względem od lat nic się nie zmienia, i raczej się nie zmieni. Na potrzeby dalszych rozważań ustalmy więc podział być może nieco arbitralnie, ale w sposób mający wiele wspólnego z realiami obserwowanymi przeze mnie wielokrotnie u klientów. Backupem niech będzie wykonywanie kopii danych z przewidywanym celem RPO powyżej 1 godziny, zaś wysoką dostępnością zabezpieczenie z celem RPO poniżej 1 godziny.

Jeśli chodzi o ustalenie wyraźnej linii podziału między współczesnym backupem i archiwizacją, sprawa jest w sumie jeszcze trudniejsza. Współczesne archiwum to nic innego, jak dłużej przechowywana, pełna kopia bezpieczeństwa. Pełna, co jasne, w sensie logicznym, ponieważ na skutek stosowania deduplikacji i innych zabiegów, zarówno backup, jak i archiwum, mają postać fizyczną niezupełnie taką, jak dane oryginalne. Istnieją także dedykowane systemy archiwizujące i indeksujące dane, pozostawiające skróty w miejscu zarchiwizowanych elementów, lecz tego typu rozwiązania pomijam w tych rozważaniach. Nieostrość wynika także z faktu, że długość czasu przechowywania danych bywa różna w zależności od konkretnych potrzeb biznesowych, oraz regulacji. Na potrzeby dalszych rozważań przyjmijmy, znów arbitralnie, lecz realistycznie zarazem, że kopie zapasowe przechowywane dłużej niż 1 lub 2 tygodnie to już w praktyce kopie archiwalne.

Rzeczą nie do pominięcia w dyskusjach o backupie jest ustalenie tego, co jest przedmiotem kopiowania. Najkrócej rzecz ujmując, inaczej podejdziemy do wykonywania kopii środowisk działających bezpośrednio na sprzęcie, inaczej zaś do kopiowania środowisk zwirtualizowanych. Ten podział jest głęboko uzasadniony nie tylko różnicami technologicznymi, ale także możliwościami wykrywania awarii i reagowania na nie, a więc odtwarzania. Przykładowo, poprawne działanie klastra VMware vSphere nie oznacza automatycznie, że systemy i aplikacje działające w jego wnętrzu również działają poprawnie. Klaster VMware może mieć RPO bliskie zera, a RTO na poziomie minut, a mimo to, bez spójnej kopii tego, co działało wewnątrz klastra, odtworzenie środowiska maszyn wirtualnych raczej się nie uda.

Konserwatywne licencjonowanie jednak popłaca

W dyskusjach o backupie nie można pominąć wątku licencjonowania rozwiązań backupowych. Większość producentów oferuje kilka modeli licencjonowania, w tym oparte na liczbie serwerów, liczbie zabezpieczanych hostów, a także modele pojemnościowe. Uzależnienie kwot płaconych za rozwiązanie od wielkości zabezpieczanych danych wydaje się rozsądne, ale jest to dość ryzykowna strategia. Marketing producentów podkreśla niskie bariery zakupu, ale dyskretnie pomija fakt, że ilość danych rośnie zwykle szybciej, niż liczba urządzeń. W związku z wirtualizacją i konsolidacją liczba urządzeń potrafi wręcz maleć, o czym warto pamiętać. Model pojemnościowy powinien być stosowany tylko wtedy, gdy organizacja jest w stanie skutecznie panować nad tempem przyrostu danych.

Kopiować, ale jak?

Wykonywanie pełnej kopii danych za każdym razem jest pożądane, tyle że w większości realnych środowisk niewykonalne ze względu na ograniczone okno czasowe. Pełne kopie wykonywane są więc tylko okresowo, np. raz na tydzień, w dni wolne, kiedy okno czasowe jest dłuższe. Pomiędzy nimi wykonywane są kopie przyrostowe, które w niektórych rozwiązaniach mogą być scalane z wcześniejszą pełną kopią za pomocą mechanizmów syntetycznych.

Stosując tradycyjne metody backupu oparte na rozwiązaniach taśmowych nie da się znacząco zmniejszyć ilości danych przesyłanych z chronionego serwera do systemu backupowego, a w konsekwencji, nie da się istotnie skrócić czasu backupu. Stosując rozwiązania dyskowe można jedynie zmniejszyć ich objętość w systemie backupu, wykorzystując w tym celu deduplikację (target deduplication). Proces deduplikacji polega, w skrócie, na eliminowaniu duplikatów danych i zapisywaniu jedynie bloków unikalnych, co zapewnia zwiększenie logicznej przestrzeni na dyskach nawet kilkudziesięciokrotnie.

„Stosując tradycyjne metody backupu oparte na rozwiązaniach taśmowych nie da się znacząco zmniejszyć ilości danych przesyłanych z chronionego serwera do systemu backupowego, a w konsekwencji, nie da się istotnie skrócić czasu backupu. Stosując rozwiązania dyskowe można jedynie zmniejszyć ich objętość w systemie backupu, wykorzystując w tym celu deduplikację (target deduplication)”

Deduplikacja może być wykonywana już na źródle przez aplikację kliencką systemu backupu, co pozwala skrócić nieco czas trwania zadań backupu, zmniejszyć ilość przesyłanych danych, ale kosztem istotnego obciążenia procesorów na systemie podlegającym ochronie. Efekt czasowy takiej operacji jest jednak w praktyce widoczny tylko w sytuacji, gdy to sieć LAN jest wąskim gardłem procesu backupu. Jeżeli podczas backupu klient nie był w stanie wysycić interfejsu 1Gb Ethernet, wtedy nawet po zastosowaniu deduplikacji na źródle zyskamy niewiele w sensie czasowym. Jedyny scenariusz, w którym deduplikacja na źródle może być rzeczywiście użyteczna, to taki, w którym barierą wydajności backupu jest pasmo na interfejsach sieciowych serwerów systemu backupowego, przyjmujących dane z chronionych systemów.

Aby uzyskać naprawdę znaczącą poprawę wydajności i skrócenie czasu trwania zadań backupu, trzeba zmienić technikę odczytu danych źródłowych z klientów systemu backupu. Zamiast za każdym razem odczytywać i przesyłać przez sieć pełną kopię danych, agent systemu backupowego może śledzić zmiany w systemie źródłowym i odpowiadające im zmiany bloków od czasu wykonania ostatniej kopii, zapisując je w podręcznej bazie danych lub lokalnym pliku. Śledzenie zmian w systemie plików (np. NTFS) jest możliwe na podstawie dziennika (journal). Z kolei VMware stworzył mechanizm Change Block Tracking (CBT). Dzięki niemu, w momencie wykonywania kopii agent systemu backupowego odczytuje tylko zmienione bloki z systemu źródłowego, przeprowadza deduplikację (opcjonalnie), a następnie przesyła do serwera backupowego informacje o tym, które zakresy bloków uległy zmianie oraz zmienione bloki, a ten wprowadza zmiany na kopii logicznie tworząc kolejną kopię pełną.

W ten sposób, w trakcie wykonywania kopii zapasowych z klienta odczytywane są minimalne ilości danych, które następnie są przesyłane przez sieć, i w efekcie sumaryczny czas wykonywania backupu można zmniejszyć wielokrotnie. W mechanizmach typu CBT kluczowy jest minimalny odczyt z klienta, to on bowiem stanowi w praktyce wąskie gardło w systemach backupu, nie zaś transfer danych w sieci LAN. Ilość danych transferowanych po sieci LAN możemy zmniejszyć stosując deduplikację na źródle, jednak dopiero mechanizm śledzenia i odczytu zmian doprowadza do prawdziwego skrócenia czasu wykonywania backupu. Wyniki często są imponujące.

„Aby uzyskać naprawdę znaczącą poprawę wydajności i skrócenie czasu trwania zadań backupu, trzeba zmienić technikę odczytu danych źródłowych (…). Zamiast za każdym razem odczytywać i przesyłać przez sieć pełną kopię danych, agent systemu backupowego może śledzić zmiany w systemie źródłowym i odpowiadające im zmiany bloków od czasu wykonania ostatniej kopii, zapisując je w podręcznej bazie danych lub lokalnym pliku. (…). W ten sposób (…) sumaryczny czas wykonywania backupu można zmniejszyć wielokrotnie”

Mamy dobitny przykład takiego efektu na naszym własnym podwórku. Wykonanie pełnej kopii na taśmie LTO maszyny wirtualnej VMware wielkości ponad 700 GB, zawierającej bazy pocztowe i aplikacje Lotus Domino, zajmowało po sieci LAN zwykle ok. 4-5 godzin. Wykonanie pełnej kopii tej samej maszyny wirtualnej za pomocą aplikacji Symantec/Veritas NetBackup oraz mechanizmu NetBackup Accelerator i transferu również po sieci LAN, skraca czas backupu do nieco ponad 7 minut z logiczną prędkością przekraczającą 2GB/s (17Gb/s). Jak to możliwe? Zrzut ekranu poniżej mówi wszystko: faktycznie skopiowanych zostało ok. 4 GB danych, które uległy zmianom od ostatniego zadania backupu. Agent systemu backupowego dzięki funkcji NetBackup Accelerator i integracji z VMware Change Block Tracking odczytał ze źródła tylko zmienione bloki dysków wirtualnych, które stanowiły jedynie ok. 0,5% objętości maszyny wirtualnej! Jak widać, śledzenie, identyfikacja i odczyt jedynie zmienionych bloków w połączeniu z deduplikacją mają przed sobą przyszłość.

Jak skrócić backup maszyny wirtualnej wielkości ponad 700 GB z 4-5 godzin do 7 minut? Śledzenie, identyfikacja i odczyt jedynie zmienionych bloków w połączeniu z deduplikacją mają przed sobą przyszłość.

Kopia bardzo blisko macierzy

Mamy rok 2015 i oprogramowanie systemów pamięci masowych nie jest już monolityczne, umożliwiając integrację z aplikacjami zewnętrznymi, w tym właśnie backupowymi. Dobrym przykładem takiej integracji jest współpraca Symantec/Veritas i NetApp. Obie firmy opublikowały ostatnio wyniki testów, podczas których backupowanych było 1000 maszyn wirtualnych VMware. Wyniki pokazują jednoznacznie, że integracja ma przemożny wpływ na wydajność. Macierze NetApp FAS 3240 w połączeniu z oprogramowaniem Symantec NetBackup 7.6 (w postaci Symantec NetBackup Appliance 5230) zmieściły się z wykonaniem kopii tysiąca maszyn wirtualnych w czasie zaledwie 2 godzin i 51 minut, (żółty słupek na wykresie). Inne rozwiązania backupowe w tym samym środowisku wypadły dużo gorzej – ponad 8 godzin lub nawet ponad 14 godzin (niebieski i czerwony słupek). Symantec NetBackup Accelerator oraz integracja z funkcjami snapszotów macierzy są dostępne także dla innych platform, np. EMC.

Macierze NetApp FAS 3240 w połączeniu z oprogramowaniem Symantec NetBackup 7.6 (w postaci Symantec NetBackup Appliance 5230) zmieściły się z wykonaniem kopii tysiąca maszyn wirtualnych w czasie zaledwie 2 godzin i 51 minut, (żółty słupek na wykresie). Inne rozwiązania backupowe w tym samym środowisku wypadły dużo gorzej – ponad 8 godzin lub nawet ponad 14 godzin (niebieski i czerwony słupek). Skala zrobiła swoje – tysiąc maszyn wirtualnych to dużo, i okazuje się, że integracja z oprogramowaniem macierzy jest w dużych środowiskach kluczowa.

Warto tu podkreślić, ze wszystkie testowane systemy korzystały z optymalizacji odczytu z wykorzystaniem oferowanej przez środowisko VMware funkcji Change Block Tracking, dzięki któremu odczytywane były jedynie różnice na poziomie blokowym. A zatem, choć warunki sprzyjały wydajności, skala zrobiła swoje – tysiąc maszyn wirtualnych to dużo, i okazuje się, że integracja z oprogramowaniem macierzy jest w dużych środowiskach kluczowa. Mało tego, dalsze zwiększanie liczby maszyn wirtualnych nie powoduje znacznego wzrostu czasu wykonywania backupu.

Zmiany dotyczą także backupu systemów plików. Tradycyjny backup plikowy to już przeżytek. Dla dużych systemów plików, a te są największym wyzwaniem, kopiując dzisiaj plik po pliku z systemu źródłowego nie jesteśmy w stanie zmieścić się z zadaniem backupu w żadnym akceptowalnym oknie czasowym. Producenci systemów backupu zapewniają odpowiednie wtyczki do systemów plików, a nawet urządzeń NAS. Dzięki nim, system backupowy może zajrzeć do dziennika transakcji systemu plików NTFS albo VxFS i wybrać tylko te zakresy bloków, czy nawet bajtów, które uległy zmianom. Mechanizm ten wielokrotnie skraca czas backupu. Dzięki niemu, w imponującym stylu jesteśmy w stanie zmieścić się w zakładanych oknach czasowych i spełnić wymagania biznesowe.

„Tradycyjny backup plikowy to już przeżytek. Dla dużych systemów plików, a te są największym wyzwaniem, kopiując dzisiaj plik po pliku z systemu źródłowego nie jesteśmy w stanie zmieścić się z zadaniem backupu w żadnym akceptowalnym oknie czasowym”

Jeśli mamy do czynienia z urządzeniami NAS, zawsze pozostaje protokół NDMP, który NetApp wraz z Legato (obecnie EMC) uzgodniły niegdyś wspólnie, a który dzisiaj jest standardem backupu urządzeń NAS. Systemy backupu, takie jak EMC Avamar czy Symantec/Veritas NetBackup, również dla protokołu NDMP są w stanie identyfikować zmiany i tylko zmienione bloki odczytywać z systemów źródłowych. Technologie te pozwalają zabezpieczać wieloterabajtowe systemy plików w czasie rzędu minut, a nie dziesiątek godzin.

Te same cele, inne metody

Dotychczas rozważaliśmy tylko backup wykonywany w jednej lokalizacji, wiele organizacji musi jednak, chcąc nie chcąc, zmierzyć się z wyzwaniem, jakim jest rozproszenie pracowników, systemów i danych. Jeśli sieć oddziałów jest niewielka, np. obejmuje kilkanaście oddziałów w głównych miastach Polski, można pokusić się o backup centralny. Gdy jednak oddziałów są dziesiątki lub setki, albo gdy oddziały są duże w sensie ilości danych, które generują, warto pomyśleć o backupie z agregacją danych na poziomie regionalnym. Taka topologia pozwoli uniknąć konieczności budowy kosztownego, superwydajnego środowiska centralnego backupu, przy zachowaniu oczekiwanych parametrów bezpieczeństwa danych.

Do tematu backupu w rozproszeniu można jednak, i warto, podejść kreatywnie. Jeśli rozproszone są głównie systemy wykorzystujące serwery plików oparte na Windows, dobrym pomysłem jest wykorzystanie technologii rozproszonej struktury domenowej, DFSR (Distributed File System Replication) oraz opcji Branch Cache. Dzięki nim plikami w oddziałach zarządza serwer w centrali, zaś serwery lub komputery w oddziałach utrzymują jedynie bufor, który jest synchronizowany z centralą. W ten sposób, pomimo rozproszenia, backup może być wykonywany centralnie.

Korzyść z replikacji systemu plików jest taka, że można dzięki niej uzyskać niezłą ochronę danych bez oprogramowania backupowego. Dodanie snapszotów pozwoli również na obsługę wersjonowania i odtwarzania wcześniejszych wersji plików. Odtwarzanie może odbywać się z serwera oddziałowego lub z jego kopii na serwerze centralnym. Taka architektura wymaga jednak przemyślenia i planowania na poziomie łącz oraz technologii dyskowych i systemów bezpieczeństwa. Trzeba także zastanowić się w jakim trybie dane będą zabezpieczane na nośnikach wymiennych i archiwizowane. Ponieważ funkcje tego rodzaju wykonuje w praktyce oprogramowanie backupowe, może się okazać, że pierwotne założenia dotyczące architektury całego rozwiązania trzeba będzie jednak zweryfikować.

„Do tematu backupu w rozproszeniu można i warto, podejść kreatywnie. Jeśli rozproszone są głównie systemy wykorzystujące serwery plików oparte na Windows, dobrym pomysłem jest wykorzystanie technologii rozproszonej struktury domenowej, DFSR (Distributed File System Replication) oraz opcji Branch Cache. (…) W ten sposób, pomimo rozproszenia, backup może być wykonywany centralnie”

Wszystko w jednym?
Na rynku wciąż pojawiają klienci chcący zbudować jedno, spójne rozwiązanie do backupu „wszystkiego” – nie tylko serwerów, ale także komputerów, laptopów i urządzeń mobilnych. Wszyscy liczący się producenci oferują rozwiązania dla każdej z tych kategorii, ale są to zwykle rozwiązania odrębne lub podobne jedynie z nazwy. Jest to głęboko uzasadnione technologicznie i architektonicznie – ich wewnętrzna architektura i zasady działania są bowiem tak różne, że próba ich integracji mija się z celem.

Serwer to coś, co z perspektywy backupu jest zawsze w tym samym miejscu, pod tym samym adresem IP. Jeśli serwer „zniknie”, to dla systemu backupowego, i nie tylko, jest to duży, czerwony alarm. Z kolei dla laptopa niedostępność w sieci lub okresowe pojawianie się w niej, za każdym razem z innym adresem IP, to stan, można powiedzieć, naturalny. Z tego właśnie w dużej mierze wynika zasadniczo inna konstrukcja systemów backupowych dla wszelkich platform mobilnych. W ich przypadku polityka wykonywania kopii w trybie „codziennie o 15.00” nie ma po prostu racji bytu. Jedynym wyjątkiem od tej reguły są stacjonarne stacje robocze, zwykle działające w tym samym miejscu i pod tym samym adresem IP. Takich stacji zwykle nawet nie wyłącza się na noc, podobnie jak serwerów.

W rozwiązaniach do zabezpieczania platform serwerowych to serwer backupowy wyznacza czas i steruje procesem wykonywania kopii. W przypadku platform mobilnych to agent zainstalowany na urządzeniu jest panem sytuacji. Można go skonfigurować tak, by np. kopie były wykonywane wtedy, gdy komputer dysponuje dostępem do sieci o określonej minimalnej przepustowości, oraz aby ostatni backup zawsze był dostępny w lokalnym buforze na wypadek potrzeby odtwarzania przy braku dostępu do sieci. Definicje polityk muszą być bardziej elastyczne także dlatego, że komputer może być niedostępny do backupu nawet przez kilka dni. W takim przypadku zwykle uruchomiona zostanie lokalna procedura przypominająca użytkownikowi o konieczności połączenia się z serwerem backupowym.

 
Konrad Puchała

Autor jest architektem systemowym w firmie Advatech. Można się z nim skontaktować pod adresem: kpuchala w domenie advatech kropka pl.