Na początku listopada wydana została open beta NAKIVO Backup & Replication v7.3. Nie minął jeszcze miesiąc, a prężnie rozwijający się producent wypuścił pełną wersję swojego softu.

NAKIVO Backup & Replication v7.3 jest już gotowe do pobrania. Dodane zostało wsparcie dla zewnętrznych rozwiązań dedykowanych do deduplikacji, co tym samym wprowadza nowy rodzaj deduplikacji oraz możliwość stworzenia nowego rodzaju repozytorium oraz bezproblemową integrację oprogramowania z infrastrukturą, w której takie urządzenia już się znajdują.

Integracja ta osiągnięta jest właśnie przez nowy typ repozytorium backupu, które zostało zoptymalizowane do pracy na dedykowanych do deduplikacji rozwiązaniach. Dzięki temu NAKIVO Backup & Replication idealnie współpracuje z takimi rozwiązaniami jak Quantum DXi, NEC HYDRAstor, EMC Data Domain, HP StoreOnce, itp.

Testy w środowiskach klientów pokazały, że nowy typ repozytorium pozwolił NAKIVO Backup & Replication v7.3 na backup maszyn wirtualnych nawet, uwaga, 53 razy szybciej, niż w przypadku zwykłego repozytorium. Przy użyciu zaawansowanego rozwiązania do deduplikacji – NEC HYDRAstor – NAKIVO Backup & Replication osiągnęło prędkość wykonywania backupu na poziomie 3.2 GB/s!

Główna różnica między normalnym (typu forever-incremental) a nowym repozytorium jest dość łatwa do wywnioskowania – normalne repozytorium przechowuje tylko przyrosty (np. zmiany wprowadzone do maszyny wirtualnej od ostatniego zadania backupu), a nowe repozytorium przechowuje całe łańcuchy backupu maszyny wirtualnej, które składają się z kilku pełnych backupów oraz kilku przyrostów pomiędzy kolejnymi pełnymi kopiami.

W kontekście integracji z rozwiązaniami do deduplikacji, nowe repozytorium:

• Tworzy mniej strumieni danych w operacjach odczytu/zapisu podczas backupu oraz odzyskiwania maszyn wirtualnych
• Nie wykorzystuje funkcji deduplikacji globalnej, którą znamy z NAKIVO Backup & Replication

Ale przyjrzyjmy się temu bliżej.

Gdy do backupowania maszyny wirtualnej wykorzystywane jest normalne repozytorium, zmienione bloki danych są zapisywane do tysięcy różnych plików w tym samym czasie. Skutkuje to tysiącami jednoczesnych strumieni danych i rozrzuceniem bloków danych z jednej maszyny wirtualnej po całym repozytorium. Rozwiązania do deduplikacji klasy enterprise są zoptymalizowane do otrzymywania danych w ograniczonej ilości strumieni (bardziej nastu niż tysięcy).

W nowym typie repozytorium, wszystkie zbackupowane bloki są porządkowane w ograniczone ilości plików dla każdej maszyny wirtualnej – jeden pełny backup i jeden kolejny plik na każdy przyrost. Dzięki temu, gdy zadanie backupu jest uruchamiane, mamy do czynienia z jednym tylko strumieniem dla każdej maszyny wirtualnej.

Wiemy, że NAKIVO Backup & Replication posiada świetną funkcję deduplikacji danych, która jest zaprojektowana tak, by zmniejszać rozmiar backupów naszych maszyn wirtualnych. Jednakże, jeśli w infrastrukturze działają duże serwery, które mają wbudowane funkcje deduplikacji, jak np. EMC Data Domain, HP StoreOnce, NEC HYDRAstor czy Quantum DXi, to ich deduplikacja może „rywalizować” z tą wbudowaną w NAKIVO. Może to mieć bardzo negatywny wpływ na wydajność całego procesu backupu.

Wybierając nowy typ repozytorium jednocześnie zmuszamy NAKIVO Backup & Replication do wyłączenia swojej wbudowanej deduplikacji. Pozwala to na unikanie konfliktów między dwoma konkurencyjnymi rozwiązaniami, które robią to samo, ale w inny sposób. Zatem, gdy w infrastrukturze znajduje się dedykowany appliance do deduplikacji, wybieramy nowe repozytorium i korzystamy z deduplikacji tego urządzenia, nie tej wbudowanej w NAKIVO.

Tworzenie okresowych pełnych backupów oznacza, że w przypadku odzyskiwania danych mamy zawsze niedawno zrobioną pełną kopię, z której możemy odzyskać nasze dane. Zwiększa to prędkość oraz wiarygodność odzyskiwania, ponieważ tylko kilka z naszych przyrostów musi być złączonych z backupem pełnym.

Z nowym typem repozytorium, zwolnienie miejsca na storage’u jest banalne – wystarczy wybrać pliki przyrostów lub pełnych backupów, które chcemy usunąć. Starsze pliki będą usuwane automatycznie, zgodnie z ustaloną polityką retencji.

Kiedy backup maszyny wirtualnej zostaje usunięty, w normalnym repozytorium pojawiają się niezagospodarowane miejsca, gdzie wcześniej były składowane konkretne bloki danych.  Te miejsca nie zawsze mogą od razu zostać nadpisane przez nowe bloki danych, więc od czasu do czasu trzeba wykonywać „odzyskiwanie” tej przestrzeni (ang. space reclaim). W nowym repozytorium, z powodu innego podejścia do składowania plików, nie jest to konieczne.

Jak używać nowego typu repozytorium na backup maszyn wirtualnych w NAKIVO Backup & Replication v7.3?

Aby zacząć używać nowego repozytorium, należy przejść następującą ścieżkę: Konfiguracja >> Repozytoria >> Dodaj Repozytorium >> Stwórz nowe repozytorium.

W polu Typ, wybierz „Incremental with full backups”, czyli przyrostowy z pełnymi backupami.

Pozostałe ustawienia mogą być konfigurowane tak samo jak zwykle, poza tym, że opcje deduplikacji oraz odzyskiwania przestrzeni nie będą dostępne.

Uwaga: jeśli zaznaczysz opcję „The target is the deduplication appliance”, automatycznie wybrany zostanie nowy typ repozytorium.

To, jaki typ repozytorium na backupu swoich maszyn wirtualnych w NAKIVO Backup & Replication v7.3 wybierzesz, powinno zależeć od konkretnych potrzeb twojej firmy. Każdy z typów ma swoje zalety, niemożliwym jest też wskazanie, że jedno jest lepsze od drugiego. Dostępność obu opcji daje ci wybór i elastyczność, dzięki której możesz zdecydować, które z rozwiązań będzie najlepiej działało w twoim środowisku. W odniesieniu do innych przydatnych funkcji NAKIVO Backup & Replication, oba typy repozytoriów dają równe możliwości i są równie wygodne dla użytkownika.

Pobierz NAKIVO Backup & Replication v7.3 z wsparciem dedykowanych rozwiązań do deduplikacji już teraz!

W tym artykule opowiem o archiwizacji serwerów na przykładzie doświadczeń firmy, w której pracuję – FENa. Mówimy o organizacji zatrudniającej kilkadziesiąt osób zajmującej się dystrybucją rozwiązań IT. Profil działalności firmy opiera się na sprzedaży oraz wsparciu i serwisie posprzedażnym, co wymaga zastosowania różnego rodzaju systemów jak CRM, systemu obsługi magazynu, serwisu, systemu obsługi zleceń OTRS, serwera pocztowego, magazynu danych i jeszcze kilku innych.

Coraz częściej sporo z tych systemów można wynieść na zewnątrz, ale niektóre ze względu na wydajność lub bezpieczeństwo nadal pozostawiamy lokalnie. Jeszcze kilka lat temu głównym problemem przy korzystaniu z infrastruktury wyniesionej była przepustowość łącz internetowych, same koszty wynajęcia zewnętrznej infrastruktury też znacznie różniły się od obecnych.

Patrząc na naszą firmę z perspektywy kilku lat, można zaobserwować trend objawiający się przenoszeniem kolejnych klocków pozwalających funkcjonować całej organizacji do chmury, w tym wypadku pierwsza na zewnątrz trafiła poczta.

Z drugiej strony widać wyraźną potrzebę zapewnienia ochrony danych i systemów które z pewnych względów przeniesione być nie mogą lub działają efektywniej lokalnie. Potrzeba ochrony danych wynika z kilku czynników, jednym z nich jest ciągłość pracy organizacji, kolejnym zgodność z regulacjami prawnymi, tymi aktualnymi i tymi z którymi przyjdzie nam się zmierzyć od maja 2018 roku, gdy w życie wejdzie rozporządzenie GDPR.

Ja jednak uważam, że najważniejszym czynnikiem jest ochrona danych po to, aby były bezpieczne. Wiem, że to brzmi jak masło maślane, postawmy się jednak na miejscu osoby, której dane przetwarzamy. Myślę, że każdy z nas chciałby aby dane jego, jego firmy, jego transakcji były należycie zabezpieczone i możliwe do odtworzenia w razie potrzeby.

Większość systemów wykorzystywanych przez FEN była i jest szyta na miarę, na przestrzeni lat oczywiście zmieniały się same serwery, a wraz z nimi systemy operacyjne.  Na początku był Linux, nie, tak naprawdę na początku była ciemność, morza i oceany, kontynenty… potem Linux.

Większość systemów w naszej firmie wykorzystywała właśnie ten system operacyjny, któremu nie mam nic do zarzucenia, no może poza złożoną administracją wymagającą sporo wiedzy. Na etapie linuksa z backupem bywało różnie, minimum to backup na zewnętrzny nośnik taki jak pendrive czy dysk USB, później backup na dodatkowy serwer po ssh, a w opcji full, backup najważniejszych danych na wyniesiony serwer. W różnych systemach wykorzystywane były różne mechanizmy, ale zawsze któryś z nich był obecny.

Kilka lat temu wraz z rozwojem technologii wirtualizacji, firma zdecydowała się na migrację. Ostatecznie padło na VMware jako rozwiązanie dość dojrzałe na tamtą chwilę, kompatybilne z wieloma GuestOS’ami włączając w to kontroler WiFi, który w końcu można było przenieść na wirtualkę zamiast utrzymywać sprzęt i przedłużać gwarancje na dodatkową skrzynkę.

W związku ze wzrostem firmy i koniecznością zarządzania większą liczbą użytkowników oraz możliwościami wynikającymi z wirtualizacji pojawiły się nowe usługi jak Active Directory. Większość sprzętowych serwerów i kontroler WiFi zostały zastąpione przez maszyny wirtualne, co znacznie uprościło zarządzanie całą infrastrukturą. Zmniejszyła się jednocześnie ilość sprzętu, który trzeba było utrzymywać i niestety okresowo wymieniać.

Ilość maszyn wirtualnych praktycznie podwoiła się w stosunku do tego co było wcześniej, ale w końcu można było dedykować konkretne maszyny do wybranych funkcji.

Niezależnie od tego na czym systemy pozwalające pracować organizacji stoją, ich backup jest niezbędny. Nie tylko do tego aby odtworzyć dane w razie klęski żywiołowej, ale z bardziej prozaicznych powodów, na przykład ludzkiego błędu lub celowego działania osób trzecich. Pisząc to nie mam na myśli złodzieja, który przyjdzie i wyrwie dyski z serwera –  oczywiście nie można tego wykluczyć, ale od tego są inne systemy bezpieczeństwa.

Aktualnie jednym z największych zagrożeń jest szkodliwe oprogramowanie, którego cel stanowią nasze dane. Coraz częściej zdarza się, że potencjalny atakujący sam opracowuje tylko część szkodliwego kodu, a do jego transportu czy samej infekcji wykorzystuje gotowe paczki, tzw. Exploit kity. Exploit kit ma za zadanie odnaleźć lukę w oprogramowaniu lub systemie operacyjnym i przez nią zainfekować stację złośliwym kodem.

Oprócz Exploit kitów pojawiają się gotowe usługi takie jak pakiet Philadelphia nazywany przez niektórych pierwszą usługą RaaS (Ransomware as a Service). Decydując się na ten pakiet, atakujący poza opracowanymi mechanizmami infekcji uzyskuje dostęp do narzędzi zarządzania czy wsparcia technicznego jego producentów.

Backup jest tylko jednym ze sposobów walki ze szkodliwym oprogramowaniem, o innych mechanizmach pisaliśmy jakiś czas temu przy okazji omawiania historii ransomware w tym artykule: Historia Ransomware

Dzięki zastosowaniu wirtualizacji rozszerzyły się możliwości w zakresie zarówno samego backupu, który stał się bardziej przystępny i prostszy, jak i odtwarzania danych, które jest znacznie przyjemniejsze niż w wypadku odtwarzania systemu na nowym serwerze sprzętowym. Przez kilka lat w FEN wykorzystywany był Veeam.

Backup w zależności od zawartości maszyny tworzony był do lokalnego repozytorium (macierz w RAID5+spare) lub poprzez wykorzystanie udziału iSCSI na zewnętrzny serwer, za który w tym wypadku służył QNAP TS-809U. Mechanizm sprawdzał się, jednak samo zarządzanie jak i konfiguracja repozytoriów do backupu mogłyby być rozwiązane lepiej.

Veeam funkcjonował jako aplikacja na serwerze Windows, co wymagało zainstalowania albo dodatkowej maszyny (dodatkowa licencja), albo znalezienia zasobów na istniejącym serwerze. Jednym z czynników który przyczynił się do poszukiwania innego rozwiązania były koszty utrzymania Veeam’a.

Jakiś czas temu FEN został dystrybutorem rozwiązania firmy NAKIVO, które jak się okazało, do zastąpienia Veeam’a nadaje się idealnie. Rozwiązanie jest licencjonowane na liczbę socketów (fizycznych gniazd CPU) w archiwizowanych serwerach. NAKIVO Backup&Replication to elastyczny system backupu dedykowany do tworzenia kopii zapasowych w środowiskach zwirtualizowanych, niezależnie od tego czy korzystamy z VMware, Hyper-V czy instancji wirtualnych w chmurze Amazon Web Services (AWS).

Dlaczego warto rozważyć NAKIVO jako swój mechanizm archiwizacji?:

1. Instalacja nie wymaga dodatkowego systemu operacyjnego pod NAKIVO. Maszynę do backupu możemy uruchomić jako GuestOS na swoim hypervisorze. Dodatkowo możemy wybrać jeden z kilku komponentów realizujących określone funkcje: jest dedykowany komponent do transportu informacji tzw. Transporter, jak i dedykowany komponent stanowiący repozytorium.Dzięki tej elastyczności poszczególne z komponentów można w złożonym środowisku rozdystrybuować na różnych serwerach. Inne opcje przewidują instalacje NAKIVO jako aplikacji dla Windows, lub dodatkowej usługi na przykład na serwerze NAS takim jak QNAP przy jednoczesnym wykorzystaniu magazynu QNAPa do przechowywania danych.
2. Zarządzanie jest super proste – nie potrzeba do tego żadnych dedykowanych aplikacji, czy wyszkolonego administratora – jeśli ktoś potrafi postawić maszynę np. na VMware ESXi, to poradzi sobie z NAKIVO – wystarczy przeglądarka internetowa, a konfiguracja to zaledwie kilka zakładek z opcjami do przeklikania.
3. Dla każdej maszyny można utworzyć do 1000 punktów przywracania, przy tworzeniu backupu wykorzystywane są mechanizmy Changed Block Tracking i Resilient Change Tracking, odpowiednio dla VMware i HyperV, gwarantujące, że przy backupie inkrementalnym przesyłane są tylko bloki danych które się zmieniły, co drastycznie zmniejsza ilość danych przesyłanych w trakcie backupów różnicowych i skraca ich czas.
4. W celu oszczędności przestrzeni dyskowej NAKIVO wyposażono w mechanizm deduplikacji – przy wystąpieniu dwóch takich samych bloków danych zapisywany jest tylko jeden, a następnie unikalne bloki danych są dodatkowo kompresowane co pozwala zaoszczędzić miejsce, na przykład by zachować więcej wersji zapasowych.
5. Rozwiązanie może pracować w trybie application aware, w którym wie z jakim systemem ma do czynienia i czego kopia zapasowa jest tworzona, dzięki temu nie trzeba się bać o spójność danych przy backupie takich systemów jak AD, Exchange, czy baz danych MS SQL lub Oracle. W przypadku systemów Windows wykorzystywany jest Microsoft VSS.
6. Po stworzeniu kopii zapasowej, NAKIVO może automatycznie zweryfikować poprawność backupu poprzez odtworzenie danej maszyny z wyłączonymi interfejsami sieciowymi, a na potwierdzenie podesłać w raporcie dla administratora zrzut ekranu z odtworzonej maszyny.

Gdy naprawdę potrzebujemy już coś odtworzyć to mamy szeroki wybór opcji, od obrazu całej maszyny, poprzez konkretne pliki, aż po obiekty w archiwizowanych bazach danych. Wszystko zależy od trybu w jakim backup był robiony i co aktualnie jest nam potrzebne.

Tyle teorii, jak wdrożenie NAKIVO wyglądało w praktyce? Po pierwsze ze strony https://www.nakivo.com pobieramy trial, duży zielony odnośnik, nie sposób przegapić:

Warto nadmienić, że NAKIVO jest rozwiązaniem popularnym zarówno wśród mniejszych firm, jak i korporacji – Coca-Cola, Honda, 3M to tylko niektóre z przykładów.

Po wypełnieniu formularza otrzymujemy dostęp do pobrania instalatora NAKIVO. Pobierana wersja zależy od tego na czym chcemy zainstalować nasze rozwiązanie backupu, dobrze jest mieć z czego wybrać.

W wypadku FEN wybrana została wersja dla Vmware. Dlaczego akurat ten wariant? Powód był prosty – dostępny był dodatkowy host ESXi z wbudowaną macierzą, wolnym miejscem, który się po prostu nudził. Dodatkową zaletą tego rozwiązania jest fakt, że maszyny można odtwarzać bezpośrednio na dodatkowego hosta, w razie awarii hosta głównego, wirtualki zarchiwizowane przez NAKIVO można odtworzyć na hoście zapasowym.

Wdrożenie na VMware opiera się na dodaniu do hosta dodatkowej maszyny wirtualnej (maszyna NAKIVO bazuje na Linksie, więc nie potrzebujemy licencji na OS). Podstawowe ustawienia jak adresacja IP, dostępne są przez konsolę dostępną z VCenter, a pozostałe zarządzanie to już interfejs www samej maszyny NAKIVO. Dla zainteresowanych szczegółami instalacji na VMware polecam ten przewodnik: Instalacja Nakivo na VMware

Dla posiadaczy QNAPów mamy gotowy artykuł naszego specjalisty od Storage, Łukasza Milica:

Instalacja Nakivo na QNAP

Gdyby ktoś NAKIVO chciał uruchomić jako aplikację na Windows,  to poniżej link do nagrania:

Instalacja Nakivo na Windows

Wróćmy do naszego wdrożenia, po dodaniu maszyny do VMware pozostaje przeklikać się przez interfejs:

1. Dodajemy VCenter (potrzebny będzie adres IP, nazwa użytkownika i hasło), a następnie wybieramy maszyny wirtualne które chcemy zarchiwizować.

2. Wybieramy repozytorium dla danych, w naszym wypadku, jako że NAKIVO nie zostało zainstalowane na głównym hoście, ale stanęło na osobnym hoście ESXi z macierzą, repozytorium danych było lokalne dla NAKIVO, dzięki temu backup jest robiony na zewnętrzny serwer, no i w razie awarii głównego hosta dane można odtworzyć na hosta zapasowego.

3. Ustalamy harmonogram backupu

4. Określamy ustawienia retencji, czyli przez ile czasu mamy utrzymywać kopie zapasowe i w ilu wersjach

5. Wybieramy dodatkowe opcje typu tryb application aware o którym wspominałem wcześniej, śledzenie zmian przez mechanizmy natywne dla hypervisora, ewentualnie decydujemy się na wykorzystanie akceleracji sieciowej (ważne gdy backup jest realizowany między lokalizacjami o ograniczonej przepustowości) oraz opcje weryfikacji backupu wraz z przesłaniem zrzutu ekranowego na email.

6. Dodatkowe ustawienia pozwalają zdecydować o raportowaniu zdarzeń związanych z backupem przez NAKIVO na wybrany adres email, czy wywołać skrypty przed lub po backupie, dzięki czemu dla bardzo specyficznych systemów możemy na przykład zablokować dostęp do aplikacji użytkownikom na czas backupu.

Informacje na temat wykonywanych backupów, takie jak podsumowanie, szczegółowe zdarzenia oraz alerty, wyświetlane są na dedykowanym panelu:

Co z przywracaniem maszyn? Może być tak samo prosto jak z backupem. W zakładce Recovery wybieramy maszynę, którą chcemy przywrócić i hosta, na którego będziemy ją odtwarzać. Wszystko zależy od tego w jakim wariancie dane chcemy przywrócić, dalszą pracę NAKIVO wykona samo. Wszystkie opcje przywracania opisane są tutaj: Opcje przywracania danych NAKIVO.

Celowo nie skupiałem się w tym artykule na technikaliach i szczegółowych ustawieniach, chciałem pokazać jak proste może być wdrożenie rozwiązania, które może przynieść oszczędności, zapewnić większe bezpieczeństwo i ułatwić pracę administratorom. Więcej o szczegółowej konfiguracji NAKIVO możecie przeczytać w kolejnym artykule: Konfiguracja NAKIVO + QNAP

Z czystym sumieniem i pełną odpowiedzialnością mogę powiedzieć, że FEN posiada w ofercie rewelacyjne rozwiązanie do backupu maszyn wirtualnych, które w pełni spełnia pokładane w nim oczekiwania. NAKIVO jest kolejnym elementem naszego portfolio, który nie tylko sprzedajemy, ale sami z niego korzystamy i jesteśmy z niego bardzo zadowoleni.