Kopia zapasowa strony firmowej: jak często robić backup i gdzie go trzymać

Kopię zapasową strony firmowej rób codziennie, a przy sklepie internetowym co kilka godzin, bo między jedną kopią a drugą tracisz wszystkie zamówienia i wiadomości z formularzy. Pełny backup to pliki plus baza danych plus poczta, a nie sam katalog z plikami. Trzymaj kopie na osobnej infrastrukturze niż strona, przechowuj je co najmniej 28 dni, a nie 7, i raz na jakiś czas faktycznie odtwórz backup, bo kopia, której nigdy nie przywróciłeś, jest tylko hipotezą.

Co tak naprawdę zawiera kompletna kopia zapasowa?

Kompletny backup strony to trzy rzeczy: pliki (WordPress, motyw, wtyczki, zdjęcia, dokumenty), baza danych MySQL oraz skrzynki pocztowe w domenie. Kopia samych plików jest bezużyteczna, bo cała treść, ustawienia, użytkownicy i zamówienia siedzą w bazie. Odzyskasz wtedy pusty szkielet strony.

To jest błąd, który widzimy u firm najczęściej. Ktoś pobrał katalog przez FTP, zapisał na dysku w biurze i uznał, że ma backup. Po awarii okazuje się, że ma zdjęcia i wtyczki, ale zero treści, zero klientów, zero historii zamówień. WordPress bez bazy danych to katalog plików PHP, które można pobrać z wordpress.org w trzydzieści sekund. Wartość jest w bazie.

Poczta to osobna sprawa i osobny problem. Jeśli firma pracuje na skrzynkach IMAP w swojej domenie, korespondencja z klientami, potwierdzenia zamówień, oferty i faktury żyją na serwerze pocztowym. Wiele planów hostingowych backupuje stronę, ale poczty już nie, albo trzyma ją krócej. Sprawdź to u swojego dostawcy konkretnie, nie na podstawie hasła o kopiach zapasowych w cenie.

Do kompletu dochodzą jeszcze rzeczy, o których nikt nie myśli, dopóki ich nie zabraknie: certyfikat SSL (odtwarzalny), konfiguracja DNS (odtwarzalna, ale bolesna, jeśli nie masz jej spisanej) i pliki konfiguracyjne serwera, na przykład .htaccess z regułami przekierowań budowanymi latami.

Jak często robić kopię zapasową strony?

Częstotliwość backupu wynika z jednej odpowiedzi: ile pracy jesteś w stanie stracić. Wizytówka firmowa, która zmienia się raz na kwartał, spokojnie wytrzyma kopię dobową. Sklep WooCommerce z kilkunastoma zamówieniami dziennie potrzebuje kopii co kilka godzin, bo przy dobowym backupie tracisz wszystko, co klienci zamówili od północy.

W żargonie nazywa się to RPO (Recovery Point Objective). Po polsku: maksymalna ilość danych, jaką akceptujesz jako stratę. Jeśli backup jest robiony o 3:00 w nocy, a serwer padnie o 16:00, Twoje RPO wynosi trzynaście godzin. Pytanie brzmi, co się mieści w tych trzynastu godzinach. Przy wizytówce: nic. Przy sklepie: dzień utargu, dane kontaktowe klientów i zamówienia, o których nawet nie wiesz, że istniały, bo nigdy ich nie zobaczyłeś w panelu.

Dlatego przy sklepach standardem nie jest jeden backup na dobę, tylko dobowy backup pełny plus częstsze kopie bazy danych. Baza jest mała i szybka do zrzucenia, a pliki (zdjęcia produktów) zmieniają się rzadko. Nie ma sensu co godzinę kopiować dwudziestu gigabajtów zdjęć, ma sens co godzinę zrzucać bazę.

Przy sklepie warto dodać jedno zastrzeżenie, o którym rzadko się mówi. Nawet jeśli backup bazy leci co godzinę, odtworzenie sklepu do stanu sprzed trzech godzin oznacza rozjazd z systemem płatności. Klient zapłacił, operator płatności o tym wie, Twoja baza już nie. Odzyskanie sklepu to zawsze także ręczne uzgodnienie transakcji, nie tylko przywrócenie plików.

Gdzie przechowywać kopię zapasową?

Kopia na tym samym serwerze co strona nie jest kopią zapasową. To duplikat pliku. Padnie dysk, wejdzie ransomware albo ktoś skasuje konto, i znikną obie rzeczy naraz. Backup ma sens tylko wtedy, gdy leży na innej infrastrukturze niż to, co zabezpiecza, najlepiej w innej lokalizacji fizycznej.

Klasyczna reguła nazywa się 3-2-1 i brzmi prościej, niż wygląda: trzy kopie danych (oryginał plus dwie kopie), na dwóch różnych nośnikach lub w dwóch różnych systemach, z czego jedna poza główną lokalizacją. Dla małej firmy w praktyce oznacza to: strona na serwerze, backup automatyczny u hostingodawcy na osobnej maszynie oraz kopia w chmurze albo na dysku, do którego serwer nie ma dostępu.

Ten ostatni punkt jest kluczowy przy ransomware. Jeśli serwer ma zamontowany zasób z backupami z prawem zapisu, złośliwe oprogramowanie zaszyfruje także backupy. Dlatego dobre rozwiązania używają kopii, których nie da się nadpisać ani skasować przed upływem zadanego czasu (immutability), albo takich, do których serwer wysyła dane, ale nie może ich odczytać ani usunąć. Zasada jest prosta: to backup ma sięgać po dane, nie serwer po backup.

Lokalizacja ma też znaczenie prawne i praktyczne. Jeśli Twoja strona zbiera dane klientów, to kopie zapasowe zawierają te same dane osobowe. W Businesshost serwery stoją fizycznie w Warszawie (OVH), a kopie nie opuszczają polskiej infrastruktury, co upraszcza rozmowę o RODO i przy większych wdrożeniach o umowę powierzenia. Szczegóły planów są w cenniku.

Czy backup u hostingodawcy wystarczy?

Dla większości małych firm backup hostingowy jest podstawą i zwykle wystarcza, pod trzema warunkami: leży na osobnej infrastrukturze, obejmuje pliki i bazę, i ma sensowną retencję. Ale jeśli hosting jest jedynym miejscem, gdzie istnieją Twoje dane, to spór z dostawcą, blokada konta albo pomyłka przy usuwaniu usługi kosztuje Cię wszystko naraz.

Porównajmy uczciwie trzy podejścia.

Backup ręczny (eksport przez FTP i phpMyAdmin) nic nie kosztuje i daje pełną kontrolę. Ma jedną wadę: nikt go nie robi regularnie. Po dwóch tygodniach zapominasz, po miesiącu masz kopię sprzed miesiąca. Jako jedyna strategia nie działa, jako trzecia kopia w regule 3-2-1 jest w porządku.

Wtyczki backupowe (UpdraftPlus, BackWPup i podobne) są wygodne i potrafią wysyłać kopie do zewnętrznej chmury, co jest ich największą zaletą. Wady są dwie. Po pierwsze, wtyczka działa wewnątrz WordPressa, więc jeśli WordPress padnie tak, że nie wstaje panel, odtworzenie robi się trudniejsze. Po drugie, wtyczka backupowa jest częścią atakowanej strony: jeśli ktoś włamie się do panelu, ma dostęp także do konfiguracji backupów i miejsca docelowego. To realne ograniczenie, nie teoria.

Backup na poziomie hostingu działa poza WordPressem, poza panelem i poza zasięgiem osoby, która włamała się na stronę. Nie zależy od tego, czy strona w ogóle się uruchamia. To jest jego przewaga. U nas każdy plan od Start (39 zł netto miesięcznie) ma dobową kopię plus osobny backup wykonywany przed każdą aktualizacją, a każde zdarzenie (backup, aktualizacja, przywrócenie) trafia do dziennika, więc wiadomo, co i kiedy zostało zrobione. W planie Pro (179 zł netto miesięcznie) przywrócenie sięga do 28 dni wstecz.

Zdrowy układ dla firmy: backup hostingowy jako podstawa, wtyczka wysyłająca kopię do zewnętrznej chmury jako druga warstwa. Dwa niezależne systemy, dwa różne miejsca.

Backup przed zmianą to nie to samo co backup nocny

To rozróżnienie ratuje strony częściej niż cokolwiek innego. Kopia nocna chroni przed awarią, której nie planowałeś. Kopia wykonana bezpośrednio przed ryzykowną zmianą chroni przed czymś, co robisz świadomie: aktualizacją WordPressa, instalacją wtyczki, zmianą motywu, podbiciem wersji PHP, migracją na inny serwer.

Różnica jest w czasie. Aktualizujesz wtyczkę o 14:00, coś się psuje, orientujesz się o 14:05. Masz do wyboru kopię sprzed jedenastu godzin (i tracisz pół dnia pracy oraz wszystko, co przyszło rano) albo kopię sprzed pięciu minut. Druga opcja to nie jest luksus, to jedyna rozsądna opcja. Rozwinęliśmy to w osobnym tekście o tym, jak zrobić backup przed aktualizacją WordPressa.

Ta sama logika dotyczy przeprowadzki. Zmiana hostingu to moment, w którym dane istnieją w dwóch miejscach i łatwo o pomyłkę: ktoś przełącza DNS za wcześnie, zamówienia lecą na stary serwer, a stary serwer jest już wyłączany. Kopia sprzed migracji, trzymana osobno przez kilka tygodni po przeprowadzce, jest tania w porównaniu z alternatywą. Jeśli nie chcesz o tym pamiętać przy każdej aktualizacji, zostaje zarządzany hosting WordPress z backupem przed każdą aktualizacją, gdzie dzieje się to automatycznie.

Ile kopii trzymać wstecz? Dlaczego 7 dni to za mało

Siedmiodniowa retencja chroni tylko przed problemami, które zauważysz w ciągu tygodnia. Problem w tym, że najgroźniejsze awarie odkrywa się późno: malware siedzi cicho przez trzy tygodnie, uszkodzona baza produktów wychodzi na jaw przy pierwszej inwentaryzacji, a skasowany katalog zdjęć zauważasz miesiąc po fakcie.

Realny scenariusz: strona zostaje zainfekowana, skrypt wstrzykuje ukryte linki. Nie widać tego na froncie, formularze działają, sklep sprzedaje. Dowiadujesz się dopiero, gdy Google oflaguje domenę albo klient zadzwoni z ostrzeżeniem przeglądarki. Mija miesiąc. Przy retencji siedmiodniowej każda dostępna kopia jest już zainfekowana, bo backup wiernie kopiuje także złośliwy kod. Zostaje Ci ręczne usuwanie malware zamiast przywrócenia czystej wersji jednym kliknięciem.

Minimum sensowne dla firmy to 28 do 30 dni. Przy sklepie i przy stronach, gdzie dane finansowe mają znaczenie, 90 dni jest lepsze. Dobrym kompromisem jest schemat: kopie dobowe z ostatnich 30 dni, kopie tygodniowe z ostatnich 3 miesięcy, kopia miesięczna z ostatniego roku. Rośnie to wolniej, niż się wydaje, bo backupy przyrostowe zapisują tylko zmiany.

Jak sprawdzić, czy backup w ogóle działa?

Odtwórz go. To jedyny test, który cokolwiek znaczy. Backup, którego nigdy nie przywróciłeś, jest hipotezą, nie zabezpieczeniem, a zielona ikonka z informacją o zakończonym backupie mówi tylko tyle, że proces się zakończył, nie że plik da się rozpakować i że baza w środku jest kompletna.

Praktyczny test raz na kwartał, do wykonania w pół godziny: pobierz najnowszą kopię, postaw ją na środowisku testowym (staging albo lokalnie), zaloguj się do panelu, otwórz kilka podstron, sprawdź, czy zdjęcia się ładują, a w sklepie czy widać ostatnie zamówienia. Sprawdź też rozmiar pliku, bo backup, który nagle skurczył się z 4 GB do 200 MB, urwał się w połowie i nikt tego nie zauważył.

Warto też zmierzyć czas. Ile minut albo godzin zajmuje pełne przywrócenie? To jest Twoje RTO i odpowiedź na pytanie, ile godzin Twoja strona będzie leżeć w najgorszym scenariuszu. Lepiej znać tę liczbę teraz niż dowiedzieć się jej w środę o 9 rano.

Backup a RODO: kopie też zawierają dane osobowe

Kopia zapasowa strony z formularzem, newsletterem albo sklepem zawiera dane osobowe, więc podlega RODO dokładnie tak samo jak strona produkcyjna. Musisz wiedzieć, gdzie fizycznie leżą kopie, jak długo są trzymane, kto ma do nich dostęp i czy dostawca backupu jest podmiotem przetwarzającym, z którym masz umowę powierzenia.

Dwie rzeczy sprawiają firmom najwięcej problemu. Pierwsza: prawo do usunięcia danych. Jeśli klient prosi o usunięcie konta, a Ty masz jego dane w kopiach z ostatnich 90 dni, nie musisz rozpakowywać każdego archiwum, ale musisz mieć zasadę, że dane znikną wraz z wygaśnięciem retencji i że nie wrócą przy ewentualnym odtworzeniu. To trzeba mieć opisane, nie tylko wiedzieć.

Druga: nieograniczona retencja. Trzymanie backupów na zawsze, bo miejsce jest tanie, jest sprzeczne z zasadą ograniczenia przechowywania. Kopie mają mieć zdefiniowany okres życia i po nim faktycznie znikać. Więcej o podziale ról między Tobą a hostingodawcą opisaliśmy przy hostingu na polskich serwerach z fakturą VAT.

Osobna sprawa to dokumenty, które nie mieszkają na stronie, ale są krwiobiegiem firmy. Faktury, umowy i rozliczenia zwykle siedzą w systemie księgowym albo na platformie, gdzie firma obraca swoimi należnościami, i mają własny reżim kopii. Backup strony ich nie obejmuje, a wiele osób zakłada, że jakoś obejmuje.

Checklista: backup strony firmowej

• Sprawdź, czy Twoja kopia zawiera pliki, bazę danych i pocztę, nie tylko pliki.
• Ustal RPO: ile godzin pracy i zamówień możesz stracić. Od tego zależy częstotliwość.
• Upewnij się, że kopie leżą na innej infrastrukturze niż strona, nie w katalogu obok.
• Wydłuż retencję do minimum 28 do 30 dni, przy sklepie rozważ 90.
• Miej drugie, niezależne miejsce docelowe (chmura zewnętrzna albo wtyczka wysyłająca kopię poza hosting).
• Rób osobną kopię przed każdą aktualizacją, zmianą motywu, podbiciem PHP i migracją.
• Raz na kwartał odtwórz backup na środowisku testowym i zmierz, ile to trwa.
• Ustaw alert o nieudanym backupie, bo cisza nie znaczy, że działa.
• Opisz w dokumentacji RODO, gdzie leżą kopie, jak długo i kto ma do nich dostęp.
• Spisz konfigurację DNS i przekierowania w miejscu, którego awaria serwera nie dotknie.

Backup jest jedną z tych rzeczy, które kosztują niewiele, dopóki są niepotrzebne, i są bezcenne przez te dwie godziny w roku, kiedy okazują się potrzebne. Jeśli nie wiesz, kiedy ostatnio ktoś sprawdził Twoje kopie, to jest dobry moment, żeby to zrobić: pobierz najnowszy backup i spróbuj go otworzyć. Dowiesz się w pięć minut, na czym stoisz.