Backup plików to za mało: jak poprawnie robić kopie bazy danych

Wielu właścicieli stron jest przekonanych, że mają backup, bo raz na jakiś czas pobierają pliki przez FTP albo panel. Problem w tym, że nowoczesna strona — WordPress, sklep, forum, dowolny CMS — to nie tylko pliki. Połowa Twojego serwisu, i to ta trudniejsza do odtworzenia, siedzi w bazie danych: treści wpisów, ustawienia, konta użytkowników, zamówienia, komentarze. Kopia samych plików bez aktualnej, spójnej kopii bazy nie odtworzy działającej strony. Ten poradnik pokazuje, jak robić kopie bazy, które naprawdę ratują sytuację.

Jeśli dopiero układasz cały proces tworzenia kopii, zacznij od tekstu jak ustawić kopie zapasowe strony, żeby naprawdę działały. Tutaj skupiamy się wyłącznie na najczęściej zaniedbywanej części — na bazie danych.

Co siedzi w bazie, a czego nie ma w plikach

W typowym CMS-ie pliki to silnik strony i wygląd: kod, motyw, wtyczki, biblioteki. Baza danych to zawartość i stan serwisu. Kiedy publikujesz wpis, dodajesz produkt albo ktoś składa zamówienie, te informacje trafiają do bazy, a nie do plików. Dlatego przywrócenie samych plików sprzed awarii da Ci pustą albo cofniętą w czasie stronę — szkielet bez treści z ostatnich dni czy tygodni.

Ważny wyjątek: przesłane pliki, na przykład zdjęcia i dokumenty, zwykle leżą w katalogu na dysku, a w bazie jest tylko odwołanie do nich. Dlatego kompletny backup to zawsze dwie części naraz — pliki i baza — wykonane w zbliżonym czasie, tak by do siebie pasowały.

Dlaczego baza wymaga osobnego traktowania

Bazy nie da się poprawnie skopiować przez zwykłe przeciągnięcie pliku, tak jak kopiujesz zdjęcie. Baza jest cały czas w użyciu: w tej samej chwili, gdy robisz kopię, ktoś może zapisywać nowe dane. Jeśli po prostu skopiujesz pliki bazy „na żywo", możesz złapać ją w połowie operacji i otrzymać kopię niespójną — taką, z której odtworzenie się nie powiedzie albo da uszkodzone dane.

Dlatego bazę zrzuca się (ang. dump) specjalnym narzędziem, które odczytuje jej zawartość w sposób spójny i zapisuje do jednego pliku z instrukcjami odtworzenia. W świecie MySQL i MariaDB, na których stoi większość hostingów, robi to standardowe narzędzie do eksportu. Kluczowe jest, by zrzut był spójny w czasie — reprezentował bazę w jednym, konkretnym momencie, a nie posklejaną z różnych chwil.

Jak poprawnie wykonać kopię bazy

Masz kilka dróg, zależnie od tego, do czego masz dostęp:

• Eksport z panelu hostingu. Większość paneli ma opcję zrzutu bazy lub narzędzie typu phpMyAdmin z funkcją eksportu do pliku. To najprostsza metoda dla jednej strony.
• Zrzut z linii poleceń. Jeśli masz dostęp do SSH, standardowe narzędzie eksportu MySQL zrobi spójny plik jedną komendą — łatwo to też zautomatyzować w harmonogramie.
• Wtyczka lub mechanizm CMS-a. Dobre wtyczki backupu dla WordPressa czy innych systemów potrafią zrzucić bazę razem z plikami i wysłać całość poza serwer.
• Backup po stronie dostawcy. Wielu hostingodawców robi automatyczne kopie całych kont, w tym bazy. To wygodne, ale traktuj to jako dodatek, a nie jedyne zabezpieczenie — o tym niżej.

Niezależnie od metody pilnuj kilku rzeczy. Zrzut powinien obejmować pełną strukturę i dane. Plik warto skompresować, bo bazy tekstowo bywają duże. I najważniejsze: pliki oraz baza z jednego backupu powinny pochodzić z tego samego, zbliżonego momentu, żeby po odtworzeniu do siebie pasowały.

Regularność, retencja i miejsce przechowywania

Jednorazowa kopia sprzed pół roku nie ochroni serwisu, którego treść zmienia się codziennie. Częstotliwość dobierz do tempa zmian:

• Strona rzadko aktualizowana — kopia bazy co pewien czas, na przykład raz na tydzień, plus przed każdą większą zmianą.
• Aktywny blog albo firmowa strona z regularnymi wpisami — kopia codzienna.
• Sklep przyjmujący zamówienia — kopie częste, nawet kilka razy dziennie, bo każda utracona godzina to utracone zamówienia.

Trzymaj kilka wersji wstecz, a nie tylko najnowszą. Jeśli awaria albo włamanie zepsuje bazę, a Ty nadpiszesz jedyną kopię już zepsutą wersją, nie masz do czego wrócić. Kluczowa jest też zasada, by kopia leżała poza tym samym serwerem — backup na tym samym koncie, które właśnie padło lub zostało zaszyfrowane, jest bezużyteczny. Automatyczne kopie dostawcy są dobrym zabezpieczeniem, ale trzymaj też własną kopię w niezależnym miejscu.

Test odtworzenia — bez tego nie masz backupu

Najważniejsza i najczęściej pomijana część: backup, którego nigdy nie próbowałeś odtworzyć, to tylko nadzieja, nie zabezpieczenie. Plik zrzutu może być uszkodzony, niepełny albo zapisany w sposób, którego nie da się wgrać z powrotem — a dowiesz się o tym w najgorszym możliwym momencie.

Dlatego co jakiś czas wykonaj próbę odtworzenia bazy w bezpiecznym miejscu, na przykład na osobnym koncie testowym albo w środowisku, które nie jest Twoją produkcyjną stroną. Sprawdź, czy strona po odtworzeniu naprawdę działa: czy treści są aktualne, czy logowanie działa, czy dane się zgadzają. Przy okazji zobaczysz, ile realnie zajmuje odtworzenie — to ważne, gdy liczy się czas. Jeśli podczas prób natrafisz na błędy typu biała strona czy błąd 500, przyda się umiejętność czytania logów, którą opisujemy w tekście logi serwera dla początkujących: gdzie szukać przyczyny błędu 500, 403 i białej strony.

Podsumowanie

Kopia plików bez bazy to połowa zabezpieczenia — i to ta mniej wartościowa. Bazę traktuj osobno: zrzucaj ją narzędziem, które daje spójny w czasie plik, rób to regularnie i w tym samym momencie co kopię plików, trzymaj kilka wersji poza serwerem i przynajmniej raz na jakiś czas przetestuj odtworzenie. Backup bazy jest też nieoceniony przy przenosinach i porządnej higienie serwera — o szerszym kontekście bezpieczeństwa piszemy w tekstach jak przenieść stronę WordPress na nowy hosting bez przestoju oraz bezpieczeństwo hostingu w 2026: malware, DDoS, WAF i kopie zapasowe. Dopiero gdy potrafisz odtworzyć bazę, możesz powiedzieć, że naprawdę masz backup.