Firma ma 15 laptopów, NAS z 4 TB przestrzeni i Microsoft 365. Właściciel mówi: „chcę backup wszystkiego”. To jeszcze nie jest wymaganie techniczne. Dopóki nie wiadomo, ile danych firma może stracić, jak szybko muszą wrócić do pracy i które systemy są krytyczne, nie da się uczciwie dobrać ani narzędzia, ani retencji, ani ceny usługi.

Najczęstszy błąd pojawia się właśnie tutaj: instalowany jest agent, zadanie świeci się na zielono i temat uznaje się za zamknięty. Tymczasem klient nie płaci za to, że program przesłał pliki do repozytorium. Płaci za możliwość odzyskania ich po awarii dysku, kradzieży laptopa, przypadkowym usunięciu katalogu czy ataku ransomware.

Dlatego profesjonalna usługa backupu zaczyna się od projektu odzyskiwania danych. Sam backup jest dopiero jego częścią.

Audyt, RPO i RTO: najpierw policz, co naprawdę trzeba odzyskać

Na początku nie interesuje mnie marka programu backupowego. Najpierw trzeba ustalić, co jest chronione, jak często i w jakim czasie ma wrócić do działania.

Weźmy niewielką firmę:

• 15 laptopów,

• około 600 GB istotnych danych lokalnych na komputerach,

• NAS z 3,2 TB zajętej przestrzeni,

• 400 GB danych w Microsoft 365,

• łącze internetowe 300/100 Mb/s,

• księgowość, która nie akceptuje utraty całego dnia pracy.

Pierwsze pytanie dotyczy RPO, czyli maksymalnej akceptowalnej utraty danych.

Jeżeli dział księgowy może stracić najwyżej godzinę pracy, RPO dla jego danych powinno wynosić maksymalnie 1 godzinę. Backup wykonywany raz na dobę nie spełnia tego wymagania, nawet jeżeli działa bezbłędnie od dwóch lat.

Dla archiwum zamkniętych projektów sytuacja może wyglądać inaczej. Jeśli pliki zmieniają się sporadycznie, RPO 24 godziny może być zupełnie wystarczające. Nie ma sensu chronić każdego zasobu tak samo. Częstszy backup zwiększa liczbę punktów odzyskiwania, obciążenie infrastruktury i koszt przechowywania.

Drugie pytanie dotyczy RTO, czyli czasu, w którym firma chce odzyskać możliwość pracy.

Tutaj szybko wychodzą na jaw nierealne oczekiwania.

500 GB danych przesyłanych przy rzeczywistej prędkości 150 Mb/s potrzebuje teoretycznie około 7 godzin i 25 minut samego transferu. Do tego dochodzą przygotowanie środowiska, zapis na dysk, weryfikacja danych i uruchomienie aplikacji.

Jeżeli klient w takiej sytuacji wymaga RTO na poziomie 4 godzin, nie można po prostu wpisać czterech godzin do umowy. Trzeba zmienić architekturę.

Jeszcze mocniej widać to przy NAS-ie. Przesłanie 4 TB przez łącze o uploadzie lub downloadzie 100 Mb/s wymaga teoretycznie prawie 89 godzin ciągłego transferu. W rzeczywistym środowisku będzie trwało dłużej. Protokół, inne usługi korzystające z łącza, obciążenie urządzeń i ograniczenia po stronie dostawcy zabierają część przepustowości.

Jeżeli taki NAS musi wrócić do pracy w kilka godzin, sama kopia w chmurze nie wystarczy. Potrzebne jest lokalne, niezależne repozytorium pozwalające na szybki restore, a chmura powinna pełnić funkcję dodatkowej kopii poza lokalizacją.

To właśnie jest różnica między kupowaniem „backupu w chmurze” a projektowaniem usługi odzyskiwania.

Audyt powinien objąć co najmniej:

• wszystkie komputery i serwery,

• maszyny wirtualne,

• NAS-y i udziały sieciowe,

• bazy danych,

• Microsoft 365 lub Google Workspace,

• aplikacje branżowe,

• dane znajdujące się wyłącznie na laptopach,

• aktualną ilość danych i ich przyrost,

• upload i download,

• urządzenia pracujące poza biurem,

• wymagane RPO i RTO,

• kolejność odzyskiwania systemów,

• obecny sposób szyfrowania i przechowywania kluczy.

W uporządkowanej firmie z 10–30 stanowiskami pierwszy audyt może zamknąć się w kilku godzinach. Nie traktowałbym jednak „2–4 godzin” jako stałej normy. Firma z serwerem SQL, maszynami wirtualnymi, oddziałami i aplikacją zależną od Active Directory wymaga zupełnie innej analizy niż 15 laptopów i jeden udział sieciowy.

Dobrym punktem wyjścia do projektowania architektury pozostaje 3-2-1-1-0:

• 3 – dane produkcyjne i co najmniej dwie dodatkowe kopie,

• 2 – różne warstwy lub sposoby przechowywania,

• 1 – kopia poza podstawową lokalizacją,

• 1 – kopia offline, odseparowana lub niezmienna,

• 0 – brak niewykrytych błędów, potwierdzony weryfikacją i testami odzyskiwania.

Nie traktowałbym jednak samego spełnienia tej zasady jako dowodu bezpieczeństwa. Można mieć trzy kopie w dwóch lokalizacjach i nadal stracić wszystko, jeżeli wszystkie repozytoria da się usunąć jednym przejętym kontem administratora.

Podobnie z retencją. 30, 90 czy 365 dni nie jest wartością dobrą z definicji.

Załóżmy, że ransomware działało niezauważone przez 21 dni. Część plików była stopniowo szyfrowana, a backup każdego dnia poprawnie kopiował ich zaszyfrowane wersje.

Przy siedmiodniowej historii możesz nie mieć już czystego punktu odzyskiwania.

Dlatego retencję dobiera się do:

• prawdopodobnego czasu wykrycia problemu,

• wartości danych,

• wymagań biznesowych,

• wymaganych historycznych wersji,

• obowiązków organizacji,

• kosztu przestrzeni.

Przykładowa polityka może utrzymywać punkty godzinowe z ostatniej doby, 30 kopii dziennych oraz 12 punktów miesięcznych. To przykład konstrukcji, nie recepta dla każdej firmy.

Ten sam sposób myślenia trzeba zastosować do laptopów. Jeżeli urządzenie ma RPO 24 godziny, informacja „nie zrobiło backupu od 48 godzin” jest już incydentem. Czekanie arbitralnie 14 dni nie ma sensu. Przy laptopie handlowca, który pojawia się w biurze dwa razy w miesiącu, trzeba natomiast zaprojektować backup przez Internet i ustalić zachowanie agenta na wolnym, taryfowym lub niestabilnym połączeniu.

Komputery, NAS, serwery i chmura wymagają różnych sposobów odzyskiwania

W jednej ofercie można chronić laptopy, NAS, serwer i Microsoft 365, ale nie powinno się wrzucać ich do jednego worka pod nazwą „backup”.

Komputer pracownika może wymagać tylko odzyskania dokumentów albo pełnego przywrócenia systemu wraz z aplikacjami. To dwie różne usługi.

Jeżeli obiecujesz klientowi wyłącznie ochronę danych użytkownika, okresowy test odzyskania katalogu i kilku losowo wybranych plików ma sens.

Jeżeli sprzedajesz możliwość odtworzenia całej stacji po awarii SSD, samo sprawdzenie dokumentu Worda jest za mało. Trzeba okresowo zweryfikować obraz systemu albo proces bare-metal recovery. W przeciwnym razie zakres testu nie odpowiada zakresowi obietnicy.

Przy NAS-ie najczęściej spotykam inne nieporozumienie: snapshot jest nazywany backupem.

Snapshot może być świetnym elementem ochrony. Pozwala bardzo szybko wrócić do wcześniejszej wersji danych i często daje znacznie lepsze RTO niż pobieranie kilku terabajtów z Internetu. Jeżeli jednak snapshot znajduje się wyłącznie na tym samym urządzeniu, nie chroni przed każdym scenariuszem utraty NAS-u.

Awaria kontrolera, kradzież urządzenia, pożar albo skuteczny atak na warstwę administracyjną może pozbawić firmę danych produkcyjnych i snapshotów jednocześnie.

Dla ważnego NAS-u stosowałbym więc trzy warstwy:

1. lokalne snapshoty do szybkiego cofnięcia zmian,

2. niezależne lokalne repozytorium do szybkiego odzyskania większej ilości danych,

3. kopię poza lokalizacją, najlepiej z ochroną przed natychmiastowym usunięciem.

Trzeba też wykonać backup konfiguracji samego urządzenia. Odzyskanie 3 TB plików niewiele daje, jeżeli nikt nie pamięta struktury udziałów, uprawnień, ustawień sieciowych i konfiguracji usług.

Serwery i maszyny wirtualne wymagają jeszcze innego podejścia.

Zielony status zadania nie oznacza, że aplikacja jest możliwa do uruchomienia.

Serwer może odtworzyć się poprawnie, a system biznesowy nadal nie ruszy, ponieważ:

• baza danych jest niespójna,

• nie działa DNS,

• niedostępny jest kontroler domeny,

• brakuje certyfikatu,

• zmieniła się licencja,

• aplikacja oczekuje innego serwera,

• konto usługi nie ma już właściwych uprawnień.

Dlatego przy serwerach znaczenie ma backup świadomy aplikacji, a test powinien obejmować uruchomienie systemu w odseparowanym środowisku i sprawdzenie faktycznej usługi, a nie tylko obecności plików na dysku.

Dobrze jest rozdzielić testy na trzy poziomy:

Poziom 1 – kontrola zadania
Czy backup zakończył się bez błędu i powstał nowy punkt odzyskiwania?

Poziom 2 – kontrola danych
Czy można odzyskać wskazany katalog, bazę albo kilka losowych plików i czy ich zawartość jest prawidłowa?

Poziom 3 – kontrola usługi
Czy można uruchomić odtworzony serwer, zalogować się do aplikacji i wykonać podstawową operację biznesową?

Przy trzecim poziomie zapisuję czas. Jeżeli umowa zakłada RTO 4 godziny, test powinien odpowiedzieć, czy osiągnięto 4 godziny, a nie tylko czy „restore zakończył się powodzeniem”.

Protokół takiego testu może zawierać:

• datę,

• użyty punkt recovery,

• godzinę rozpoczęcia,

• czas przygotowania restore,

• czas transferu,

• moment uruchomienia systemu,

• wynik testu aplikacji,

• zmierzone RTO,

• wykryte błędy,

• działania do wykonania przed następnym testem.

Osobną kategorią jest Microsoft 365 i Google Workspace.

Nie wystarczy powiedzieć, że „chmura ma własny backup” albo odwrotnie – że „Microsoft 365 nie ma backupu”. Obie odpowiedzi są zbyt proste.

W Microsoft 365 trzeba rozróżnić zwykłe mechanizmy odzyskiwania, wersjonowanie, kosze, polityki retencji oraz odrębną usługę Microsoft 365 Backup. W sierpniu 2026 r. Microsoft oferuje ją jako usługę rozliczaną według chronionej zawartości, z ceną katalogową 0,15 USD za GB miesięcznie.

Microsoft 365 Backup chroni OneDrive, SharePoint i Exchange Online. Dla pełnego przywracania OneDrive i SharePoint punkty z ostatnich dwóch tygodni mogą mieć rozdzielczość 10 minut, a dla starszego okresu dostępne są punkty tygodniowe. Exchange Online zachowuje 10-minutową częstotliwość punktów również dla starszego okresu. Okno odzyskiwania można obecnie konfigurować m.in. na 3 miesiące, 6 miesięcy, rok lub dwa lata.

To zmienia sposób rozmowy z klientem. Pytanie nie brzmi „czy Microsoft robi backup?”, tylko:

Czy zakres, retencja, sposób odzyskiwania, koszt i zależność od tego samego ekosystemu odpowiadają wymaganiom firmy?

Jeżeli nie, można zastosować niezależne rozwiązanie backupowe. To samo podejście obowiązuje przy Google Workspace: najpierw sprawdza się możliwości konkretnej usługi i planu, a dopiero potem decyduje, czy potrzebna jest dodatkowa warstwa ochrony.

Najbardziej krytyczny fragment całego projektu dotyczy jednak dostępu do kopii.

Niezmienność danych jest ważna, ale sama nie wystarczy. Warstwa backupowa powinna być projektowana tak, aby przejęcie zwykłego konta administracyjnego nie dawało automatycznie możliwości zniszczenia całej historii.

W praktyce oznacza to:

• MFA,

• osobne konta do administracji backupem,

• zasadę najmniejszych uprawnień,

• oddzielenie poświadczeń produkcyjnych od backupowych,

• Object Lock lub podobną ochronę niezmienności tam, gdzie jest dostępna,

• kontrolę operacji destrukcyjnych,

• rejestrowanie zmian polityk,

• alerty dotyczące usuwania kopii,

• szyfrowanie.

Dobry test jest prosty: atakujący przejmuje konto administratora domeny. Czy z tego samego konta może zalogować się do systemu backupowego i skasować wszystkie punkty odzyskiwania?

Jeżeli tak, architektura wymaga poprawy.

Drugi problem to klucze szyfrujące. Zaszyfrowany backup, którego nie da się odszyfrować po odejściu administratora, jest praktycznie tak samo użyteczny jak uszkodzony backup.

Trzeba więc ustalić:

• kto kontroluje klucz lub hasło,

• gdzie znajduje się awaryjna kopia danych dostępowych,

• kto może uruchomić recovery,

• czy usługodawca jest w stanie odtworzyć dane bez udziału klienta,

• co stanie się po zakończeniu współpracy,

• jak odzyskać dostęp po utracie konta administratora.

Monitoring też nie może ograniczać się do tabeli „zielone/czerwone”.

Przy obsłudze firmy chcę widzieć przynajmniej:

• nieudane zadanie,

• zadanie zakończone ostrzeżeniem,

• przekroczone RPO,

• brak kontaktu z agentem,

• kończącą się przestrzeń,

• nieoczekiwany wzrost ilości kopiowanych danych,

• zmianę lub usunięcie polityki,

• próbę usunięcia punktów recovery,

• nieudany test odzyskiwania.

Nagły skok ilości zmienionych plików również zasługuje na uwagę. Może oznaczać normalną migrację danych, ale może też być jednym z pierwszych sygnałów masowego szyfrowania.

Jak wycenić usługę, żeby pierwszy duży restore nie zjadł całej marży

Najgorszy model sprzedażowy wygląda tak: klient płaci miesięcznie za „nielimitowany backup”, a usługodawca dopiero podczas awarii odkrywa, ile kosztuje przestrzeń, transfer, licencje i kilkanaście godzin pracy administratora.

Cena usługi powinna wynikać z kosztów oraz deklarowanego poziomu obsługi.

Do kalkulacji trzeba włączyć:

• licencje backupowe,

• przestrzeń lokalną,

• przestrzeń chmurową,

• liczbę chronionych urządzeń,

• przyrost danych,

• wymaganą retencję,

• monitoring,

• czas administratora,

• testy odzyskiwania,

• raportowanie,

• obsługę incydentów,

• wymagane RTO,

• zakładaną marżę.

Samo stwierdzenie „klient ma 4 TB danych” nadal nie mówi, ile zajmie repozytorium backupowe.

Załóżmy uproszczony przykład.

Komputery i NAS mają łącznie 3,8 TB danych źródłowych, a każdego dnia powstaje średnio 44 GB nowych lub zmienionych danych, które trzeba zachować przez 30 dni.

W najbardziej uproszczonym modelu:

3,8 TB + 30 × 44 GB = około 5,12 TB danych przechowywanych po miesiącu.

To nadal nie jest dokładna prognoza dla konkretnego programu. Deduplikacja, kompresja, synthetic full, sposób liczenia wersji i usuwania punktów recovery mogą mocno zmienić wynik. Ten przykład pokazuje natomiast, dlaczego nie wolno liczyć rachunku dla backupu jako „3,8 TB źródła = 3,8 TB w chmurze”.

Na 25 sierpnia 2026 r. Backblaze B2 startuje od 6,95 USD za TB miesięcznie. Przy 5,12 TB daje to około:

5,12 × 6,95 USD = 35,58 USD miesięcznie.

Wasabi Hot Cloud Storage Pay-Go kosztuje obecnie 7,99 USD za TB miesięcznie:

5,12 × 7,99 USD = 40,91 USD miesięcznie.

W Wasabi trzeba dodatkowo uwzględnić minimum rozliczeniowe 1 TB oraz 90-dniowy minimalny okres przechowywania obiektów w modelu Pay-Go. Usunięcie danych przed upływem tego okresu nie oznacza automatycznie, że przestają generować koszt.

W Backblaze B2 nie ma analogicznego minimalnego okresu przechowywania w podstawowym modelu B2. Nie oznacza to jednak, że jeden dostawca zawsze będzie tańszy. Przy większym recovery trzeba brać pod uwagę również zasady transferu, integrację z używanym oprogramowaniem, zachowanie Object Lock oraz sposób rozliczenia całej usługi.

Koszt chmury jest przy tym tylko jedną pozycją. Często nie największą.

Przykład wyceny usługi najlepiej budować od czasu pracy, a nie od arbitralnego cennika „za komputer”.

Jeżeli wewnętrznie przyjmujesz stawkę 200 zł netto za godzinę pracy administratora i pierwsze wdrożenie zajmie realnie 8 godzin, sam koszt pracy przy konfiguracji wynosi:

8 × 200 zł = 1600 zł netto.

To nie jest sugerowana cena rynkowa. To przykład obliczenia.

Do tych 1600 zł trzeba doliczyć koszty związane z licencjami, urządzeniami, repozytorium i pozostałymi elementami projektu, a następnie własną marżę.

Tak samo z abonamentem.

Jeżeli monitoring, obsługa alertów, raport i okresowe testy zabierają średnio dwie roboczogodziny miesięcznie:

2 × 200 zł = 400 zł netto miesięcznego kosztu pracy.

Dopiero do tego dochodzą licencje, storage, ewentualne koszty infrastruktury, rezerwa na obsługę incydentów i marża.

Taki model daje dwie korzyści. Po pierwsze wiadomo, dlaczego klient płaci określoną kwotę. Po drugie po sześciu miesiącach można sprawdzić, czy usługa rzeczywiście jest rentowna.

Nie sprzedawałbym też każdego pakietu z tym samym SLA.

Jeżeli klient oczekuje reakcji w cztery godziny tylko w dni robocze, koszt obsługi będzie inny niż przy wymaganiu reakcji wieczorem, w weekend i w święta. Im niższe RTO oraz krótszy czas reakcji, tym bardziej usługa przestaje być zwykłym abonamentem backupowym, a zaczyna wymagać gotowości operacyjnej.

W umowie lub opisie usługi powinno być jednoznacznie określone:

• jakie urządzenia i zasoby są objęte ochroną,

• czego backup nie obejmuje,

• jakie jest RPO,

• jakie jest docelowe RTO,

• jak długo przechowywane są punkty recovery,

• jak często system jest kontrolowany,

• jak często wykonywane są testy,

• kto odpowiada za zgłoszenie nowego urządzenia,

• kto może zatwierdzić usunięcie kopii,

• jak zgłaszana jest awaria,

• co dzieje się z backupem po zakończeniu umowy,

• w jaki sposób klient otrzymuje swoje dane i klucze.

Jeżeli usługodawca przetwarza w ramach backupu dane osobowe w imieniu klienta, trzeba również prawidłowo uregulować powierzenie przetwarzania. Przy przechowywaniu lub innym przetwarzaniu danych poza EOG należy ustalić lokalizację przetwarzania i właściwy dla konkretnej sytuacji mechanizm transferu danych. Tego nie należy sprowadzać do checkboxa „serwer w chmurze”.

Wróćmy na koniec do firmy z początku tekstu.

Mamy:

• 15 laptopów,

• NAS z około 3,2 TB danych,

• Microsoft 365,

• łącze 300/100 Mb/s,

• krytyczne dane księgowe z RPO 1 godzina,

• wymaganie szybkiego powrotu do pracy po awarii NAS-u.

W takim środowisku nie wybrałbym wariantu „wszystko tylko do chmury”. Przy 100 Mb/s odzyskanie kilku terabajtów trwałoby zbyt długo.

Projekt powinien przewidywać:

• częsty backup najważniejszych danych,

• lokalne punkty odzyskiwania,

• niezależne lokalne repozytorium dla szybkiego restore,

• dodatkową kopię poza firmą,

• ochronę niezmienną dla przynajmniej jednej warstwy,

• osobne dane dostępowe do backupu,

• monitoring według RPO,

• okresowe odzyskanie plików,

• pełny test krytycznych systemów,

• osobną decyzję dotyczącą ochrony Microsoft 365.

Właśnie tak powinno się projektować usługę: najpierw ustalasz scenariusz awarii i wymagany wynik recovery, a dopiero później wybierasz program, storage i cennik.

FAQ

Czy firma potrzebuje NAS-u, jeśli ma backup w chmurze?
Nie zawsze. Przy kilku laptopach i niewielkiej ilości danych backup bezpośrednio do chmury może być prostszy. Lokalna kopia zaczyna mieć dużą wartość, gdy trzeba szybko odzyskać setki gigabajtów lub kilka terabajtów. NAS używany jako repozytorium sam również musi być chroniony.

Czy snapshot NAS-u jest backupem?
Snapshot może być ważną warstwą ochrony, ale snapshot znajdujący się wyłącznie na tym samym urządzeniu nie zabezpiecza przed jego kradzieżą, fizycznym zniszczeniem ani każdym przejęciem administracyjnym. Do krytycznych danych potrzebna jest niezależna kopia.

Jak często wykonywać backup komputerów?
Tak często, jak wynika z RPO. Jeżeli firma może stracić maksymalnie godzinę pracy, backup raz dziennie odpada. Jeśli dane zmieniają się sporadycznie i utrata doby jest akceptowalna, częstsze wykonywanie kopii może być niepotrzebne.

Czy Microsoft 365 ma własny backup?
Tak. Microsoft oferuje obecnie Microsoft 365 Backup dla OneDrive, SharePoint i Exchange Online. Nie należy jednak mylić go ze zwykłym wersjonowaniem, koszem i politykami retencji. Wybór między nim a niezależnym rozwiązaniem powinien wynikać z wymaganej retencji, sposobu restore, kosztu i przyjętego modelu ryzyka.

A co z Google Workspace?
Google Workspace udostępnia własne mechanizmy odzyskiwania i retencji zależne od usługi oraz konfiguracji. Przed zakupem dodatkowego backupu trzeba sprawdzić, czego firma rzeczywiście potrzebuje. Niezależna kopia ma sens między innymi wtedy, gdy wymagane są inne okresy przechowywania, centralne raportowanie albo oddzielna warstwa administracyjna.

Jak często testować odtwarzanie?
Nie ma jednej częstotliwości dobrej dla każdego zasobu. Krytyczny system powinien być testowany częściej niż archiwum. Ważniejsze od sztywnego „raz na kwartał” jest to, aby testować po większych zmianach infrastruktury oraz regularnie sprawdzać zarówno pojedyncze dane, jak i pełne recovery najważniejszych usług.

Co zrobić, jeśli ransomware wykryto dopiero po kilku tygodniach?
Trzeba znaleźć ostatni znany dobry punkt recovery sprzed kompromitacji. Właśnie dlatego zbyt krótka retencja jest ryzykowna. Niezmienna kopia wykonana wczoraj nie pomoże, jeżeli od trzech tygodni zawiera już zaszyfrowane dane.

Czy backup w chmurze gwarantuje szybkie odzyskanie danych?
Nie. RTO zależy między innymi od ilości danych, prędkości pobierania, wydajności repozytorium, sposobu restore i czasu potrzebnego do uruchomienia systemów. Kilka TB odzyskiwanych przez zwykłe łącze internetowe może oznaczać dni, a nie godziny.

Czy zielony status backupu oznacza, że dane są bezpieczne?
Nie. Potwierdza przede wszystkim wykonanie zadania. Dopiero próba odtworzenia pokazuje, czy kopia jest czytelna, czy dostępne są klucze, czy zachowano uprawnienia oraz czy uruchamia się chroniona aplikacja.

Co sprawdzić jako pierwsze u nowego klienta?
Wybierz najbardziej krytyczny zasób i wykonaj kontrolowany restore. Zmierz czas odzyskania, sprawdź dostęp do kluczy i zweryfikuj, kto może usunąć wszystkie kopie. Jeżeli nie potrafisz odpowiedzieć na te trzy pytania, nie zaczynaj od kupowania większej przestrzeni ani instalowania kolejnych agentów. Najpierw usuń problem z odzyskiwaniem — dopiero potem optymalizuj backup.

Dodatkowe informacje na: https://hd-biznes.com/blog.