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.