Kopia zapasowa jest super… dopóki nie musisz jej odtwarzać. Wtedy nagle wychodzi, że „backup jest” nie znaczy „backup działa”: brakuje ostatnich plików, baza jest sprzed tygodnia, a panel pozwala co najwyżej pobrać archiwum bez możliwości szybkiego przywrócenia. Najgorsze jest to, że większość takich problemów widać dopiero po awarii, ataku albo ludzkim błędzie.
Jeśli prowadzisz stronę firmową, blog, sklep albo serwis z kontami użytkowników, powinieneś myśleć o kopiach zapasowych jak o planie awaryjnym: ile danych możesz maksymalnie stracić i jak szybko musisz wrócić do działania. To dokładnie opisują dwa parametry: RPO (ile możesz stracić) i RTO (jak szybko musisz odzyskać działanie). One są dużo bardziej praktyczne niż marketingowe „codzienne backupy” bez doprecyzowania.
Drugi element to retencja, czyli jak długo kopie są przechowywane. Trzy dni historii to za mało, jeśli błąd lub infekcja została zauważona po tygodniu. A 30 dni historii nie pomoże, jeśli kopie są robione źle (np. bez bazy danych) albo trzymane w tym samym miejscu, które padło razem z serwerem.
Trzeci temat to offsite: kopie poza serwerem, na którym działa Twoja strona. To brzmi jak detal, ale w praktyce odróżnia „odtworzymy po awarii dysku” od „straciliśmy wszystko, bo awaria dotyczyła całej maszyny, konta lub macierzy”. Offsite jest też kluczowy w scenariuszu ataku na konto hostingowe, bo atakujący potrafi skasować nie tylko pliki, ale i backupy, jeśli są pod ręką.
W tym wpisie rozkładam backup w hostingu na czynniki pierwsze: jak czytać ofertę, jakie pytania zadać, jak sprawdzić, czy kopie obejmują to, co trzeba, i jak raz na kwartał wykonać test odtworzenia bez stresu. Dostaniesz też checklistę porównawczą, sekcję o typowych pułapkach oraz proste wskazówki, które rozwiązanie ma sens dla strony na CMS i dla sklepu. Jeśli jesteś na etapie wyboru usług, potraktuj backup jako jeden z głównych elementów decyzji — obok wydajności czy niezawodności.
Backup w hostingu bez mitów: co dokładnie powinno być kopiowane
Podstawowy błąd myślenia o kopii zapasowej to traktowanie jej jako jednego pliku „zip ze stroną”. Strona WWW to zwykle co najmniej trzy elementy: pliki aplikacji (CMS i wtyczki), pliki Twoich treści (uploady, zdjęcia, dokumenty) oraz baza danych (najczęściej MySQL/MariaDB). Jeśli backup nie obejmuje bazy albo obejmuje ją w innej częstotliwości niż pliki, odtworzenie będzie pozorne: witryna wstanie, ale treści i zamówienia znikną.
Druga rzecz to „spójność” kopii. Dla serwisu, który zapisuje dane w trakcie (zamówienia, rejestracje, formularze), ważne jest, żeby kopia bazy i plików była zbliżona czasowo. Inaczej możesz odtworzyć pliki z 02:00 i bazę z 23:00 dnia poprzedniego, a potem zdziwić się, że część obrazów „nie pasuje” do wpisów, a zamówienia mają braki.
Trzeci element to zakres: czy kopia obejmuje całe konto, tylko katalog public_html, czy też np. dodatkowe domeny, subdomeny, cron, konfiguracje, certyfikaty, a nawet skrzynki pocztowe. Dla części projektów to krytyczne — bo awaria poczty potrafi zatrzymać obsługę zamówień podobnie jak awaria strony.
W praktyce, kiedy czytasz opis backupu, szukaj odpowiedzi na pytania: „co jest kopiowane”, „jak często”, „jak długo trzymane”, „gdzie trzymane” i „jak wygląda odtworzenie”. Jeśli na któreś z nich nie ma jasnej odpowiedzi, to sygnał, że w razie problemu będziesz zdany na support albo własną improwizację. Jeżeli dopiero wybierasz usługę, dobrze jest patrzeć na backup tak samo jak na parametry stabilności.
RPO i RTO po ludzku: jak przeliczyć je na realne wymagania dla strony i sklepu
RPO (Recovery Point Objective) mówi, jak stare mogą być dane po odtworzeniu. Jeśli RPO wynosi 24 godziny, to w najgorszym razie stracisz dzień zmian. Dla bloga aktualizowanego raz na tydzień — często do przełknięcia. Dla sklepu, gdzie wpadają zamówienia cały dzień — to realna strata pieniędzy, nerwów i reklamacji.
RTO (Recovery Time Objective) mówi, jak szybko masz wrócić do działania. Jeśli RTO to 4 godziny, to znaczy, że od awarii do działającej strony masz maksymalnie cztery godziny. Tu nie chodzi o to, czy backup „da się pobrać”, tylko czy odtworzenie jest szybkie i przewidywalne. W praktyce RTO zależy od tego, czy możesz przywrócić kopię jednym kliknięciem, czy musisz ręcznie rozpakować archiwum, importować bazę i zgadywać konfigurację.
Jak to policzyć w realnym świecie? Zacznij od pytania: „co się dzieje, jeśli strona nie działa 2 godziny?”. Dla strony firmowej to zwykle utrata leadów i wizerunek, dla sklepu — utrata sprzedaży i rosnąca liczba zgłoszeń. Potem: „co się dzieje, jeśli stracę dane z 12 godzin?”. Dla serwisu z rejestracją to ryzyko utraty kont i danych użytkowników, dla sklepu — zamówień i płatności.
Na tej podstawie dobierasz: częstotliwość backupu (to wpływa na RPO) oraz sposób odtwarzania i dostęp do kopii (to wpływa na RTO). Często okazuje się, że „codzienny backup” jest OK dla plików, ale baza powinna być kopiowana częściej. A jeśli nie chcesz inwestować w bardzo częste kopie na poziomie hostingu, wtedy wchodzi wariant: dodatkowy backup aplikacyjny lub zewnętrzny.
Warto też pamiętać o scenariuszach „nie-awaryjnych”: ktoś przypadkiem usunie katalog uploadów, wtyczka nadpisze szablon, albo aktualizacja CMS popsuje stronę. To nie jest awaria serwera, a i tak potrzebujesz RTO i RPO — tylko w skali jednego projektu.
Retencja kopii: ile ma sens?
Retencja to czas przechowywania kopii. Najczęściej zobaczysz „7 dni” albo „14 dni”. Problem: wiele usterek i infekcji nie jest wykrywanych od razu. Strona może działać normalnie, a złośliwy kod dodaje przekierowania dopiero po kilku dniach, albo spamerskie linki pojawiają się w tle i wychodzą dopiero, gdy spadnie ruch z Google.
Jeśli masz retencję 7 dni, a problem zauważysz po 10 dniach, wszystkie kopie będą już „skażone”. Wtedy backup istnieje, ale nie ma wartości. Dlatego sensowna retencja zależy od tego, jak szybko wykrywasz problemy i jak często zaglądasz do projektu. Dla serwisu, który ktoś monitoruje codziennie, 14 dni może wystarczyć. Dla strony „zostawionej samej sobie” — 30 dni to bezpieczniejszy punkt startu.
Retencja to też liczba punktów przywracania. Dwa punkty (wczoraj i dziś) to mało. Kilkanaście punktów rozłożonych w czasie daje możliwość „cofnięcia” do momentu sprzed zmiany, która popsuła stronę. W praktyce dobre rozwiązania oferują codzienne kopie przez X dni, czasem tygodniowe przez Y tygodni, a czasem miesięczne przez Z miesięcy — to pozwala wrócić do wersji sprzed dłuższego czasu bez trzymania gigantycznej liczby kopii.
Uważaj na retencję „na papierze”, jeśli nie wiesz, jak wygląda dostęp do kopii. Bywa, że kopie są trzymane długo, ale odtworzenie dotyczy tylko ostatniej lub wymaga zgłoszenia do supportu. Dla RTO to ogromna różnica: tydzień historii nie pomoże, jeśli przywrócenie trwa dzień roboczy. Jeżeli przy wyborze hostingu kierujesz się ceną, to właśnie retencja i offsite są często pierwszym miejscem, gdzie „taniej” oznacza „mniej bezpiecznie”.
Offsite i odporność na awarie: jak rozpoznać kopię, która przetrwa najgorszy scenariusz
Offsite oznacza, że kopia jest przechowywana poza serwerem (albo przynajmniej poza tym samym środowiskiem), na którym działa Twoja strona. To ważne, bo istnieją awarie i incydenty, które „zabierają wszystko naraz”: problem z macierzą, błąd w systemie plików, awaria całej maszyny wirtualnej, a czasem kompromitacja konta.
Jeśli backup leży na tym samym koncie hostingowym, w tym samym panelu i w tych samych uprawnieniach, atakujący, który przejmie dostęp, może go skasować. Podobnie człowiek w stresie: „usuwam katalog, bo coś nie działa” i przypadkiem usuwa też kopie. Offsite zmniejsza ryzyko, że błąd lub atak dotknie jednocześnie produkcji i kopii.
Jak to sprawdzić bez wchodzenia w techniczne szczegóły infrastruktury dostawcy? Po pierwsze, szukaj jasnej informacji, że kopie są przechowywane poza serwerem produkcyjnym (nie „na osobnym dysku”, tylko poza hostem). Po drugie, zapytaj (albo sprawdź w panelu), czy masz możliwość pobrania kopii na własny komputer / do własnej chmury. To prosty test: jeśli możesz pobrać, to znaczy, że kopia istnieje jako niezależny artefakt, a nie tylko „migawka w systemie”.
Warto też sprawdzić, czy offsite obejmuje zarówno pliki, jak i bazę. Czasem „offsite” dotyczy archiwum plików, a baza jest trzymana inaczej — i wtedy wracamy do problemu spójności. Dobre podejście to traktowanie backupu jako zestawu, który da się odtworzyć w całości, a nie jako kilku niezależnych elementów.
Offsite jest szczególnie ważny przy serwisach, które nie mogą mieć długich przestojów. Jeśli przywracanie ma sens działać szybko, a do tego kopia ma przetrwać „najgorszy dzień”, offsite jest jednym z kryteriów, które naprawdę rozróżnia oferty.
Backup a typ hostingu i CMS
Na hostingu współdzielonym backup zwykle działa na poziomie konta: archiwizacja katalogów i zrzut bazy. To najprostszy model, ale ma swoje ograniczenia: częstotliwość może być stała (np. raz dziennie), a odtworzenie bywa ograniczone do ostatnich punktów. Dodatkowo, jeśli serwis ma dużo plików (sklep z dużą liczbą zdjęć), backup może być ciężki i wolniejszy.
W przypadku WordPressa często największym problemem nie jest „czy backup jest”, tylko „czy backup potrafi szybko wrócić do działającej strony po nieudanej aktualizacji wtyczki lub motywu”. WordPress żyje aktualizacjami, a te potrafią wywrócić stronę. Dlatego w praktyce backup powinien wspierać szybkie odtworzenie i możliwość cofnięcia do konkretnego dnia/godziny. To nie zawsze wymaga osobnego hostingu, ale wymaga sensownej retencji i prostego przywracania — tematu, który warto mieć w głowie, wybierając hosting WordPress.
W sklepach (PrestaShop i inne) dochodzi „krytyczność bazy”: zamówienia, stany magazynowe, dane klientów, integracje. Tu RPO bywa ostrzejsze, bo strata kilku godzin może oznaczać realne rozjazdy w płatnościach i wysyłkach. Do tego dochodzi często większy ruch i większa liczba zapisów do bazy. W takim scenariuszu backup raz dziennie może być minimum, ale nie zawsze optimum — czasem potrzebujesz częstszej kopii bazy albo dodatkowego mechanizmu.
W praktyce typ hostingu wpływa też na to, jaką masz kontrolę. Na części usług masz tylko gotowy backup i przycisk „przywróć”, na innych możesz dołożyć własne narzędzia i automaty. Warto wiedzieć, że „środowisko WordPress” i „środowisko www” mogą się różnić podejściem do panelu i narzędzi — co dobrze tłumaczy wpis Hosting www vs hosting WordPress.
Backup to część większej układanki stabilności. Jeśli serwer często ma problemy z dostępnością, to nawet świetny backup nie naprawi strat w sprzedaży i wizerunku, bo będziesz go używać za często.
Jak sprawdzić, czy backup działa?
Najlepsza kopia zapasowa to taka, którą raz na jakiś czas testujesz. I nie chodzi o odtworzenie „na produkcji”, tylko o kontrolowany test: pobranie kopii, sprawdzenie zawartości, próba przywrócenia w środowisku testowym albo na subdomenie. Dzięki temu wiesz, czy kopia zawiera bazę, czy pliki się rozpakowują, czy brakuje uprawnień i czy konfiguracja jest kompletna.
Zacznij od prostego kroku: czy w panelu hostingu widzisz listę punktów przywracania i czy możesz pobrać kopię. Pobranie to pierwszy test: jeśli pobierasz archiwum i jest podejrzanie małe, to sygnał, że coś nie obejmuje uploadów albo bazy. Jeśli panel nie pozwala pobrać, tylko „przywrócić”, to nadal może być OK, ale Twoje możliwości awaryjne są mniejsze (jesteś zależny od jednego dostawcy i jednego panelu).
Drugi krok to „czy wiesz, co przywracasz”. W praktyce warto mieć zapisane: gdzie jest baza, jaki jest użytkownik bazy, gdzie jest plik konfiguracyjny aplikacji, jakie są wersje PHP i rozszerzeń. Przy odtwarzaniu po awarii najwięcej czasu schodzi nie na import bazy, tylko na odtwarzanie kontekstu: „co tu było ustawione”. Jeśli masz stronę na CMS, dobrze jest też wiedzieć, które elementy są krytyczne (np. pliki konfiguracyjne, klucze, cache).
Trzeci krok to pomiar RTO w praktyce. Ustaw stoper i zrób kontrolowany scenariusz: „przywracam kopię z wczoraj”. Zobacz, ile realnie trwa: kliknięcie i odtworzenie, a potem weryfikacja działania. Jeśli wychodzi 2–3 godziny przy prostej stronie, to Twoje RTO w praktyce jest inne niż w wyobrażeniu.
Na koniec przygotuj prostą procedurę awaryjną dla siebie lub zespołu: gdzie kliknąć, co przywrócić, jak sprawdzić wynik. To nie musi być dokument na 10 stron. Wystarczy lista kroków i 3–5 rzeczy do weryfikacji po odtworzeniu (strona główna, logowanie, formularz, koszyk, panel administracyjny).
Backup a bezpieczeństwo i pozycjonowanie: po czym poznasz, że awaria będzie kosztowna
Nie każda awaria jest taka sama. Najbardziej kosztowne są te, które trwają długo (RTO w praktyce jest duże) albo te, które cofają dane i powodują chaos (RPO jest zbyt luźne). Jeśli prowadzisz działania SEO, długie przestoje i błędy 5xx potrafią odbić się na widoczności. Jeśli prowadzisz sprzedaż, przestój to utrata przychodu i konieczność tłumaczeń klientom.
Awaria jest też kosztowna, gdy problem jest „ukryty” — np. infekcja, która trwa, ale nikt jej nie zauważa. Wtedy retencja i możliwość cofnięcia się do czystej kopii mają ogromne znaczenie. W praktyce to jest moment, gdy doceniasz dłuższą historię kopii i offsite, bo pozwala wrócić do stanu sprzed incydentu.
Zwróć uwagę na symptomy, które mówią, że potrzebujesz lepszego backupu niż „domyślny”: często aktualizujesz CMS, masz wtyczki od różnych autorów, masz integracje i automaty, rośnie liczba zamówień, albo Twoja strona jest krytyczna dla pozyskiwania leadów. To wszystko zwiększa prawdopodobieństwo sytuacji, w której backup będzie realnie użyty.
Backup to też zabezpieczenie przed własnymi zmianami. Jeśli testujesz nowe funkcje, zmieniasz szablon, wdrażasz CDN albo optymalizacje, ryzyko „coś poszło nie tak” rośnie. Zresztą część tematów o wydajności i stabilności hostingu pokazuje, jak wiele elementów składa się na działanie strony — od zasobów po warstwę sieci. W tym kontekście backup jest ostatnią deską ratunku, gdy nie chcesz rozkładać projektu od zera.
Najczęstsze błędy i jak je naprawić
„Backup jest”, ale obejmuje tylko pliki, bez bazy danych.
To błąd, który wychodzi dopiero przy odtwarzaniu: strona się ładuje, ale wpisy, zamówienia, ustawienia są nieaktualne albo znikają. Naprawa: upewnij się, że backup obejmuje bazę, a jeśli hosting robi kopie bazy osobno, sprawdź częstotliwość i sposób przywracania. Dla CMS i sklepów baza to element krytyczny — bez niej kopia jest niepełna.
Retencja zbyt krótka, żeby cofnąć się przed problem (np. infekcja wykryta po 10 dniach).
Krótka retencja sprawia, że wszystkie kopie są „z tego samego zepsutego okresu”. Naprawa: zwiększ retencję (jeśli hosting pozwala), dołóż niezależny backup z dłuższą historią albo przynajmniej co jakiś czas archiwizuj kopię miesięczną poza hostingiem. Dodatkowo ustaw monitoring, żeby szybciej wykrywać problemy i nie „przegapić” momentu, do którego trzeba się cofnąć.
Kopie trzymane w tym samym miejscu co produkcja (brak offsite).
To ryzykowne w awarii infrastruktury lub przy przejęciu konta. Naprawa: sprawdź, czy hosting oferuje offsite, a jeśli nie, wprowadź dodatkowy backup poza hostingiem (nawet proste pobieranie kopii raz na tydzień do własnej chmury jako warstwa awaryjna). Offsite nie musi być skomplikowany — ma być odporny na ten sam incydent.
Backup robi się automatycznie, ale nikt nigdy nie testował odtworzenia.
To klasyczna „kopia Schrödingera”: istnieje, ale nie wiesz, czy działa. Naprawa: raz na kwartał wykonaj test odtworzenia w kontrolowanym środowisku. Zapisz RTO w praktyce i sprawdź kompletność: pliki, baza, konfiguracja, działanie kluczowych funkcji.
Odtwarzanie trwa zbyt długo, bo proces jest ręczny i nieudokumentowany.
W kryzysie najwięcej czasu tracisz na zgadywanie: skąd pobrać kopię, jaką wersję wybrać, gdzie importować bazę. Naprawa: przygotuj krótką procedurę (nawet prywatną notatkę) i sprawdź, czy panel pozwala na szybkie „przywróć punkt”. Jeśli nie pozwala, rozważ model, w którym krytyczne elementy (np. baza sklepu) mają dodatkową warstwę backupu.
Mylenie backupu z „wysoką dostępnością”.
Backup nie zapewnia ciągłości działania. On pozwala wrócić po problemie, ale nie zapobiegnie przestojowi. Naprawa: jeśli Twoje RTO jest bardzo krótkie (np. kilkanaście minut), sam backup może nie wystarczyć — potrzebujesz dodatkowych rozwiązań (monitoring, szybkie przełączenie, procedury). Dlatego warto patrzeć też na niezawodność i sygnały z uptime hostingu.
FAQ – Najczęściej zadawane pytania
RPO mówi, ile danych możesz stracić (jak „stara” może być kopia), a RTO mówi, jak szybko wrócisz do działania. „Codzienny backup” oznacza zwykle RPO rzędu 24 godzin, ale nie mówi nic o RTO. Możesz mieć codzienne kopie i jednocześnie odtwarzanie trwające pół dnia, bo wymaga ręcznych działań. Dlatego warto myśleć tymi dwoma parametrami, a nie samą częstotliwością.
Jest lepszy niż brak backupu, ale nie chroni przed wszystkimi scenariuszami. Jeśli awaria dotyczy całego środowiska albo ktoś przejmie konto, kopie mogą zniknąć razem z produkcją. Dlatego offsite (kopie poza serwerem produkcyjnym) jest ważne, zwłaszcza dla projektów krytycznych. Dobrą praktyką jest też trzymanie choć jednej warstwy kopii niezależnie od hostingu.
Minimum to baza danych oraz katalog z uploadami (zdjęcia i pliki), a w praktyce także pliki motywu i konfiguracja. Jeśli odtwarzasz tylko pliki, a baza jest nieaktualna, stracisz wpisy, ustawienia, komentarze. Jeśli odtwarzasz tylko bazę, a uploady są z innego dnia, część obrazów może „nie pasować” do treści. Najważniejsze jest to, żeby kopia była kompletna i możliwie spójna czasowo.
To zależy od tego, czy poczta jest krytyczna dla działania firmy (np. obsługa zamówień, zgłoszenia, faktury). W wielu przypadkach kopia strony nie obejmuje poczty automatycznie. Jeśli potrzebujesz możliwości odtworzenia maili, upewnij się, że backup hostingu obejmuje też pocztę albo że masz niezależną archiwizację. Warto to rozdzielić: backup WWW i backup poczty to często dwa różne mechanizmy.
Chroni, jeśli masz wystarczającą retencję i czyste punkty przywracania. Jeśli infekcja trwa długo niezauważona, a retencja jest krótka, wszystkie kopie mogą być już „zainfekowane”. Dlatego backup powinien iść w parze z monitoringiem i aktualizacjami. Offsite też ma znaczenie, bo atakujący z dostępem do konta może próbować usunąć kopie.
30-letnia pasjonatka informatyki, która świat serwerów i hostingów zna od podszewki. Wierzy, że technologia powinna ułatwiać życie, a nie je komplikować. Żyje w ciągłym ruchu – jeśli akurat nie konfiguruje nowej usługi, prawdopodobnie pakuje plecak na kolejną wyprawę w nieznane.
Dodaj komentarz