Backup trzymany na tym samym serwerze co Twoja strona to złudne poczucie bezpieczeństwa. Sprawdź, czym jest prawdziwy backup, dlaczego zasada 3-2-1 ratuje firmy i jak skonfigurować kopię zapasową, która faktycznie zadziała w razie awarii, ataku ransomware lub upadłości hostingodawcy.
Backup przechowywany na tym samym serwerze, koncie lub u tego samego dostawcy hostingu co dane oryginalne nie jest backupem — to tylko druga kopia w tym samym miejscu awarii. Prawdziwy backup musi znajdować się na innej infrastrukturze, w innej lokalizacji i poza zasięgiem tego samego ataku, awarii sprzętu czy decyzji administracyjnej, która może zniszczyć dane źródłowe. Jeśli haker, awaria dysku, pożar serwerowni albo błąd pracownika hostingu mogą skasować jednocześnie Twoją stronę i jej „kopię zapasową” — to nie jest zabezpieczenie, to iluzja zabezpieczenia.
Spis treści
- Czym jest backup — i czym na pewno nie jest
- Dlaczego kopia na tym samym serwerze to pułapka
- Twarde dane: ile firm traci dane mimo „backupu”
- Prawdziwe historie utraty danych przez hosting
- Zasada 3-2-1 (i jej rozszerzona wersja 3-2-1-1-0)
- Checklist: czy Twój backup jest prawdziwy?
- Backup na hostingu vs prawdziwy backup — tabela porównawcza
- Jak zbudować poprawną strategię backupu krok po kroku
- Najczęstsze błędy przy robieniu kopii zapasowych
- FAQ — najczęstsze pytania o backup
- Podsumowanie
1. Czym jest backup — i czym na pewno nie jest
Backup (kopia zapasowa) to niezależna kopia danych, przechowywana w taki sposób, że żadne pojedyncze zdarzenie — awaria, atak, błąd człowieka, upadłość firmy — nie jest w stanie zniszczyć jednocześnie danych źródłowych i ich kopii.
Kluczowe słowo to niezależna. Jeśli kopia dzieli z oryginałem:
- ten sam dysk lub macierz RAID,
- ten sam serwer fizyczny lub maszynę wirtualną,
- to samo konto hostingowe i ten sam panel logowania,
- tego samego dostawcę i tę samą serwerownię,
- to samo źródło zasilania, sieci i administratorów,
…to w praktyce nie masz backupu — masz duplikat w tym samym punkcie awarii (ang. single point of failure). To rozróżnienie jest fundamentem każdej poważnej strategii ochrony danych i jednocześnie najczęściej ignorowaną zasadą wśród właścicieli stron internetowych, sklepów online i małych firm.
2. Dlaczego kopia na tym samym serwerze to pułapka
Większość firm hostingowych oferuje „automatyczne kopie zapasowe” jako element pakietu. To wygodne i lepsze niż nic — ale warto zrozumieć, przed czym takie rozwiązanie faktycznie chroni, a przed czym nie.
Ten sam atak niszczy oryginał i kopię jednocześnie
Współczesne ataki ransomware nie ograniczają się już do zaszyfrowania plików produkcyjnych. Grupy przestępcze świadomie polują na infrastrukturę backupową, bo wiedzą, że firma bez kopii zapasowej zapłaci okup znacznie szybciej. Jeśli Twój backup leży w tym samym panelu administracyjnym, na tym samym koncie FTP albo w tej samej bazie danych co strona — atakujący, który przejmie dostęp do hostingu, przejmuje wszystko naraz.
Awaria sprzętu nie wybiera
Padnięcie macierzy dyskowej, kontrolera RAID albo całej szafy serwerowej potrafi unicestwić zarówno dane produkcyjne, jak i kopie trzymane „obok” — jeśli fizycznie znajdują się na tym samym sprzęcie.
Błąd człowieka po stronie hostingu
Pomyłka administratora, niewłaściwie wykonana migracja, błędny skrypt czyszczący stare konta — to scenariusze, które wielokrotnie kasowały dane tysięcy klientów naraz, razem z ich kopiami zapasowymi przechowywanymi w tym samym systemie.
Problemy finansowe lub prawne dostawcy
Upadłość, przejęcie firmy, spór sądowy, zajęcie serwerów przez organy ścigania w ramach śledztwa dotyczącego innego klienta tej samej serwerowni — to wszystko może odciąć Cię od danych bez Twojej winy, niezależnie od tego, jak dobrze hosting deklarował, że „robi backupy”.
Fałszywe poczucie bezpieczeństwa jest najgroźniejsze
Najbardziej niebezpieczny element tego mechanizmu to nie sama awaria — to przekonanie właściciela strony, że problem nie może go dotyczyć, bo przecież „hosting robi backupy”. To przekonanie usypia czujność i sprawia, że nikt nie konfiguruje niezależnej kopii, dopóki nie jest za późno.
3. Twarde dane: ile firm traci dane mimo „backupu”
Liczby pokazują skalę problemu lepiej niż jakakolwiek teoria:
- Według raportu Veeam, cytowanego przez eGospodarka.pl z okazji Światowego Dnia Backupu 2025, aż 96% ataków ransomware wymierzonych jest nie tylko w dane produkcyjne, ale również bezpośrednio w infrastrukturę backupową, a w trzech na cztery przypadki próba zniszczenia kopii kończy się sukcesem napastnika.
- Dane przytaczane w branżowych analizach pokazują, że w 2025 roku 94% udanych ataków ransomware obejmowało próbę celowego zniszczenia kopii zapasowych ofiary — atakujący traktują backup jako pierwszy cel, nie ostatni.
- Z kolei zestawienie statystyk cyberbezpieczeństwa wskazuje, że mimo posiadania kopii zapasowych przez 68% zaatakowanych firm, aż 56% z nich i tak zdecydowało się zapłacić okup — głównie dlatego, że czas potrzebny na pełne odtworzenie danych z istniejącego backupu liczony był w tygodniach, a nie godzinach.
- W Polsce w 2025 roku aż 83% przedsiębiorstw doświadczyło przynajmniej jednej próby cyberataku, według „Barometru cyberbezpieczeństwa 2025” KPMG — czyli temat dotyczy praktycznie każdej firmy posiadającej stronę lub sklep internetowy, nie tylko dużych korporacji.
Wniosek z tych danych jest prosty: samo posiadanie jakiejkolwiek kopii zapasowej nie wystarcza. Liczy się to, gdzie ta kopia faktycznie się znajduje i czy jest odporna na ten sam scenariusz awarii, który zagraża oryginałowi.
4. Prawdziwe historie utraty danych przez hosting
Przypadek 2be.pl / Adweb (Polska)
Jeden z najgłośniejszych przypadków na polskim rynku hostingowym dotyczył firmy 2be.pl, należącej do grupy Adweb. W wyniku incydentu bezpieczeństwa utracono dane około 1500 kont hostingowych i blisko 10 tysięcy domen. Konsekwencją była fala pozwów ze strony klientów, ogromne koszty sądowe, a ostatecznie zamknięcie firmy. Wielu poszkodowanych klientów straciło dorobek zbierany latami, ponieważ polegali wyłącznie na zabezpieczeniach po stronie dostawcy i nie posiadali żadnej niezależnej kopii danych poza jego infrastrukturą.
Atak na infrastrukturę backupową jako standardowy etap ransomware
Współczesne grupy ransomware-as-a-service traktują przejęcie serwerów backupu, danych logowania do macierzy NAS czy kont w chmurze jako rutynowy, wczesny etap ataku — zanim w ogóle zaszyfrują dane produkcyjne. Celem jest pozbawienie ofiary jakiejkolwiek możliwości odtworzenia systemów bez zapłacenia okupu.
Wspólny mianownik
W obu typach scenariuszy — błędzie ludzkim po stronie dostawcy i celowym ataku — ofiary łączy jedno: kopia zapasowa znajdowała się w tym samym środowisku, które zostało skompromitowane. Gdyby istniała niezależna, odizolowana kopia, czas i koszt odtworzenia byłyby radykalnie inne.
5. Zasada 3-2-1 (i jej rozszerzona wersja 3-2-1-1-0)
Zasada 3-2-1 to branżowy standard projektowania kopii zapasowych, stosowany od dekad przez administratorów IT na całym świecie:
- 3 — przechowuj co najmniej trzy kopie danych: oryginał plus dwie kopie zapasowe.
- 2 — trzymaj je na dwóch różnych typach nośników (np. dysk serwera + chmura, albo serwer + lokalny NAS).
- 1 — co najmniej jedna kopia musi znajdować się poza siedzibą / poza dostawcą danych źródłowych (off-site).
Nowoczesna, rozszerzona wersja tej zasady to 3-2-1-1-0, uwzględniająca zagrożenie ransomware:
- dodatkowe 1 — jedna kopia powinna być niezmienna (immutable) lub fizycznie odizolowana (air-gapped), czyli niemożliwa do nadpisania lub zaszyfrowania nawet przez kogoś, kto przejmie pełny dostęp administracyjny.
- 0 — regularne testy odtwarzania powinny kończyć się zerem błędów — backup, którego nigdy nie przetestowano, w praktyce nie istnieje.
Kopia zapasowa trzymana wyłącznie na koncie hostingowym spełnia w najlepszym razie punkt „2” (inny katalog/inny mechanizm zapisu), ale nigdy nie spełnia punktu „1” — bo nie opuszcza infrastruktury tego samego dostawcy.
6. Checklist: czy Twój backup jest prawdziwy?
Odpowiedz sobie szczerze na poniższe pytania:
- Czy kopia zapasowa znajduje się fizycznie poza serwerem, na którym działa Twoja strona?
- Czy kopia jest u innego dostawcy niż Twój hosting (inna firma, inna infrastruktura)?
- Czy do backupu prowadzi inne hasło / inny dostęp niż do panelu hostingowego?
- Czy backup jest niezmienny lub odizolowany od sieci na tyle, że ransomware z poziomu serwera nie może go zaszyfrować ani skasować?
- Czy backup obejmuje pliki ORAZ bazę danych w spójnym, zsynchronizowanym stanie?
- Czy testowałeś realne odtworzenie danych z tej kopii w ciągu ostatnich 3 miesięcy?
- Czy masz więcej niż jedną wersję kopii w czasie (np. z ostatnich 7-30 dni), a nie tylko najnowszy nadpisywany plik?
Jeśli na którekolwiek pytanie odpowiedziałeś „nie” — Twoja obecna kopia zapasowa wymaga uzupełnienia.
7. Backup na hostingu vs prawdziwy backup — tabela porównawcza
| Kryterium | Backup tylko na hostingu | Prawdziwy backup (zewnętrzny) |
|---|---|---|
| Niezależna lokalizacja | Ten sam serwer/dostawca | Inna infrastruktura i lokalizacja |
| Odporność na atak ransomware na konto hostingowe | Ginie razem z danymi | Pozostaje nietknięty |
| Odporność na awarię sprzętu hostingu | Może zostać zniszczony razem z oryginałem | Niezależny sprzęt |
| Odporność na upadłość/zamknięcie firmy hostingowej | Brak dostępu do danych | Dane pozostają u Ciebie / w innym miejscu |
| Odporność na błąd administratora hostingu | Możliwe usunięcie wraz z kontem | Poza zasięgiem tego błędu |
| Historia wersji (kilka punktów w czasie) | Zależy od planu hostingowego, często ograniczona | Pełna kontrola nad retencją |
| Koszt | Zwykle wliczony w abonament | Dodatkowy, zwykle niewielki koszt |
| Wymagana konfiguracja | Minimalna | Wymaga jednorazowego ustawienia |
8. Jak zbudować poprawną strategię backupu krok po kroku
Zostaw backup hostingowy jako pierwszą linię obrony
Nie wyłączaj automatycznych kopii w panelu hostingowym — to wciąż przydatne narzędzie do szybkiego przywrócenia plików po drobnym błędzie (np. nieudana aktualizacja wtyczki). Traktuj je jednak jako uzupełnienie, nie jako jedyne zabezpieczenie.
Skonfiguruj automatyczny eksport poza hosting
Najprostsze i sprawdzone opcje:
- Chmura obiektowa niezależna od hostingu (np. Backblaze B2, Amazon S3, Wasabi, Google Cloud Storage) — tania, skalowalna, dostępna z poziomu większości narzędzi do backupu stron.
- Dysk sieciowy NAS w innej lokalizacji (np. w siedzibie firmy), jeśli wolisz zachować pełną kontrolę nad nośnikiem fizycznym.
- Wtyczki/skrypty automatyzujące eksport, np. w WordPressie narzędzia takie jak UpdraftPlus, Duplicator czy BlogVault potrafią same wysyłać kopię plików i bazy danych na zewnętrzne konto chmurowe według harmonogramu.
- Narzędzia open-source dla serwerów Linux: rsync, rclone, restic lub BorgBackup — pozwalają zbudować w pełni automatyczny, zaszyfrowany i przyrostowy backup wysyłany poza serwer.
Zadbaj o pełną kopię, nie tylko o pliki
Backup powinien obejmować jednocześnie pliki strony i eksport bazy danych w tym samym momencie czasowym — niespójna kopia (pliki z poniedziałku, baza ze środy) może okazać się bezużyteczna przy odtwarzaniu.
Wprowadź wersjonowanie i retencję
Ustaw przechowywanie kilku punktów w czasie (np. 7 dni wstecz, 4 tygodnie wstecz, 3 miesiące wstecz). Dzięki temu, jeśli problem (np. infekcja malware) zostanie wykryty z opóźnieniem, nadal będziesz mieć dostęp do czystej kopii sprzed infekcji.
Rozważ kopię niezmienną (immutable)
Jeśli zarządzasz danymi o wysokiej wartości (sklep internetowy, baza klientów, dane finansowe), skonfiguruj backup w trybie write once, read many (WORM) lub z polityką blokady retencji — uniemożliwia to nadpisanie lub skasowanie kopii nawet przez kogoś, kto przejmie pełne dane logowania.
Testuj odtwarzanie regularnie
Backup, który nigdy nie był odtworzony testowo, jest niepewny. Raz na kwartał wykonaj próbne przywrócenie kopii na osobnym, izolowanym środowisku i sprawdź, czy strona faktycznie działa.
Udokumentuj procedurę
Spisz krok po kroku, jak wygląda proces odtworzenia danych z backupu — kto za to odpowiada, jakie ma dane dostępowe i ile czasu to zajmuje. W sytuacji kryzysowej nie ma czasu na improwizację.
9. Najczęstsze błędy przy robieniu kopii zapasowych
- Trzymanie backupu w tym samym katalogu/koncie co strona — to klasyczny błąd opisany w tym artykule.
- Brak szyfrowania kopii — niezaszyfrowany backup w chmurze to dodatkowy wektor wycieku danych.
- Jedna kopia bez historii wersji — nadpisywanie tego samego pliku backupu uniemożliwia powrót do stanu sprzed infekcji.
- Brak testów odtwarzania — backup „na papierze” istniejący, ale nigdy nie sprawdzony w praktyce.
- Backup tylko plików, bez bazy danych (lub odwrotnie) — niekompletna kopia.
- Te same dane logowania do hostingu i do backupu — jeśli atakujący przejmie panel hostingowy, przejmie też backup.
- Brak automatyzacji — poleganie na „pamiętaniu”, żeby zrobić kopię ręcznie, kończy się lukami czasowymi.
10. FAQ — najczęstsze pytania o backup
Czy backup oferowany przez firmę hostingową jest bezwartościowy? Nie, jest przydatny i wart wykorzystania jako pierwsza, szybka linia obrony przy drobnych awariach. Problem pojawia się tylko wtedy, gdy jest to jedyna kopia danych — wtedy nie chroni przed scenariuszami, w których ucierpi cała infrastruktura dostawcy.
Jak często powinienem robić backup strony internetowej? Zależy od częstotliwości zmian. Statyczna strona wizytówkowa może mieć backup tygodniowy lub miesięczny. Aktywny sklep internetowy z codziennymi zamówieniami powinien mieć backup bazy danych co najmniej raz dziennie, a w przypadku bardzo dużego ruchu — kilka razy dziennie.
Czy chmura (Google Drive, Dropbox) wystarczy jako miejsce na backup? Może być jednym z elementów strategii, o ile dane są tam przesyłane automatycznie, w sposób zaszyfrowany i niezależny od konta powiązanego z hostingiem. Nie powinna być jednak jedynym miejscem przechowywania — warto łączyć kilka niezależnych lokalizacji.
Czym różni się backup od replikacji lub klastra wysokiej dostępności? Replikacja i klastry (HA) zwiększają dostępność usługi w czasie rzeczywistym, ale zwykle kopiują też błędy i uszkodzenia danych niemal natychmiast na wszystkie węzły. To nie jest substytut backupu — jeśli baza danych zostanie zaszyfrowana przez ransomware, replikacja skopiuje zaszyfrowane dane równie szybko, co dane prawidłowe.
Co to jest backup niezmienny (immutable) i czy jest mi potrzebny? To kopia zapasowa, której nie da się nadpisać, zmodyfikować ani skasować przez określony czas, nawet przez konto administracyjne. Jest szczególnie ważna dla firm przechowujących dane klientów, dane finansowe lub działających w branżach regulowanych, gdzie ryzyko ataku ransomware jest wysokie.
Ile kopii zapasowych powinienem przechowywać jednocześnie? Zgodnie z zasadą 3-2-1 minimum to trzy kopie danych (oryginał + dwie kopie) na dwóch różnych typach nośników, z czego co najmniej jedna poza siedzibą/dostawcą danych źródłowych. W praktyce dla małych firm dobrym punktem startowym jest: backup hostingowy + automatyczny eksport do niezależnej chmury z historią kilku ostatnich wersji.
Czy backup chroni przed wyciekiem danych? Nie. Backup chroni przed utratą danych (skasowaniem, zaszyfrowaniem, uszkodzeniem), ale nie zapobiega ich kradzieży/wyciekowi, jeśli atakujący uzyskał dostęp przed wykonaniem kopii. To dwa różne obszary bezpieczeństwa, które wymagają osobnych zabezpieczeń (m.in. szyfrowania, kontroli dostępu, monitoringu).
11. Podsumowanie
Backup, który dzieli infrastrukturę, konto lub dostawcę z danymi, które ma chronić, nie jest backupem — jest tylko drugą kopią narażoną na dokładnie to samo ryzyko. Statystyki nie pozostawiają złudzeń: zdecydowana większość udanych ataków ransomware celuje dziś bezpośrednio w infrastrukturę backupową, a firmy, które posiadały kopię zapasową „na hostingu”, i tak masowo decydowały się płacić okup, bo proces odtwarzania trwał zbyt długo lub kopia również została zniszczona.
Rozwiązanie nie wymaga rewolucji — wystarczy jedna dodatkowa, automatyczna kopia poza Twoim obecnym dostawcą hostingu, najlepiej z historią wersji i regularnie testowanym procesem odtwarzania. To koszt rzędu kilku-kilkunastu złotych miesięcznie w zamian za realną ochronę przed utratą danych, którą zbierałeś czasem przez lata.