Kopia zapasowa strony firmowej — co zabezpieczyć i jak sprawdzić, że da się przywrócić

Kopia zapasowa strony firmowej to cztery elementy: kod źródłowy, baza danych (jeśli strona korzysta z systemu zarządzania treścią), pliki wgrane na serwer oraz zapisana konfiguracja domeny i integracji. Automatyczna kopia od hostingu bywa pomocna, ale nie zastępuje kopii, którą kontrolujesz Ty — bo za to, czy strona wstanie po awarii, odpowiadasz Ty, a nie zapis w regulaminie dostawcy. Poniżej pokazuję, co dokładnie zabezpieczyć, jak często to robić i jak zweryfikować, że kopię da się naprawdę przywrócić.

Co wchodzi w skład kopii strony firmowej

Pełna kopia strony to nie tylko folder z plikami. Zanim zaplanujesz kopię, zrób listę wszystkiego, co tracisz w chwili, gdy serwer przestaje działać — i zabezpiecz każdy punkt z tej listy osobno.

• Kod źródłowy strony. Dla stron kodowanych od zera, np. w Astro, kod żyje w repozytorium i każda opublikowana zmiana ma swoją historię. To najwygodniejsza forma kopii: przywracasz konkretną wersję, wiesz, kto i kiedy ją zmienił. Jeśli Twoja strona powstawała w technologii kodowanej od zera, upewnij się, że masz dostęp do repozytorium — nie tylko do działającej strony.
• Baza danych. Jeśli strona ma panel administracyjny, treści, wpisy blogowe, ustawienia formularzy czy zamówienia siedzą w bazie. Kod bez bazy to szkielet bez zawartości.
• Pliki wgrane przez panel. Zdjęcia realizacji, PDF-y ofert, cenniki do pobrania — wszystko, co ktoś dodał ręcznie po wdrożeniu, nie ma swojego odbicia w repozytorium kodu.
• Konfiguracja. Rekordy DNS domeny, zmienne środowiskowe, klucze do integracji (poczta firmowa, bramka płatności w sklepie), ustawienia certyfikatu SSL. Te rzeczy giną najczęściej, bo nikt nie traktuje ich jako części strony.
• Dostępy. Lista kont do hostingu, domeny, repozytorium i panelu, zapisana w menedżerze haseł. Kopia, do której nie masz drogi wejścia, nie jest kopią.

Kopia od hostingu a kopia niezależna — kto za co odpowiada

Kopia od hostingu to wygodny dodatek, ale nie plan awaryjny. Dostawcy hostingu zwykle trzymają kopie przez ograniczony czas, często wyłączają odpowiedzialność za ich kompletność, a w skrajnych przypadkach — gdy problem leży po ich stronie albo konto zostaje zablokowane — możesz nie mieć do nich dostępu dokładnie wtedy, gdy są najbardziej potrzebne.

Dlatego stosuj prostą zasadę: przynajmniej jedna kopia strony musi fizycznie istnieć w innym miejscu niż hosting. W praktyce oznacza to:

• kod w repozytorium, do którego masz dostęp Ty, a nie tylko wykonawca,
• regularny eksport bazy danych zapisywany poza serwerem,
• kopię plików wgranych przez panel w chmurze lub na dysku, który nie należy do dostawcy hostingu.

To rozdzielenie ma jeszcze jedną zaletę: gdy z jakiegokolwiek powodu zmienisz hosting albo wykonawcę, nie zaczynasz od zera. Kopie, które masz u siebie, działają niezależnie od tego, kto dziś obsługuje serwer.

Jak często robić kopię — decyduje to, co zmienia się na stronie

Częstotliwość kopii wynika z jednego pytania: ile treści straciłbyś, gdyby awaria zdarzyła się dzisiaj wieczorem? Dla różnych typów stron odpowiedź wygląda inaczej.

• Strona statyczna, aktualizowana przez wykonawcę. Kopia powstaje przy każdej publikacji zmian — w repozytorium zapisuje się każda wersja. Między publikacjami strona się nie zmienia, więc dodatkowe harmonogramy nic nie wnoszą.
• Strona z panelem, na której sam publikujesz treści. Baza zmienia się za każdym razem, gdy dodajesz wpis, opinię czy zdjęcie. Tu potrzebny jest regularny, najlepiej automatyczny eksport bazy — ręczne „pamiętam, żeby pobrać" przestaje działać po drugim tygodniu.
• Sklep internetowy. Zamówienia i dane klientów zapisują się codziennie, więc codzienna kopia bazy to minimum. Przed każdą większą zmianą — aktualizacją, wdrożeniem nowej funkcji — zrób dodatkową pełną kopię i dopiero potem pozwól na zmiany na produkcji.

Test przywracania — jedyny dowód, że kopia działa

Kopia, której nigdy nie przywrócono, to hipoteza. Jedyny sposób, żeby wiedzieć, że zadziała w razie awarii, to odtworzyć ją raz w warunkach kontrolowanych. Zrób to według tej kolejności:

1. Odtwórz kopię na środowisku testowym — subdomena albo lokalny serwer. Nigdy nie testuj przywracania na działającej stronie.
2. Przejdź stronę jak użytkownik. Strona główna, kluczowa podstrona, cennik, formularz. Szukaj brakujących zdjęć i błędów — to one pokazują, których plików brakuje w kopii.
3. Wyślij testową wiadomość przez formularz kontaktowy i sprawdź, czy dochodzi na firmową skrzynkę. To weryfikuje nie tylko bazę, ale i konfigurację poczty, której zwykle nie ma w plikach kopii.
4. Porównaj rozmiar bazy i liczbę plików z poprzednią kopią. Nagły spadek oznacza, że eksport gdzieś się wykrzacza i nikt tego nie zauważył.
5. Zapisz, ile czasu zajęło odtworzenie. To Twój realistyczny czas reakcji na awarię — warto go znać, zanim awaria się wydarzy.

Test powtarzaj po każdej większej zmianie strony: nowym wdrożeniu, zmianie hostingu, przejściu na inny system. Strona, która zmieniła się od ostatniego testu, to w praktyce inna strona.

Najczęstsze błędy przy kopiach zapasowych

Z problemów, które widuję najczęściej, każdy da się uniknąć jedną decyzją podjętą wcześniej:

• Jedyna kopia leży u hostingu. Gdy problem dotyczy samego dostawcy, tracisz stronę i kopię za jednym zamachem.
• Kopia nigdy nie była testowana. Eksport bazy, który urywa się w połowie, wygląda jak pełnoprawny plik — dopóki nie spróbujesz go wgrać.
• Kopia kodu bez bazy albo bazy bez plików. Strona odtworzona w połowie jest często gorsza niż brak strony, bo sugeruje, że wszystko działa.
• Dostępy do kopii ma tylko wykonawca. Jeśli współpraca się kończy, a nikt nie przekaże Ci repozytorium i eksportów, kopia formalnie istnieje, ale nie dla Ciebie. Dlatego przy każdym przejęciu strony upominaj się o komplet: kod, eksport bazy, pliki media i dostęp do repozytorium.
• Hasła do zaszyfrowanych kopii są zgubione. Szyfrowanie kopii to dobra praktyka, ale klucz musi leżeć w menedżerze haseł, do którego dostęp ma właściciel firmy.

Comiesięczny przegląd kopii — krótka checklista

Raz w miesiącu, przy okazji przeglądu statystyk strony, przejdź pięć punktów:

• sprawdź datę ostatniej kopii bazy i plików — czy jest świeża względem tego, co publikujesz,
• zobacz, czy nie przyszło powiadomienie o nieudanym eksporcie (i czy takie powiadomienia w ogóle są włączone),
• upewnij się, że dostęp do repozytorium i chmury z kopiami masz również Ty, nie tylko wykonawca,
• wyrywkowo otwórz ostatni eksport bazy — plik, który nie chce się otworzyć, lepiej wykryć dziś niż w kryzysie,
• odhacz w kalendarzu termin następnego testu przywracania.

Podsumowanie

Kopia zapasowa strony firmowej przestaje być abstrakcją, gdy spełnia trzy warunki: obejmuje kod, bazę, pliki i konfigurację, leży przynajmniej częściowo poza hostingiem oraz była co najmniej raz testowo przywrócona. Reszta — częstotliwość, narzędzia, automatyzacja — to szczegóły, które dobiera się pod to, jak często Twoja strona się zmienia.

Jeśli nie masz pewności, czy Twoja strona spełnia te warunki, najprościej zacząć od analizy strony i planu działania — sprawdzę w niej również to, co dzieje się z kopiami i dostępami, i pokażę, co trzeba dopiąć, zanim zrobi to pierwszy poważny problem.