Q1: Czy możliwa jest zmiana kluczy szyfrujących zastosowanych do zaszyfrowania bloków danych "zdeponowanych" w repozytorium Sejfu Danych?
A1: Klucze szyfrujące nadawane podczas instalacji oprogramowania klienckiego poziomu L1 kolektora (DS-Mobile, DS-Client itp.) służą do zaszyfrowania repozytorium backupu wykonanego z poziomu każdej indywidualnej instalacji wspomnianego oprogramowania klienckiego. Dodatkowo kluczami tymi są szyfrowane metadane zapisywane w lokalnych bazach danych tych instalacji. Do momentu potrzeby ponownej instalacji oprogramowania klienckiego (np. w przypadku realizacji procedur DR) operator backupu nie jest zmuszany do podawania kluczy szyfrujących. Aby wymusić zmianę kluczy szyfrujących backupowane dane wykonuje się reinstalację oprogramowania klienckiego co jest szybkie i łatwe ze względu na możliwość zaimportowania poprzedniej pełnej konfiguracji oprogramowania (również zadań backupu i polis retencji). Trzeba mieć na uwadze fakt, że dostęp do danych zabezpieczonych w systemie jest możliwy tylko po podaniu dwóch kluczy szyfrujących - jednego wspólnego dla całej organizacji oraz drugiego - związanego z indywidualną instalacją oprogramowania klienckiego (oczywiście operator musi posiadać jeszcze określoną rolę w systemie - co pozwala niezależnie od cyklicznej zmiany kluczy szyfrujących również wymuszać cykliczną zmianę haseł ograniczających dostęp do oprogramowania). Dlatego też w praktyce wystarczy zmiana tylko klucza szyfrującego indywidualnego, dzięki czemu zmiana taka nie ma negatywnego wpływu na deduplikację globalną głównego repozytorium. Dostęp do poprzedniej wersji backupów - zaszyfrowanych poprzednim kluczem szyfrującym odbywa się z poziomu poprzedniej instalacji oprogramowania klienciego (którą mozna przetrzymywać np. w formie gotowej maszyny wirtualnej "na boku" lub też w formie instalacji ad-hoc).
Q2: Oprogramowanie realizuje tzw. "Incremental backup forever" - czy obciąża LAN podczas skanowania zasobów podlegających procesowi backupu?
A2: Podczas wykonywania backupu plików - również w przypadku wykorzystania funkcjonalności "Continuos Data Protection" - wykorzystywane są wbudowane w systemy operacyjne mechanizmy pozwalające ograniczyć potrzebę skanowania plików które nie uległy zmianie - Windows Built-in File Monitoring (platforma Windows) oraz File Alteration Monitor (platforma Linux). Zastosowana technologia minimalizuje potrzebę dostępu do plików podczas wykonywania ich backupów ograniczając ten dostęp tylko do plików zmodyfikowanych. Niezależnie od powyższego, operator zadania backupu może wymusić backup wszystkich plików bez względu czy się one zmieniły czy też nie - jednak do głównego repozytorium backupu (poziom L2 - Recovery) przesłane są tylko delty (na poziomie plików i bloków) wyliczone w stosunku do poprzednio wykonanych backupów zachowując optymalizację łącza WAN. O spójność tak przesłanych danych dbają mechanizmy wyznaczania sygnatur plików i bloków jak również wbudowane mechanizmy autonomic-healing.
Q3: Jak jest realizowana bezagentowość - jakie wymogi muszą być spełnione po stronie źródła danych?
A3: Oprogramowanie klienckie poziomu L1 kolektorów (DS-Mobile, DS-Client itp.) wykonując bezagentowy backup zasobów widocznych w sieci LAN wykorzystuje standardowe protokoły przewidziane przez producentów backupowanych źródeł wykorzystując API oraz transmisję TCP/IP. Wspomniane oprogramowanie klienckie działa jak dowolny klient serwera plików, bazy danych itd. wykorzystując znane "standardy przemysłowe". Ewentualne oprogramowanie firewall zainstalowane po stronie źródła musi zezwolić na transmisję do/z oprogramowania klienckiego poziomu L1.
Q4: Czy jest możliwe celem zminimalizowania ruchu sieciowego LAN wykorzystanie bezpośredniego połączenia z kolektorami (poziom L1) z zasobami storage, np. via SAN?
A4: TAK. Oprogramowanie klienckie na kolektorach pozwala zarówno backupować bezagentowo zasoby poprzez sieć LAN, jak również zasoby widoczne lokalnie na serwerze na którym jest ono zainstalowane. Pozwala to zatem na dostęp do backupowanych zasobów via SAN - również z wykorzystaniem snapschotów oferowanych przez producentów storage (obecnie oprogramowanie zawiera wbudowany mechanizm współpracy z macierzami NetApp ale jest możliwe wykorzystanie mechanizmów API do współpracy z innymi producentami).
W przypadku środowiska VMware możliwe są trzy tryby dostępu do backupowanych maszyn wirtualnych - via LAN, via SAN oraz Hot-Add (gdy oprogramowanie klienckie poziomu L1 zainstalowane jest na maszynie wirtualnej). Również podczas odtwarzania maszyn dostępne są w/w metody dostępu do zasobów widziane przez serwery ESX.
Q5: Na rynku można spotkać oprogramowanie pozwalające automatycznie przetestować poprawność pracy zbackupowanych maszyn wirtualnych. Czy Asigra pozwala zautomatyzować takie procesy?
A5: Wspomniane oprogramowanie automatyzuje proces sprawdzenia poprawności wykonania backupu i odtworzenia tylko środowiska wirtualnego. Sprawdzenie to opiera się na uruchomieniu zbackupowanej maszyny wirtualnej (np. bezpośrednio z repozytorium backupu) oraz uruchomieniu skryptów mających na celu przetestowanie poprawności działania wybranych usług. Należy zwrócić jednak uwagę na fakt, że metoda taka ma duże ograniczenia - dotyczy tylko maszyn wirtualnych (najczęściej z systemem operacyjnym Windows) i w praktyce nie potwierdza poprawności tak odtworzonych danych a jedynie poprawne funkcjonowanie usługi (teoretycznie możliwe jest napisanie np. skryptu czytającego całą bazę danych ale w praktyce będzie to często nie wykonalne ze względu na czasochłonność takiego procesu). Proces takiego automatycznego testu może również zaburzać możliwość przeprowadzania w tle procesów backupu pozostałych maszyn wirtualnych lub właśnie testowanej. Asigra posiada wbudowane dwa mechanizmy weryfikacji poprawności przechowywania i przetwarzania backupów - Autonomic Healing oraz Validation Restore. Validation Restore wykonywany na żądanie administratora backupu (również w sposób zapisany w harmonogramie) pozwala potwierdzić 100% odtwarzalność danych wskazanych do przetestowania - niezależnie od tego czy są to dane bazy danych, serwery pocztow, plików, całe maszyny wirtualnej czy np. aplikacja SAP. Administrator w sytuacji wystąpienia jakiegoś problemu otrzymuje informację czego on dotyczy a system stara się poradzić sobie z tą sytuacją żądając np. ponownego wykonania backupu "uszkodzonego" elementu w trakcie wykonywania zaplanowanego przez administratora następnego zadania backupu. Dla środowisk VMware zaimplementowana jest funkcja automatyki inkrementalnego odtwarzania maszyn wirtualnych w DRC (poziom L2) z możliwością ich autommatycznego włączenia. Jest to funkcjonalność mająca na celu skrócenie czasu odtworzenia środowiska produkcyjnego w ośrodku DRC, ale można ją również wykorzystać do zautomatyzowania procesu testowania poprawność zachowania się usług serwowanych przez odtwarzane maszyny.
Q6: Czy do backupu komputerów i urządzeń przenośnych oprogramowania, istnieje centralna konsola do zarządzania wykonywanymi backup'ami tak ażeby ograniczyć do minimum ingerencję użytkownika końcowego w proces backupu?
A6: TAK. Jedna centralna konsola opeatorska pozwala na zarządzanie polisami backupu i retencji, konfiguracją oprogramowania klienckiego oraz przeglądem aktywności, logów (również ze strony oprogramowania klienckiego).
Q7: Jakie są mechanizmy pozwalające uprościć proces instalacji oprogramowania klienckiego oraz jego ewentualny upgrade/update ?
A7: Oprogramowanie klienckie typu DS-Mobile (usługa zabezpieczenia urządzeń mobilnych) można przygotować w formie paczek msi z wybraną przez administratora informacją konfiguracyjną (można np. pozostawić użytkownikowi tylko potrzebę wpisania własnego klucza szyfrującego, albo pozostawić całą instalację w trybie "silent"). Tak spreparowane paczki msi można wykorzystać do instalacji oprogramowania np. poprzez polisy Active Directory czyniąc cały proces przeźroczystym dla użytkownika końcowego.
Niezależnie od podanej powyżej możliwości każdą instalację oprogramowania klienckiego poziomu L1 (np. DS-Mobile, DS-Client) można skonfigurować od strony centralnej konsoli operatorskiej upraszczając proces instalacji do minimum. Aktualizacja wersji wspomnianego oprogramowania odbywa się automatycznie w trakcie połączenia oprogramowania klienckiego poziomu L1 z głównym repozytorium backupu (poziom L2 - DRC).
Q8: Jaka jest różnica pomiędzy usługą zabezpieczenia urządzeń mobilnych - End-Point a zabezpieczeniem zasobów serwerowych do DRC?
A8: W obydwóch przypadkach występuje jeden lub więcej głównych repozytoriów backupu (poziom L2) zlokalizowanych w prywatnej lokalizacji klienta lub też w Data Center (np. na oferowanych przez nas zasobach). Do tego głównego repozytorium w przypadku usługi zabezpieczenia urządzeń mobilnych trafiają zaszyfrowane i przetworzone bloki danych przygotowane przez oprogramowanie klienckie poziomu L1 zainstalowane na chronionym urządzeniu. W przypadku zabezpieczenia zasobów serwerowych do głównego repozytorium trafiają zaszyfrowane i przetworzone bloki danych zgromadzone przez oprogramowanie klienckie poziomu L1 (DS-Client) pełniące funkcje kolektora zbierającego dane z chronionych serwerów - w sposób bezagentowy - pozwalając tym samym na współistnienie z istniejącymi u klienta innymi systemami backupu.
Q9: Co to jest kolektor L1(lokany) dla usługi zabezpieczenia zasobów serwerowych do DRC? Czym różni się ono od wersji stosowanej w usłudze zabezpieczenia urządzeń mobilnych?
A9: Oprogramowanie poziomu L1 dla usługi zabezpieczenia zasobów serwerowych zainstalowane na dedykowanej maszynie fizycznej, maszynie wirtualnej bądź w postaci oferowanego przez nas gotowego appliance, realizuje autonomiczną politykę backupu określoną przez administratorów, wykonuje backupy oraz odtworzenia jednocześnie przesyłając zaszyfrowaną i przetworzoną "sieczkę" bloków danych do głównego repozytorium backupu (poziom L2) zlokalizowanego najcześciej w odległym DRC. Jednocześnie kolektor sam w sobie jest może być lokalnym repozytorium backupu. Dzięki takiemu podziałowi możliwa jest realizacja dowolnego scenariusza Disaster Recovery - repozytorium backupu znajdując się w miejscy przetważania oraz w miejscu oddalonym - chroniąc przed utratą danych w przypadku utraty nawet całej źródłowej lokalizacji . Wersja oprogramowania klienckiego oferowanego dla zabezpieczenia urządzeń mobilnych (np. DS-Mobile) to pomniejszona wersja wspomnianej wcześniej "dużej" instalacji serwerowej ograniczona do backupu tylko zasobów pochodzących ze stacji roboczych (ewentualnie smartfonów i tabletów).
Q10: Co się stanie z moimi danymi przechowywanymi w repozytorium backupu jeśli nie przedłużę umowy na korzystanie z usług Sejfu Danych?
A10: Jeśli klient wykorzystywał własną instalację we własnej serwerowni, to oczywiście dane będą w dalszym ciągu w niej zgromadzone - klient aby móc z nich skorzystać będzie musiał się zgłosić do Sejfu Danych lub naszego Partnera o umożliwienie dostępu "tylko do odczytu" za symboliczną opłatą (może to być od razu ustalone w trakcie procesu rezygnacji z kontynuacji korzystania z umowy). Jeżeli jednocześnie będzie chciał jeszcze coś zapisać w repozytorium (dodatkowe dane) to Sejf Danych będzie mógł mu udzielić odpłatnie na określony czas licencję "czasową" pozwalającą na wykonanie tego typu operacji. W sytuacji gdy repozytorium będzie umiejscowione w zasobach chmury, Klient może wygenerować dysk na zewnętrzny nośnik ze swoimi danymi. Musi to zrobić sam np. zdalnie ( żaden zewnętrzny administrator nie ma dostępu do jego danych) a Sejf Danych lub partner mogą przygotować i dostarczyć zewnętrzne nośniki. Może pozwolić umowie wygasnąć, wtedy po upływie terminu wyznaczonego, konto zostanie skasowane i dane bezpowrotnie utracone. Może również zlecić przechowywanie repozytoriów backupu w chmurze - jako dodatkową usługę.
Q11: Stosuję rozwiązanie do backupu maszyn wirtualnych z poziomu hypervisora z którego jestem zadowolony (Veeam Backup & Recovery). Czy jest sens ażebym wykorzystywał dodatkowo oprogamowanie Asigra dostarczane przez Sejf Danych?
A11: Obydwa rozwiązania się nie wykluczają - wręcz przeciwnie - mogą bardzo dobrze się uzupełniać. Backup wykonywany "od dołu" z poziomu hypervisora (oferowany również przez nasz system) ma wiele zalet - "kompaktowość" backupu (administrator nie martwi się o to co jest w środku), łatwość odtworzenia, oraz w większości przypadków również wysoka sprawność procesu backupu i odtwarzania. Jednak do stosowania oferowanych mechanizmów backupu maszyn wirtualnych nie można podchodzić bezkrytycznie - główny problem to konsystencja tak wykonywanego backupu - w przypadku maszyn wirtualnych wyposażonych w OS Microsoft Windows i mechanizm VSS wspierany przez VSS writer'y zainstalowane dla wsparcia aplikacji typu MS-SQL, MS-Exchange, MS-SharePoint mozemy być pewni że wykonane w ten sposób backupy (o ile prawidłowo wykonywane są snapschoty - z wykorzystaniem VSS-writer) będą konsystentne - zaimplementowane pod potrzeby danej aplikacji VSS-writer'y zadbają o to ażeby wykonać "flush" pamięci w momencie wykonywania snapschota maszyny na potrzeby wykonania backupu - wspomniany "flush" w przypadku np. MS-SQL oznaczać będzie zamknięcie transakcji i zrzucenie danych z cache na dysk. W pozostałych przypadkach - a więc gdy brak wsparcia od strony aplikacji dla VSS (nie ma zainstalowanych lub wręcz przewidzianych przez producenta aplikacji VSS-writer'ów), lub też gdy mówimy o OS'ach innych niż Microsoft Windows - konsystentny backup dla maszyn wirtualnych serwujących usługi on-line (np. bazodanowe) wymaga wygaszenia funkcjonowania tych usług poprzez ich np. wyłączenie i ponowne włączenie (skryptami) - a więc spowodowanie zauważalnej przerwy w świadczeniu usług. W przeciwnym wypadku podczas odtworzenia maszyny wirtualnej z backupu otrzymamy wersję maszyny której "podczas działania ktoś wyłączył prąd" - backup wykonany w ten sposób zachowuje jedynie to co zostało zapisane na dysku, a więc nie będzie zawierał nie zamkniętych transakcji które były przechowywane w pamięci RAM (a obecnie takich danych ze względów wydajnościowych cache'owanych jest coraz więcej). Drugim problemem związanym z backupem "od dołu" maszyn wirtualnych jest ich niska granularnośc - w najlepszym przypadku jesteśmy w stanie zbackupować wybrane dyski z całej maszyny wirtualnej - ale nic poza tym - oznacza to że tą samą technologię (a więc i koszty) musimy zastosować do wszystkich danych zgromadzonych na maszynie wirtualnej - bez względu na to czy sa to binaria, pliki użytkowników czy też ważne bazy danych. Dodatkowo, stosowana w VMware technologia CBT nie zawsze musi korzystnie wpływać na szybkość wykonania backupu, a sam fakt korzystania z niej oraz trwania backupu (podczas którego rozrasta się plik składujący zapisy zmian - snapschot) negatywnie wpływa na wydajność storage wykorzystywanego przez backupowaną maszynę wirtualną co najczęściej również ma wpływ na pracę innych maszyn wirtualnych. Rozwiązaniem tego problemu jest stosowanie backupu hybrydowego - a więc stosowania backupu "od dołu" tam gdzie nie wpływa to negatywnie na konsystencję danych oraz wydajność samej maszyny wirtualnej - np. raz na dzień albo nawet raz w tygodniu - w przypadku np. maszyn bazodanowych będą to dyski OS + binaria oraz drugiego backupu - od strony aplikacji (np. backup bazy danych) jako głównego backupu który zabezpieczy dane krytyczne wykonywanego np. co godzinę dla zachowania minimalnego RPO. Tak więc posiadając system backupu maszyn wirtualnych można pomyśleć o wdrożeniu backupu hybrydowego, którego druga część - aplikacyjna będzie wykonywana przez oprogramowanie Sejfu Danych zapewniając 100% konsystentność przechowywanych backupów oraz bardzo dużą granularność zarówno procesu backupu jak i odtworzenia co pozwoli w sytuacji krytycznej na skócenie czasu RTO (administrator realizując zapisaną w procedurach DR kolejność odtworzeniową może podzielić dane na bardziej i mniej ważne).
Q12: Wydaje się że ażeby zapewnić pełną konsystentność backupu maszyny wirtualnej dowolnego systemu operacyjnego (bez wykorzystania Microsoft VSS writer) wykonego "od dołu" wystarczy podczas wykonywania snapschotu zaznaczyć opcję "memory" - w ten sposób można obejść problem opisany w A11.
A12: Po pierwsze - nie każde oprogramowanie do backupu maszyn wirtualnych posiada tę opcję. Po drugie - wybranie tej opcji oznacza że podczas procesu zamrażania maszyny na dysk (jako uzupełnienie danych które się na nim znalazły przed wykonaniem snapschotu) zostaje zapisana cała zawartość wykorzystanego przez maszynę wirtualną RAM'u. Z podobną sytuacją mamy do czynienia podczas wykonywania np. VMware vmotion - z tą różnicą że w tym przypadku nie jest to kopiowanie "RAM to RAM", tylko "RAM to disk" a więc proces ten będzie trwał dużo dłużej - oznacza to w praktyce że już dla maszyn wyposażonych w 4GB będzie to proces odczuwalny przez użytkowników korzystających z maszyny wirtualnej jako jej totalne zamrożenie (hyperwisor ażeby nie dopuścić do generowania przez system kolejnych zmian w RAM i ażeby nie zapętlić tym samym procesu "zrzutu" pamięci - wstrzymuje na pewien czas zegar vCPU). O ile można sobie wyobrazić wykonywanie tego typu backupów w czasie poza normalną pracą systemu (np. godziny nocne), to w praktyce jest to procedura niedopuszczalna dla sytuacji produkcyjnej pracy systemu i serwowania usług - a to oznacza że nie można w praktyce zaimplementować częstego wykonywania backupów - w trakcie normalnej pracy użytkowników celem minimalizacji parametru RPO a więc zminimalizowania ilości utraconych danych.