Czy kopia zapasowa (backup) to ratunek od przestoju?

Czy kopia zapasowa (backup) to ratunek od przestoju?

Po co nam usługi disaster-recovery, przecież my nie żyjemy w Ameryce. W końcu jakie jest prawdopodobieństwo katastrofalnego zdarzenia, które akurat zniszczy nasz budynek? Uwielbiam taką retorykę! A już Albert Einstein mówił: „Wyobraźnia jest ważniejsza od wiedzy, ponieważ wiedza jest ograniczona”. Proponuję zatem nieco poszerzyć nasze horyzonty i rozważyć, czy rzeczywiście w każdym przypadku dobrze wykonany backup to ratunek od przestoju.

Skojarzenie dotyczące katastrof najczęściej bierze się z rozdzielnego tłumaczenia wyrazów „disaster” i „recovery”. Wówczas krążymy wokół zdarzeń kategorii: tornado, upadek statku powietrznego, pożar czy powódź. Tymczasem już Google Translator to zestawienie wyrazów tłumaczy jako: „odzyskiwanie po awarii”. A że awaria me wiele imion i zwykle wydarzy się w najgorszym momencie, to i jest miejsce na rozważania czy ten firmowy backup to na pewno odpowiedź na każdą sytuację. Odpowiedź oczywiście jest przecząca.

Pora na konkrety. Kiedy zdecydowanie potrzebujesz usług disaster-recovery:

  1. Jeśli przetwarzasz dane we własnej serwerowni, która nie spełnia standardu Uptime Institute Tier II lub ANSI/TIA-942 Tier 2.
  2. Gdy nie dublujesz kluczowej infrastruktury (serwery, przełączniki) i nie stosujesz mechanizmów wysokiej dostępności (high availability).
  3. Gdy sprzęt, którego używasz ma więcej niż 3 lata i jest już po gwarancji.
  4. Jeśli Twój kontrakt serwisowy z dostawcą przewiduje naprawę lub wymianę w następnym dniu roboczym (np. 8x5xNBD).
  5. Jeśli godzinna przerwa w dostępności choćby jednego serwera jest biznesowo nie do zaakceptowania.
  6. Jeśli nie masz własnego zespołu IT lub masz tylko jednego fachowca.
  7. Gdy nie masz ubezpieczenia typu business interruption rozszerzonego o systemy IT i dane[1].
  8. Jeśli przywracanie z kopii zapasowej krytycznego serwera zajmuje kilka godzin.

Nawet jeśli tylko jeden z punktów pasuje do sytuacji jaką masz w firmie, powinieneś poważnie rozważyć usługi z zakresu disaster-recovery, np. DRaaS. Jeśli pasujących punktów jest więcej (wyłączając oczywiście pkt. 5 i 7), wówczas ryzyko wystąpienia przestoju jest bardzo wysokie. Kopia zapasowa jest niezbędna, jednak nie przywróci normalnego funkcjonowania, gdy pojawi się problem sprzętowy. W takiej sytuacji potrzebny jest szybki start na innym sprzęcie np. w zapasowej lokalizacji lub w chmurze publicznej dostawcy nawet w ciągu 15 minut.

[1] na dzień pisania tego artykułu w Polsce nie znalazłem takiej oferty.

Planowanie odtwarzania po awarii – 7 grzechów głównych

Planowanie odtwarzania po awarii – 7 grzechów głównych

Jako samozwańczy „ewangelista” z zakresu ciągłości działania – czuję się usprawiedliwiony sięgając po katechizm 😉 Nie będę jednak prawił kazań. Opowiem tylko o typowych błędach jakie towarzyszą planowaniu odtwarzania po awarii, pamiętając przy tym o lekkostrawnej formie.

    1. Pycha. Nam się nic nie przytrafi. Zadziwiająco często spotykam menadżerów którzy jak mantrę powtarzają: „Przecież nigdy się to nie zdarzyło, po co więc chronić się przed takim ryzykiem?” Wtedy zalecam BIA (Analiza wpływu na biznes), która wprost odpowiada na pytanie czy warto czy też nie.
    2. Chciwość. Ta inwestycja nie przyniesie pieniędzy. Biznes nie lubi inwestować gdy nie widzi policzalnych zwrotów. Ciągłość działania porównać można do polisy ubezpieczeniowej, gdzie nakłady to koszt. Niestety, nie wiadomo, czy zaangażowane środki się zwrócą – czyli czy na przykład dzięki nim uratujemy organizację od przestoju. Pozostaje chłodna analizy ryzyk i ich wpływu na biznes oraz kosztów przestoju.
    3. Nieczystość. Nadmiarowość to nie odtwarzanie po awarii. Posiadanie klastra wysokiej dostępności, wyeliminowanie pojedynczych punktów awarii infrastruktury czy świetnie zabezpieczone centrum danych to solidny fundament ciągłości działania. Nie jest to jednak ochrona przed każdym ryzykiem. Przeciętny informatyk wyrwany ze snu bez wahania wskaże kilka scenariuszy, które zatrzymają IT Twojego przedsiębiorstwa.
    4. Zazdrość. Pomijanie właścicieli procesów. Zapominamy, lub co gorsza nie chcemy włączyć do planowania wszystkich interesariuszy. To strzał w kolano. Bez ich wiedzy nie będzie skutecznego odtworzenia po awarii.
    5. Nieumiarkowanie. Wszystko jest krytyczne. Klasyka. Zwykle, gdy zespół IT arbitralnie decyduje o tym, jakie zasoby mają być zabezpieczone na wypadek awarii, mamy sytuację, w której zasoby centrum zapasowego równe są zasobom centrum podstawowego.
    6. Gniew. Dlaczego działa tak wolno? Aspekt wydajności środowiska zapasowego jest częstym zarzewiem konfliktów wewnętrznych i zewnętrznych. Pamiętajmy, że to proteza, niezbędna do czasu powrotu stanu normalnego. Mamy podtrzymać procesy krytyczne. Poza tym testujmy praktycznie nasz plan odzyskiwania po awarii.
    7. Lenistwo. Zbytnie zaufanie do dostawcy DRaaS. Odtwarzanie po awarii jako usługa wymaga zaangażowania każdej strony umowy. Dostawca odpowiada za technologię i zasoby po swojej stronie. My natomiast, zadbajmy o uruchomienia testowe czy też cykliczne aktualizujmy plan odtwarzania po awarii. Przy okazji, zmianie może ulec zapotrzebowanie na zasoby dostawcy.

Czy DRCaaS = DRaaS? Zapasowe centrum danych

Czy DRCaaS = DRaaS? Zapasowe centrum danych

Disaster Recovery Center lub zamiennie DR Site, to po prostu zapasowe centrum danych. Miejsce w którym utrzymujemy sprzęt podobny lub tożsamy z tym z ośrodka podstawowego. Idea jest taka, aby w razie awarii podstawowego centrum danych możliwie szybko uruchomić nasze systemy i aplikacje z ośrodka zapasowego. Dodawanie do DRC czy do DRS członu „as a service” (jako usługa), oznacza, że może chodzić o DRC w wirtualnym wydaniu.

No dobrze, co to oznacza? Przyjmijmy, że mamy dostawcę, który oferuje nam Zapasowe Centrum Danych. Zazwyczaj jest to kawałek miejsca w szafie lub wiele szaf zlokalizowanych w Centrum Danych. Miejsce to, z natury rzeczy spełnia określone kryteria jakości usług. Głównie chodzi o nadmiarowość wszelkich systemów, poczynając od chłodzenia, zasilania, gaszenia, a na przyłączach telekomunikacyjnych i energetycznych kończąc. W klasycznym podejściu instalujemy tam nasze serwery. Oznacza to jednak, że dublujemy naszą infrastrukturę. Możemy „zaoszczędzić” decydując się na odwzorowanie częściowe, tylko dla zasobów krytycznych. W takim przypadku mamy zarówno koszty inwestycji jak i powiększone koszty operacyjne, bo trzeba płacić za miejsce w centrum danych dostawcy.

Innym rozwiązaniem jest DRCaaS lub DRSaaS. Różnica w stosunku do DRC/DRS polega na tym, że dostawca daje nam zasoby sprzętowe w postaci wirtualnych przydziałów w ramach własnych zasobów fizycznych. I tak, zamiast serwera otrzymujemy wirtualny serwer, zamiast przełącznika – przełącznik wirtualny, itd. Całość zasobów z naszego ośrodka podstawowego odwzorowujemy w przydzielonym przez dostawcę środowisku. Zwykle dostawcy oddają nam interfejs, dzięki któremu informatycy mogą zbudować zapasowe środowisko samodzielnie.

No i na deser odpowiedź na pytanie z tytułu, czy DRCaaS = DRaaS? Otóż nie – to są różne, choć funkcjonalnie podobne usługi. DRC jako usługa, to takie wirtualne centrum danych, które konfigurujemy na przykład dla potrzeb disaster recovery, ale nie tylko. Tymczasem DRaaS to usługa skupiona przede wszystkim na utrzymaniu ciągłości działania wirtualnego środowiska IT klienta. Zwykle usługa jest łatwa w implementacji, gdyż bazuje na znanej technologii najczęściej powiązanej z tą, używaną w środowisku informatycznym klienta. Obie usługi są też zwykle inaczej rozliczane. Na koniec można napisać, że DRaaS może być częścią usługi DRCaaS, ale nie na odwrót.

Co to jest DRaaS? Kopia zapasowa czy coś więcej?

Co to jest DRaaS? Kopia zapasowa czy coś więcej?

W wolnym tłumaczeniu – odtwarzanie po katastrofie jako usługa. Wiem, to nadal tylko definicja, w dodatku mało trafna. Disaster-recovery as a Service, to w istocie usługa zapewnienia ciągłości działania systemów informatycznych serwowana przez zewnętrznego dostawcę. Usługa jest doskonałym substytutem zapasowego centrum danych (DRC).

Chodzi o to by zabezpieczyć całą maszynerię, a nie tylko chronić dane. Jeśli w serwerowni poleje się woda albo pojawi się ogień (a to naprawdę się zdarza), wówczas sam fakt posiadania kopii zapasowych nie pozwoli nam wystartować od razu. Zdarzenie, które uszkodzi nam sprzęt, wymusza naprawę, co zazwyczaj oznacza wymianę albo zakup. Gwarancja producenta tu nie pomoże. Co wtedy? Wtedy jest różnie, zespół IT próbuje na szybko załatwić „pożyczaka”, no i szukamy substytutów, np. chmury. Tyle, że jeśli nigdy nie spisaliśmy procedury, to działania będą chaotyczne i stracimy mnóstwo czasu. A w tym przypadku czas to pieniądz. Warto wcześniej przygotować organizację na działanie w warunkach awaryjnych. Ja, w tym zakresie namawiam do outsourcingu, bo w ten sposób wstrzykujemy naszej organizacji zweryfikowany know-how i nie ponosimy inwestycji.

Jak działa DRaaS? Mamy dwie główne składowe usługi: replikację oraz serwery wirtualne. Replikacja czyli nieustanne kopiowanie zapewnia niejako odwzorowanie naszych systemów i danych na serwerach przydzielonych nam przez dostawcę DRaaS. Obrazy wędrują w zadanych interwałach czasowych lub po każdej zmianie. Serwery wirtualne czekają na sytuację w której będą potrzebne. Dostawca rezerwuje/gwarantuje nam odpowiednie konfiguracje, zgodne ze źródłem, oraz zasoby sieciowe. I teraz, gdy mamy solidny kryzys w naszej serwerowni sami decydujemy o przełączeniu. Nasze konfiguracje, dane i aplikacje wystartują w centrum danych dostawcy. Do aplikacji dostawać się będziemy bezpiecznymi kanałami VPN, łącząc się poprzez Internet, np. z domu. Można także zapewnić tymczasowe miejsce pracy dla zespołu, ośrodki szkoleniowe mają dobrą ofertę. Na koniec, jeszcze „tylko” trzeba wrócić, do stanu sprzed awarii.

Czy DRaaS zastępuje backup? Nie, w żadnym wypadku! Backup, czyli kopie bezpieczeństwa to podstawa, a DRaaS to następny krok.

Chętnie poznam Wasze definicje DRaaS, gdyż ciągle szukam zgrabnej formułki. Zachęcam do lektury wpisu: czy każdej organizacji potrzebne jest zapasowe centrum danych.