Kopie zapasowe, odtwarzanie i kontrola spójności

Kopia jest użyteczna, gdy można ją odtworzyć

Awaria dysku, błąd programu i przypadkowy DELETE wymagają różnych działań, ale wszystkie pokazują znaczenie kopii zapasowej. Plik o nazwie backup.sql nie jest jeszcze dowodem, że zawiera komplet danych i daje się poprawnie odtworzyć. Potrzebne są procedura, kontrola oraz próbne odtworzenie w oddzielnym środowisku.

RPO opisuje akceptowaną utratę danych w czasie, a RTO czas potrzebny na przywrócenie działania. To rozszerzenie praktyczne: sama częstotliwość backupu nie gwarantuje osiągnięcia tych celów.

Próbne odtworzenie danych kursu

1. Przygotuj bazę z części 26. Zapisz wersję silnika, datę i liczbę rekordów 5/4/4/6.
2. W phpMyAdmin wyeksportuj strukturę i dane czterech tabel do SQL. Sprawdź, czy zakres obejmuje także potrzebne widoki lub inne obiekty, jeśli zostały dodane w ćwiczeniach.
3. Zachowaj kopię pliku w chronionym miejscu. Dla rzeczywistych danych stosuj kontrolę dostępu, szyfrowanie i retencję. Kopia na tym samym uszkodzonym dysku nie uratuje danych.
4. Utwórz nową bazę, np. cn_sql_odtworzenie_2026. Sprawdź w kopii eksportu CREATE DATABASE, USE i DROP, aby import nie skierował operacji do oryginału. Dostosuj wyłącznie roboczą kopię skryptu do nowego celu.
5. Zaimportuj, zatrzymując się na błędach. Sprawdź tabele, typy, klucze, liczby i konkretne wartości. Dopiero wtedy zanotuj wynik próby.

SELECT COUNT(*) AS klienci FROM klienci;
SELECT SUM(cena) AS suma_cen FROM produkty;
SELECT p.zamowienie_id, SUM(p.ilosc * pr.cena) AS wartosc
FROM pozycje p
JOIN produkty pr ON pr.id = p.produkt_id
GROUP BY p.zamowienie_id
ORDER BY p.zamowienie_id;

Na bazie początkowej oczekujemy 5 klientów, sumy cen 1005 i wartości zamówień: 240, 800, 75, 110. Te kontrole sprawdzają wybrane dane, nie zastępują pełnej weryfikacji bazy. Jeżeli wcześniej wykonano UPDATE, punktem odniesienia ma być stan zapisany przed eksportem, a nie wynik z niezmienionej bazy.

Spójność logiczna i techniczna

Klucz obcy chroni relację między tabelami, CHECK — warunek wartości, UNIQUE — unikalność. Można też szukać nieprawidłowości zapytaniem diagnostycznym. Poniższe powinno zwrócić zero wierszy:

SELECT z.id, z.klient_id
FROM zamowienia z
LEFT JOIN klienci k ON k.id = z.klient_id
WHERE k.id IS NULL;

To wykrywa zamówienia bez klienta. Nie mówi jednak, czy pliki bazy są technicznie nieuszkodzone. Z kolei poprawna struktura pliku nie potwierdza, że wszystkie dane biznesowe są sensowne. Integralność techniczna, relacyjna i zgodność z wymaganiami to różne warstwy kontroli.

Ten sam cel, inne narzędzia

To mapa narzędzi, nie zestaw poleceń do uruchomienia na działającej bazie strony. Odtwarzanie wymaga poprawnego celu, ścieżek i uprawnień. W SSMS do próbnego odtworzenia wybierz nową nazwę bazy i nowe pliki, nie opcję nadpisania oryginału.

Naprawa nie jest uniwersalnym przyciskiem

Najpierw zachowaj komunikaty, logi i bezpieczną kopię dostępnych danych. Rozróżnij brak miejsca, problem uprawnień, zerwane połączenie, naruszenie więzów i rzeczywiste uszkodzenie. Błąd SQL nie oznacza automatycznie uszkodzenia pliku.

REPAIR TABLE w MySQL nie jest metodą naprawy InnoDB. Nie stosuj go do każdej tabeli. Tryby awaryjnego odzyskiwania i naprawy dopuszczającej utratę danych są zadaniem administratora z udokumentowaną procedurą. Preferuj sprawdzone odtworzenie, a narzędzia naprawcze dobieraj do rozpoznanej przyczyny i silnika.

Ćwiczenia z rozwiązaniami

Źródła i dalszy krok

MariaDB: mariadb-dump · MySQL: REPAIR TABLE · SQL Server: VERIFYONLY · Access: kompaktowanie i naprawa · SQLite: Online Backup API

INF.03 obejmuje nie tylko zapytania, lecz także konserwację, kopie i odtwarzanie baz. W kolejnej części połączymy bazę z aplikacją PHP.