Disaster Recovery i backup na GCP
Nie pytaj, czy masz kopie, tylko czy na pewno się z nich odtworzysz
Backup, którego nigdy nie przetestowałeś, to nadzieja, nie zabezpieczenie. Wiele firm odkrywa to w najgorszym momencie: kopie są, ale odtworzenie nie działa, trwa za długo albo backup też padł ofiarą ataku. Disaster Recovery to coś więcej niż backup: to udowodniona, przetestowana zdolność powrotu do działania w czasie, który zaakceptujesz. Projektujemy DR i backup na GCP, dobierając wzorzec do Twoich realnych wymagań i odporności na ransomware.
RTO/RPO
punkt wyjścia każdej strategii
wzorce
dobór do wymagań i budżetu
immutable
kopie odporne na ransomware
testowane
udowodniona odtwarzalność
Masz backupy, ale nie wiesz, czy naprawdę odtworzysz z nich firmę, gdy przyjdzie kryzys
Większość firm ma jakieś kopie zapasowe. Problem w tym, że samo posiadanie backupu to złudzenie bezpieczeństwa. Liczy się, czy odtworzysz z niego działanie, jak szybko i czy backup w ogóle przetrwał atak. To pytania, na które wiele firm nie zna odpowiedzi, dopóki nie jest za późno.
Pewnie znasz przynajmniej jedną z tych sytuacji:
-
Masz backupy, ale nigdy nie testowałeś odtwarzania
Kopie się robią, ale nikt nie sprawdził, czy da się z nich realnie odtworzyć systemy, w jakim czasie i czy wszystko wstanie poprawnie. Backup nietestowany to backup, na którym nie możesz polegać. -
Nie wiesz, jak długo trwałoby odtworzenie po awarii
Gdyby kluczowy system padł teraz, ile czasu firma by stała? Godziny? Dni? Bez zdefiniowanego i przetestowanego RTO to loteria, a każda godzina przestoju kosztuje. -
Boisz się ransomware, który zaszyfruje też backupy
Ataki ransomware rosną lawinowo. Nowoczesny atak celuje nie tylko w produkcję, ale i w kopie zapasowe. Jeśli backup da się zaszyfrować lub usunąć, nie ochroni Cię w momencie, gdy najbardziej go potrzebujesz. -
Masz wymogi regulacyjne dotyczące ciągłości, których nie spełniasz
Regulacje jak DORA czy NIS2 wymagają udokumentowanych i przetestowanych planów ciągłości z określonymi RTO i RPO. Jeśli działasz w finansach albo jako podmiot istotny, brak takiego planu to ryzyko regulacyjne. -
Twoje stare systemy nie spełniają współczesnych wymogów odtwarzania
Backup oparty na wolnych, tradycyjnych procesach nie pozwala na szybkie odtworzenie ani nie chroni przed nowoczesnymi atakami. Stare podejście do backupu nie wystarcza w 2026.
Zaczynamy od RTO/RPO, dobieramy wzorzec i udowadniamy odtwarzalność testami
Dobry disaster recovery zaczyna się nie od technologii, tylko od dwóch pytań: ile czasu przestoju możesz znieść (RTO) i ile danych możesz stracić (RPO). Odpowiedzi różnią się dla różnych systemów, więc dobieramy wzorzec DR do każdego, balansując szybkość odtwarzania, koszt i ryzyko. A potem udowadniamy, że to działa, bo DR bez testów to tylko teoria.
Prowadzimy wdrożenie DR i backupu w pięciu krokach:
Analiza wpływu i definicja RTO/RPO
Identyfikujemy krytyczne systemy i definiujemy dla każdego RTO (akceptowalny czas przestoju) i RPO (akceptowalna utrata danych). Klasyfikujemy systemy według priorytetu: mission-critical wymaga innego podejścia niż środowisko testowe. To fundament całej strategii.
Dobór wzorca DR do każdego systemu
Dla każdego systemu dobieramy właściwy wzorzec: backup and restore (najtańszy, dla elastycznych wymagań), pilot light, warm standby (sub-godzinne RTO) lub active-active (near-zero downtime). Nie stosujemy jednego wzorca do wszystkiego, bo to albo przepłacanie, albo niewystarczająca ochrona.
Wdrożenie backupu i replikacji
Wdrażamy backup i replikację na Google Cloud (Backup and DR Service): niezmienne, nieusuwalne kopie w backup vault, replikacja między regionami, polityki backupu per priorytet systemu. Backupy nie tylko danych, ale i konfiguracji oraz definicji infrastruktury (jako kod).
Odporność na ransomware
Projektujemy ochronę pod nowoczesny model zagrożeń: niezmienne kopie (których atak nie zaszyfruje ani nie usunie), izolowane środowisko odtwarzania (IRE) do sprawdzenia, czy backup jest czysty przed przywróceniem do produkcji. To znaczy, że odtwarzasz dane, którym można zaufać.
Testy, orkiestracja i utrzymanie
Regularnie testujemy odtwarzanie (od tabletop po pełny failover), bo DR nietestowany to DR, którego nie masz. Orkiestrujemy failover i failback tak, żeby systemy wstawały w odpowiedniej kolejności zależności. Każdy test daje udokumentowane wyniki i poprawki.
Masz backupy, ale nigdy nie sprawdziłeś, czy się z nich odtworzysz?
Przeanalizujemy Twoją gotowość na awarię: jakie masz RTO/RPO, czy backupy są odporne na ransomware i czy odtwarzanie naprawdę działa. Pokażemy luki, zanim odkryje je kryzys.
RTO, RPO i cztery wzorce disaster recovery
Sednem disaster recovery jest dobór wzorca do realnych wymagań systemu. Nie ma jednego dobrego wzorca: jest właściwy dla danego RTO, RPO i budżetu. Oto cztery podejścia, od najtańszego do najszybszego.
01
Najpierw RTO i RPO
RTO (Recovery Time Objective) to maksymalny akceptowalny czas przestoju. RPO (Recovery Point Objective) to maksymalne okno utraty danych. Te dwie metryki definiują, czego potrzebujesz, i różnią się dla różnych systemów: system finansowy może wymagać RTO liczonego w minutach, a środowisko testowe w dniach. Od nich zaczynamy.
02
Backup and Restore
Regularne kopie, brak gotowej infrastruktury zapasowej, odtwarzanie od zera po awarii. Najwyższe RTO i RPO, najniższy koszt. Dla systemów, gdzie dłuższy czas odtwarzania jest akceptowalny. Backupy obejmują nie tylko dane, ale i konfiguracje oraz definicje infrastruktury.
03
Pilot Light
Minimalna wersja środowiska działa ciągle w drugim regionie: kluczowe komponenty (bazy danych) są replikowane, ale serwery aplikacji wyłączone. Przy awarii skalujesz uśpione zasoby. Odtwarzanie w minutach do godzin, przy umiarkowanym koszcie.
04
Warm Standby
W pełni funkcjonalna, ale zmniejszona replika produkcji działa ciągle w drugim regionie. Przy failover skalujesz ją do pełnej wydajności. Szybsze odtwarzanie niż pilot light (sub-godzinne RTO), wyższy koszt.
05
Multi-site active/active
Pełna produkcja działa jednocześnie w dwóch lub więcej regionach. Awaria jednego regionu jest obsługiwana przez pozostałe bez ręcznej interwencji. Near-zero downtime, ale najwyższy koszt (jak utrzymanie drugiego środowiska produkcyjnego). Dla systemów, które nie mogą stać ani chwili.
06
Dobór, nie jeden wzorzec dla wszystkich
Stosowanie jednego wzorca do całego środowiska to albo przepłacanie (active-active dla systemu, który może stać dzień), albo niewystarczająca ochrona (backup-restore dla systemu krytycznego). Dobieramy wzorzec per system, według jego RTO, RPO i wartości dla biznesu.
Ransomware zmienił reguły: backup musi przetrwać atak
To najważniejsza zmiana w myśleniu o backupie i DR. Tradycyjny backup projektowano pod awarie sprzętu. Dziś największym zagrożeniem jest ransomware, który celuje nie tylko w produkcję, ale i w kopie zapasowe. Backup, który da się zaszyfrować, nie ochroni Cię przed atakiem.
Skala zagrożenia
Ataki ransomware rosną lawinowo, a środowiska chmurowe nie są na nie odporne z definicji. Nowoczesny atak szuka i szyfruje także backupy, żeby uniemożliwić odtworzenie i wymusić okup. To znaczy, że sam fakt posiadania kopii nie wystarcza.
Niezmienne kopie (immutable)
Projektujemy backupy jako niezmienne i nieusuwalne: raz zapisana kopia nie może być zaszyfrowana ani skasowana, nawet przez atakującego z dostępem do systemu. Atakujący nie zniszczą danych, do których nie mogą się dostać. To fundament odporności na ransomware.
Izolacja i air-gap
Kopie przechowywane w izolowanym backup vault, w osobnym koncie lub regionie, odłączone od głównej sieci. To dodatkowa warstwa, która sprawia, że atak na produkcję nie sięga kopii.
Czysty backup przed przywróceniem (IRE)
Najgorszy scenariusz to przywrócenie backupu, który sam zawiera ukrytego ransomware. Dlatego używamy izolowanego środowiska odtwarzania (Isolated Recovery Environment): przywracamy backup w odizolowanym środowisku, sprawdzamy go narzędziami bezpieczeństwa i dopiero czysty przywracamy do produkcji. Odtwarzasz dane, którym można zaufać.
Dlaczego DR bez testów to DR, którego nie masz
Można mieć świetnie zaprojektowany DR i wciąż nie być chronionym, jeśli się go nie testuje. To najczęściej pomijany element, a decydujący o tym, czy DR zadziała, gdy będzie potrzebny.
Testowanie udowadnia odtwarzalność
Backup i plan DR to teoria, dopóki nie udowodnisz, że działają. Testujemy odtwarzanie regularnie: od ćwiczeń teoretycznych (tabletop) po pełne symulacje failover. Krytyczne systemy testujemy częściej. Każdy test daje udokumentowane wyniki i konkretne poprawki, więc plan staje się coraz pewniejszy, zamiast leżeć w szufladzie nieaktualny.
Orkiestracja failover i failback
Odtworzenie to nie tylko przywrócenie danych, ale uruchomienie systemów w odpowiedniej kolejności zależności (najpierw bazy, potem aplikacje, potem warstwa dostępu). Orkiestrujemy failover (przełączenie na zapas) i failback (powrót po ustąpieniu awarii), żeby wszystko wstawało spójnie, a nie w chaosie.
Compliance: DORA, NIS2
Regulacje coraz częściej wymagają udokumentowanych i przetestowanych planów ciągłości z określonymi RTO i RPO. DORA (dla podmiotów finansowych) i NIS2 (dla podmiotów istotnych) nakładają takie obowiązki. Projektujemy DR tak, żeby nie tylko chronił biznes, ale i spełniał wymogi regulacyjne, z dokumentacją, której wymaga audyt.
DR jako ciągły proces
Disaster recovery to nie jednorazowy projekt, tylko proces, który ewoluuje wraz z infrastrukturą i biznesem. Nowe systemy, zmiany, nowe zagrożenia. Plan trzeba aktualizować i regularnie testować, dlatego oferujemy prowadzenie DR na bieżąco.
Dlaczego warto zaprojektować DR i backup z 7Technology
Zaczynamy od RTO/RPO, nie od narzędzia
Projektujemy DR od pytania, ile przestoju i utraty danych możesz znieść, a potem dobieramy wzorzec do każdego systemu. To znaczy, że nie przepłacasz za ochronę, której nie potrzebujesz, ani nie zostajesz z niewystarczającą tam, gdzie liczy się każda minuta.
Projektujemy pod ransomware, nie tylko pod awarie sprzętu
Niezmienne kopie, izolacja, sprawdzanie backupu w izolowanym środowisku przed przywróceniem. Projektujemy DR pod nowoczesny model zagrożeń, w którym backup też jest celem ataku, a nie pod wczorajsze ryzyka.
Udowadniamy odtwarzalność testami
Nie zostawiamy Cię z planem, którego nikt nie sprawdził. Testujemy odtwarzanie regularnie, dokumentujemy wyniki i poprawiamy plan. Bo backup, którego nie przetestowałeś, to nadzieja, nie zabezpieczenie.
Rozumiemy wymogi regulacyjne
DORA, NIS2 i inne regulacje wymagają udokumentowanych, przetestowanych planów ciągłości. Projektujemy DR tak, żeby spełniał te wymogi, z dokumentacją gotową na audyt, co jest kluczowe dla firm w regulowanych branżach.
Zostajemy i prowadzimy DR dalej
DR to ciągły proces, nie jednorazowy projekt. W modelu Managed Services GCP prowadzimy go na bieżąco: aktualizujemy plan, testujemy regularnie, monitorujemy backupy, żeby ochrona była aktualna, gdy naprawdę jej potrzebujesz.
Co mówią o nas klienci
"Migracja produkcyjnego SAP była dla nas projektem o najwyższym ryzyku. 7Technology przeprowadziło nas przez nią bez ani jednego nieplanowanego przestoju."
Lucyna Michniewicz
CIO @ VOX
"Szukaliśmy partnera, który weźmie odpowiedzialność za całość, a nie odeśle nas do kolejnego podwykonawcy. Po kilku latach współpracy wiem, że trafiliśmy dobrze."
Edyta Sapijaszko
CIO @ Herbapol
"Automatyzacja procesów na WEBCON BPS zdjęła z naszych zespołów dziesiątki godzin pracy ręcznej miesięcznie. Wdrożenie poszło sprawnie i zgodnie z planem."
Magdalena Obidowska
Project Manager @ Oceanic
Projekty, za które wzięliśmy odpowiedzialność
Środowisko IT dealera Mercedes-Benz w Google Cloud
Migracja kluczowych systemów biznesowych do chmury, a następnie przejęcie i integracja środowiska IT nowego salonu w Sosnowcu - bez przerwy w pracy sprzedaży i serwisu.
System:
Środowisko IT - ok. 55 systemów (m.in. ERP, DMS, systemy kadrowo-płacowe i księgowe, SAP)
Technologia:
Google Cloud Platform, Terraform, SAP
Kluczowe osiągnięcia:
Jedno środowisko dla 5 lokalizacji; przejęcie salonu bez przestoju
Automatyzacja sortowania półtusz w chłodni
Decyzję o przydziale półtuszy do zamówienia zamiast operatora podejmuje algorytm, a rozjazdy na torach przestawiają się same - na podstawie sześciu parametrów każdej sztuki.
System:
System MES 7Technology + dedykowany moduł automatyzacji chłodni
Technologia:
RFID w hakach, sterowniki PLC, integracja z wagami i klasyfikacją mięsności
Kluczowe osiągnięcia:
Kilku pracowników na zmianę → 1 operator; reakcja na zmianę zamówienia w kilka sekund
Od papierowych kart do pełnej identyfikowalności z 7MES
Wdrożenie objęło cały zakład - od rampy przyjęć, przez rozbiór i produkcję, po kontrolę załadunku pod dokiem - z pełną genealogią każdej partii.
System:
7MES (autorski system klasy MES 7Technology)
Technologia:
Comarch ERP XL, wagi hakowe / najazdowe / stanowiskowe / laboratoryjne, skanery i terminale dotykowe
Kluczowe osiągnięcia:
Kompletacja krótsza o 4–5 godzin; genealogia partii od ręki zamiast w dni
Cztery lata cyfryzacji na WEBCON BPS, SAP i AI
Kilkanaście procesów w WEBCON zintegrowanych z SAP, a najnowszy etap zamienił ponad 40 000 dokumentów surowcowych w przeszukiwalną bazę wiedzy dla działu badań.
System:
WEBCON BPS + SAP (moduły FI i MM)
Technologia:
WEBCON BPS, SAP Gateway (OData, REST API), Google Cloud (Gemini, BigQuery, Looker Studio), OCR, KSeF, Autenti
Kluczowe osiągnięcia:
Wyszukiwanie surowca z 2–4 godzin do poniżej 30 sekund
Powiązane technologie i usługi
Technologie:
Usługi
Konsultacje:
Często zadawane pytania o disaster recovery i backup na GCP
Backup to kopia danych. Disaster recovery to udowodniona, przetestowana zdolność powrotu do działania po awarii, w określonym czasie. Backup jest częścią DR, ale samo posiadanie kopii nie wystarcza: liczy się, czy odtworzysz z niej działanie, jak szybko (RTO), ile danych stracisz (RPO) i czy backup przetrwał atak. DR to całościowa zdolność odtworzenia firmy, nie tylko danych.
To dwie kluczowe metryki DR. RTO (Recovery Time Objective) to maksymalny akceptowalny czas przestoju, czyli jak długo system może być niedostępny. RPO (Recovery Point Objective) to maksymalne okno utraty danych, czyli ile ostatnich danych możesz stracić. Różnią się dla różnych systemów: krytyczny system finansowy może wymagać RTO w minutach, a środowisko testowe w dniach. Od ich zdefiniowania zaczyna się każda strategia DR.
Zależy od RTO, RPO i budżetu danego systemu. Backup and restore (najtańszy, najwolniejszy) dla elastycznych wymagań. Pilot light (replikowane dane, wyłączone aplikacje) dla odtwarzania w minutach-godzinach. Warm standby (zmniejszona, działająca replika) dla sub-godzinnego RTO. Multi-site active/active (pełna produkcja w wielu regionach) dla near-zero downtime, ale najdrożej. Dobieramy wzorzec per system, nie jeden dla wszystkich.
Tylko jeśli jest właściwie zaprojektowany. Nowoczesny ransomware celuje też w backupy, więc zwykła kopia może zostać zaszyfrowana razem z produkcją. Ochronę dają niezmienne kopie (immutable, których nie da się zaszyfrować ani usunąć), izolacja (osobne konto, region, air-gap) i sprawdzanie backupu w izolowanym środowisku przed przywróceniem, żeby nie przywrócić ukrytego ransomware. To projektujemy jako standard.
To odizolowane środowisko, w którym przywracamy backup i sprawdzamy go narzędziami bezpieczeństwa, zanim przywrócimy go do produkcji. Chroni przed najgorszym scenariuszem: przywróceniem kopii, która sama zawiera ukrytego ransomware. Dzięki IRE odtwarzasz dane, co do których masz pewność, że są czyste.
Tak, to absolutnie kluczowe. DR bez testów to DR, którego de facto nie masz, bo nie wiesz, czy zadziała. Backup może być uszkodzony, odtwarzanie może trwać dłużej niż zakładasz, systemy mogą wstawać w złej kolejności. Testujemy regularnie (od ćwiczeń teoretycznych po pełny failover), dokumentujemy wyniki i poprawiamy plan. Krytyczne systemy testujemy częściej.
Tak. Regulacje jak DORA (dla podmiotów finansowych) i NIS2 (dla podmiotów istotnych) wymagają udokumentowanych i przetestowanych planów ciągłości z określonymi RTO i RPO. Projektujemy DR tak, żeby spełniał te wymogi, z dokumentacją gotową na audyt. Dla firm w regulowanych branżach to nie tylko ochrona biznesu, ale i zgodność z prawem.
Zależy od wzorca, wolumenu danych i wymagań RTO/RPO. Backup and restore to najtańsza opcja, a multi-site active/active może kosztować jak utrzymanie drugiego środowiska produkcyjnego. Klucz to dobór wzorca do wartości systemu: nie przepłacać za ochronę, której nie potrzebujesz, ani nie oszczędzać tam, gdzie przestój kosztuje fortunę. Koszt DR jest zwykle ułamkiem kosztu jednego dnia nieplanowanego przestoju.
DR to ciągły proces, nie jednorazowy projekt. Infrastruktura i biznes się zmieniają, dochodzą nowe systemy i zagrożenia, więc plan trzeba aktualizować i regularnie testować. W modelu Managed Services GCP prowadzimy DR na bieżąco: aktualizujemy plan, przeprowadzamy testy, monitorujemy backupy, żeby ochrona była aktualna i sprawdzona, gdy naprawdę jej potrzebujesz.
