Wpierwszej części artykułu poruszyłem kwestie związane z przyczynami utraty danych i sytuacji (dramatycznej i niebezpiecznej) w firmach sektora SMB. Dramatycznej – bo większość firm nie jest w żaden sposób zabezpieczona przed utratą danych albo stosowane metody backupu są „pseudobackupem”, „drutowaniem” uspokajającym jedynie głowy osób (nie)odpowiedzialnych za IT. Niebezpiecznej – gdyż, de facto, każdy incydent może skończyć się brakiem możliwości odtworzenia danych, o ciągłości pracy organizacji nie wspominając.
Jaki powinien być system backupowy?
– Automatyczny (czyli powinien wykonywać się samodzielnie, bez ingerencji użytkownika / administratora, tak, żeby ograniczyć do zera czynnik ludzki związany z uruchomieniem wykonywania backupu);
– Konfigurowany czasowo (czyli z możliwością ustalenia, jak często, w jakich porach ma się odbyć – innego podejścia wymaga baz a SQL z systemu ERP, a innego zdjęcia ze stacji roboczej);
– Zapewniający retencję (czyli ilość kopii zapasowych danych – czy ma być to 30 kopii czy 7 kopii), co jest istotne zwłaszcza, gdy chcemy uchronić dane przed kryptolokerem, a ostatnia kopia niekoniecznie zapewni odczytywalność zbackupowanych danych (bo kryptoloker mógł te dane już zaszyfrować);
– Szyfrowany na wyjściu z backupowanego urządzenia (przykładowo algorytmem AES i kluczem 256 bitów tak, aby mieć pewność, że nikt nieuprawniony nie jest w stanie sprawdzić zawartości kopii zapasowej – czy to na docelowym nośniku, czy podczas transmisji);
– Efektywny pod względem wykorzystania łącza i storage (czyli taki, który kompresuje dane podczas transmisji i zapisu, ale także taki, który nie powoduje każdorazowego wykonywania pełnej kopii danych, a jedynie bloki/elementy, które uległy zmianie – np. przyrostowy / różnicowy);
– Pozwalający na automatyczne stosowanie zasady 3…2…1.. – hybrydowy – pozwalający na wykonanie kopii zapasowej np. na lokalnym urządzeniu, a dodatkowo w chmurze (albo na taśmach LTO) wg ustalonej polityki backupu;
– Wieloobiektowy – umożliwiający wykonywanie backupu różnych obiektów – począwszy od plików i folderów, przez bazy danych (bez konieczności zatrzymywania silnika bazy danych i pracy danego systemu), skrzynek poczty elektronicznej (czyli backup granularny), poprzez całe maszyny (czy to fizyczne, czy wirtualne);
– Bardziej „ekstrawagancki” – taki, który posiada łatwą możliwość odtwarzania poszczególnych elementów obiektów (np. pojedynczych plików z maszyny wirtualnej, pojedynczej wiadomości pocztowej czy pojedynczych rekordów z bazy danych);
– Pozwalający na odtworzenie środowiska na innej maszynie fizycznej (przykładowo pracujemy na serwerze HP model x, backupujemy całe środowisko, ale jesteśmy w stanie przywrócić je na innym urządzeniu (np. serwerze Dell model y);
– Inteligentny – potrafiący wyłączyć urządzenie po wykonaniu backupu (np. stację roboczą) albo też taki, w którym jesteśmy w stanie określić wydajność szyfrowania danych – np. na słabszej stacji – mniejszą, co nie zablokuje działania komputera, a wręcz stanie się niewidoczne dla użytkownika.
Jak można ogólnie skategoryzować backup danych?
Backup danych krytycznych
Jako dane krytyczne rozumieć należy dane, od których zależy „życie” organizacji – a więc dane systemów finansowo-księgowych, „całych” ERPów, CRM, poczty elektronicznej itd. W tym przypadku backup powinien być „w miarę” częsty. Jak częsty – to zależy od ilości krytycznych danych i profilu działalności organizacji. Warto zadbać o backup całych serwerów fizycznych i wirtualnych tak, aby móc szybko przywrócić działanie tychże systemów w przypadku incydentu.
Backup stacji roboczych / danych mniej krytycznych
Rzadko wykonywany – wg badań, tylko co 25 stacja robocza backupowana jest w sposób automatyczny. Do backupu stacji roboczych idealnie nadaje się backup w chmurze, do którego wrócę za chwilę, zwłaszcza w przypadku pracowników mobilnych. Ze stacji roboczych najczęściej wykonuje się kopie plików i folderów, danych lokalnej skrzynki pocztowej.
Backup telefonów komórkowych
Na telefonach komórkowych też mamy szereg danych – oczywiście najbardziej sensowny jest backup w chmurze, czy to za pomocą aplikacji producenta telefonu, teleoperatora czy też inną. Co ważne, warto sprawdzić dokąd wysyłane są nasze dane – powinny być przesyłane do DC na ternie EU.
Jaki backup – lokalny czy w chmurze? A może hybryda?
Zalety backupu lokalnego – zazwyczaj szybkość wykonywania i odtwarzania. Tak więc najczęściej backup lokalny powinien być wybierany w organizacjach, gdzie wykonuje się backup całych maszyn wirtualnych i/lub dużej ilości danych, a także tam, gdzie łącze internetowe jest „takie sobie”.
Dlaczego backup w chmurze i dlaczego tak?
O chmurze wszyscy mówią, ale nikt jej nie widział. Gdy zapytać przedstawicieli sektora SMB, czy używają chmury, 99 proc. procent mówi nie, ale jeśli zaczniemy zadawać pytania czy korzystają z gmaila, poczty na Onecie albo dropboxa lub innego rozwiązania do przechowywania zasobów w chmurze, to jednak wychodzi na to, że chmura znana jest dla większości przedsiębiorców.
Co ciekawe, gdy zaczyna się rozmawiać o backupie w chmurze (rozumianej jako proces automatyczny, szyfrowany i w pełni profesjonalny) to większość przedstawicieli tego sektora wyciąga kilkanaście argumentów przeciw. Poniżej postaram się rozwiać większość wątpliwości backupu w „cloudzie”
Dlaczego backup w chmurze?
Po pierwsze profesjonalne Data Center gwarantuje dużo bardziej bezpieczną infrastrukturę niż zazwyczaj dana organizacja, zwłaszcza z sektora MSP, jest w stanie zapewnić. Mało która firma może sobie pozwolić na tego typu zabezpieczenia (zabezpieczenia fizyczne, redundantne nośniki, systemy zasilania gwarantowanego, kilku niezależnych operatorów łącz telekomunikacyjnych i prądu). Co ważne, backup znajduje się w innych lokalizacjach niż przedsiębiorstwo (brak narażenia na kradzież nośników kopii zapasowych czy pożaru). Praktycznie wszyscy znaczący producenci rozwiązań backupowych mają swoje centra danych na ternie Unii Europejskiej. Centra danych zazwyczaj są klasy Tier3, a sama infrastruktura zaprojektowana przez prawdziwych specjalistów.
Po drugie przechowywane dane są zaszyfrowane, zaś dane są zaszyfrowane już na wyjściu z urządzenia, z którego wykonywany jest backup. Zazwyczaj stosowany jest klucz 256 bitów i algorytm AES, który jest nie do złamania przy obecnym rozwoju technologii.
Po trzecie backup w chmurze jest zabezpieczeniem danych backupów przed kryptolokerami. Nie mają oni dostępu do plików backupu, zaś rozwiązania lokalne bardzo często narażone są na zaszyfrowanie backupów (ponieważ lokalizacja backupów często zmapowana jest jako kolejny dostępny wolumin serwerowy albo dostępna wprost w sieci lokalnej)
Po czwarte to oszczędność czasu: natychmiastowa dostępność kopii zapasowych w przypadku incydentu (przykładowo względem rozwiązań w technologii LTO), duża przewaga nad skryptami tworzącymi pełne kopie zapasowe (ze względu na ilość backupów, czas wykonania, zajętość powierzchni – backup przyrostowy-różnicowy, dowolna retencja). Całość przekłada się więc też na kilkukrotne zmniejszenie czasu zarządzania procesami tworzenia kopii zapasowych.
Po piąte Backup w chmurze to idealny sposób tworzenia kopii zapasowych pracowników mobilnych. Backup możne się wykonywać z dowolnego miejsca, gdzie jest Internet. Nie potrzeba VPN, jak w przypadku rozwiązań lokalnych, nie trzeba o nim pamiętać (żeby połączyć się z centralą przez ów VPN).
Po szóste, bardzo ważne – aspekt kosztowy. Backup w chmurze jest dostępny dla każdego przedsiębiorstwa i cechuje go brak jednorazowej inwestycji rzędu min. kilku tysięcy złotych na sprzęt i licencje. Tutaj mamy zazwyczaj subskrypcje miesięczne. Nie ma kosztów związanych z używaniem taśm (taśmy, składowanie, przechowywanie, transport). Z rozwiązania chmurowego można zawsze wyjść bez ponoszenia dodatkowych kosztów.
Po siódme to łatwość skalowania rozwiązania: organizacja rośnie, a co za tym idzie – rosną wymagania / powierzchnie. Nie ma konieczności planowania powierzchni dyskowej na backupy i jednocześnie mamy dowolność zmian polityki backupowej i nie ma pytań: co zrobić z niewystarczającym sprzętem
O czym warto pamiętać przy tworzeniu polityki backupu?
– O harmonogramie backupu – żeby np. systemy tworzenia kopii zapasowych nie uruchamiały się jednocześnie blokując ruch w sieci lokalnej czy też globalny, aby też nie był wykonywany w momencie gdy np. dany system jest najbardziej obciążony,
– Retencji backupu – ile backupów „trzymamy” i gdzie (chmura, lokalnie),
– Jak często wykonujemy pełne kopie danych, a co jakiś czas backup przyrostowy czy różnicowy.
Pamiętaj, że tylko twardziele nie robią backupu, tak więc w przypadku swoich danych – lepiej być mięczakiem.