Czy Twoja baza ERP ma kopię? Sprawdź w 10 minut

Na pytanie „czy mamy kopię zapasową” prawie każda firma odpowiada „tak”, bo ktoś kiedyś ją ustawił. Na pytanie „kiedy powstała ostatnia kopia bazy, na której pracujecie dziś” odpowiedź zwykle brzmi „trzeba by sprawdzić”. Ten wpis pokazuje, jak sprawdzić to samodzielnie albo z informatykiem, w kilka minut i bez instalowania czegokolwiek.

Dotyczy to wszystkich programów, które trzymają dane w Microsoft SQL Server. W tej bazie działa większość popularnych w Polsce programów handlowo magazynowych, księgowych i ERP. Jeśli nie wiesz, czy Twój program do nich należy, zapytaj informatyka albo dostawcę programu, gdzie jest baza danych i jak się nazywa.

Co znalazłem u klienta na początku listopada

Z mojego doświadczenia: firma handlowa, kilka stanowisk, ERP na SQL Server w maszynie wirtualnej. Kopie zapasowe „były”, a na serwerze każdej nocy uruchamiało się zadanie o nazwie sugerującej konserwację i kopie. Sprawdzenie zajęło kilka minut i pokazało coś innego.

• Nocne zadanie robiło kopie kilku starych baz testowych, a nie bazy, na której firma pracowała. Pliki trafiały na ten sam dysk co bazy i były trzymane przez tydzień.
• Baza produkcyjna działała już na nowym serwerze, a plan kopii został na starym. Ostatnia pełna kopia bazy produkcyjnej pochodziła sprzed trzech miesięcy.
• Część zadań na starym serwerze kończyła się błędem codziennie. Powiadomienia o błędach nie trafiały do nikogo, więc nikt o nich nie wiedział.
• Udostępnione foldery z dokumentami firmy nie miały kopii od kilku lat.

Dlaczego kopia przestaje działać po cichu

Mechanizm jest podobny do wygasającego certyfikatu SSL: coś, co miało dziać się samo, przestaje się dziać i nic tego nie sygnalizuje. Najczęstsze przyczyny, które widzę przy programach na SQL Server:

1. Przeniesienie bazy na nowy serwer albo do maszyny wirtualnej. Przenosi się baza, a zadania kopii zostają na starym serwerze.
2. Plan kopii obejmuje wybrane bazy z nazwy. Po aktualizacji programu albo założeniu nowej firmy w programie baza ma inną nazwę i do planu nie trafia.
3. Darmowa edycja SQL Server Express nie ma usługi SQL Server Agent, która w pozostałych edycjach uruchamia zadania według harmonogramu. Kopia musi być wtedy uruchamiana innym mechanizmem, na przykład harmonogramem zadań Windows albo modułem samego programu, i o tym łatwo zapomnieć.
4. Zadanie kończy się błędem (brak miejsca na dysku, zmienione hasło do udziału sieciowego), a powiadomienie o błędzie nie ma adresata.
5. Kopia powstaje, ale tylko na tym samym dysku albo serwerze co baza. Chroni przed pomyłką użytkownika, a nie przed awarią dysku, kradzieżą serwera czy szyfrowaniem danych przez złośliwe oprogramowanie.

Jak sprawdzić datę ostatniej kopii

SQL Server zapisuje historię każdej kopii, którą wykonał, w systemowej bazie msdb, w tabeli backupset. Wystarczy to odczytać. Zapytanie niczego nie zmienia, tylko czyta. Uruchamia się je w SQL Server Management Studio, zalogowanym na serwerze, na którym działa baza programu.

SELECT d.name AS baza,
       MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS ostatnia_pelna,
       MAX(CASE WHEN b.type = 'I' THEN b.backup_finish_date END) AS ostatnia_roznicowa,
       MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS ostatni_dziennik
FROM sys.databases d
LEFT JOIN msdb.dbo.backupset b ON b.database_name = d.name
WHERE d.database_id > 4   -- pomija bazy systemowe
GROUP BY d.name
ORDER BY ostatnia_pelna;

Drugie zapytanie pokazuje, gdzie trafiły pliki ostatnich pełnych kopii. To ważne, bo kopia zapisana na dysku C: tego samego serwera wygląda w historii tak samo dobrze jak kopia wysłana poza budynek.

SELECT TOP 20 b.database_name AS baza, b.backup_finish_date AS koniec,
       b.is_copy_only AS jednorazowa, m.physical_device_name AS plik
FROM msdb.dbo.backupset b
JOIN msdb.dbo.backupmediafamily m ON m.media_set_id = b.media_set_id
WHERE b.type = 'D'
ORDER BY b.backup_finish_date DESC;

Jak czytać wynik

Kopia, która się nie odtwarza, nie jest kopią

Data w historii mówi, że kopia powstała. Nie mówi, że da się z niej odtworzyć dane. Są dwa poziomy sprawdzenia i warto znać różnicę między nimi.

Dokumentacja Microsoft mówi wprost, że RESTORE VERIFYONLY nie próbuje sprawdzić struktury danych zapisanych w kopii. To dobry codzienny strażnik, ale nie zastępuje odtworzenia. Prawdziwy test robi się, odtwarzając kopię jako nową bazę o innej nazwie, na tym samym albo innym serwerze, i sprawdzając, czy da się w niej znaleźć wczorajsze dokumenty.

Lista na 10 minut

FAQ: najczęstsze pytania