# Czy Twoja baza ERP ma kopię zapasową? Jak to sprawdzić w 10 minut

> Większość firm wie, że ma kopię zapasową, bo ktoś kiedyś ją ustawił. Mało która sprawdziła, kiedy ta kopia naprawdę ostatnio powstała. Pokazuję zapytanie, które odpowiada na to w minutę, jak czytać wynik i dlaczego kopia potrafi przestać działać po cichu, na przykładzie bazy, która nie miała pełnej kopii od trzech miesięcy.

Adres strony: https://systembox.pl/blog/kopia-zapasowa-bazy-erp-jak-sprawdzic

Autor: Sergiusz Siemak. Opublikowano: 2026-11-03. Kategoria: Bezpieczeństwo. Czas czytania: ok. 7 min.

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

Jeśli program ERP działa na SQL Server, data ostatniej kopii każdej bazy jest zapisana na serwerze. Jedno zapytanie pokazuje, kiedy kopia powstała i gdzie trafił plik. Kopia starsza niż doba albo leżąca na tym samym dysku co baza nie chroni firmy przed awarią.

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.

> **Uwaga:** Nikt tu nie zaniedbał niczego w oczywisty sposób. Kopia była kiedyś ustawiona poprawnie, a potem zmieniło się otoczenie: nowy serwer, nowa baza, nowy informatyk. Kopia nie psuje się w dniu, w którym przestaje działać. Psuje się w dniu, w którym jest potrzebna.

## 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.

**Zapytanie 1: ostatnia kopia każdej bazy**

```sql
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;
```

Typy w kolumnie type według dokumentacji Microsoft: D to pełna kopia bazy, I to kopia różnicowa, L to kopia dziennika transakcji.

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.

**Zapytanie 2: dokąd trafiły ostatnie pełne kopie**

```sql
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

**Ostatnia pełna kopia bazy produkcyjnej: co oznacza wynik**

| Co widzisz | Co to znaczy | Co zrobić |
| --- | --- | --- |
| Data z ostatniej doby, plik na innym serwerze lub udziale sieciowym | Kopie powstają i wychodzą poza serwer bazy | Sprawdzić, czy kopia się odtwarza (niżej) i czy jest też kopia poza budynkiem |
| Data z ostatniej doby, plik na tym samym serwerze | Kopia chroni przed pomyłką, nie przed awarią serwera ani szyfrowaniem danych | Dodać kopiowanie plików poza serwer |
| Data sprzed kilku dni lub tygodni | Mechanizm kopii przestał działać, a nikt tego nie zauważył | Od razu wykonać kopię ręcznie, potem znaleźć przyczynę |
| Brak daty (NULL) | SQL Server nigdy nie wykonał kopii tej bazy albo robi ją inne narzędzie | Ustalić, czym jest robiona kopia; jeśli niczym, to jest najpilniejsza sprawa |

Pusta kolumna nie zawsze oznacza brak kopii. Jeśli kopię całej maszyny wirtualnej robi osobne narzędzie, historia w msdb może jej nie zawierać. Wtedy dowodem jest raport z tego narzędzia, z datą ostatniej udanej kopii.

## 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.

**Szybka weryfikacja kontra prawdziwy test odtworzenia**

RESTORE VERIFYONLY:
- Sprawdza, czy plik kopii jest kompletny i czytelny
- Sprawdza sumy kontrolne, jeśli kopia je ma
- Nie odtwarza bazy i nie sprawdza struktury danych
- Trwa minuty, można robić po każdej kopii

Odtworzenie pod inną nazwą:
- Baza powstaje naprawdę, obok produkcyjnej
- Widać, czy program się z nią łączy i czy dane są aktualne
- Pokazuje realny czas powrotu do pracy po awarii
- Wymaga miejsca na dysku, warto raz na kwartał

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

**Sprawdzenie kopii bazy ERP krok po kroku**

1. Ustal serwer i nazwę bazy: w programie albo u dostawcy; baz może być kilka, po jednej na firmę
2. Zapytanie 1: data ostatniej pełnej kopii każdej bazy
3. Zapytanie 2: gdzie leżą pliki kopii: ten sam serwer czy poza nim
4. Historia zadań: czy zadania kopii kończą się sukcesem i kto dostaje błędy
5. RESTORE VERIFYONLY: czy ostatni plik kopii jest czytelny
6. Termin testu odtworzenia: w kalendarzu, raz na kwartał, z osobą odpowiedzialną

Pierwsze trzy kroki to tylko odczyt i nie wpływają na pracę programu. Wykonanie kopii ręcznie obciąża dysk przez kilka do kilkudziesięciu minut, więc lepiej zrobić je poza godzinami pracy.

> **Info:** Jeśli robisz to po raz pierwszy, sprawdź też miejsce na dysku przed wykonaniem kopii. Kopia z kompresją jest zwykle wyraźnie mniejsza niż baza, ale zapełnienie dysku, na którym leży sama baza, zatrzyma program dla wszystkich.

> **W praktyce:** Jeśli wolisz, żeby ktoś to sprawdził: wyślij mi wynik obu zapytań (bez haseł i bez danych klientów, same nazwy baz, daty i ścieżki plików), a odpiszę, co z niego wynika i co poprawić w pierwszej kolejności.

**Źródła**

- backupset (Transact-SQL): kolumny database_name, backup_finish_date, type, is_copy_only (odczyt 03.11.2026), Microsoft Learn: https://learn.microsoft.com/en-us/sql/relational-databases/system-tables/backupset-transact-sql
- backupmediafamily (Transact-SQL): physical_device_name, czyli plik lub urządzenie kopii (odczyt 03.11.2026), Microsoft Learn: https://learn.microsoft.com/en-us/sql/relational-databases/system-tables/backupmediafamily-transact-sql
- RESTORE VERIFYONLY: co sprawdza i że nie weryfikuje struktury danych (odczyt 03.11.2026), Microsoft Learn: https://learn.microsoft.com/en-us/sql/t-sql/statements/restore-statements-verifyonly-transact-sql
- Editions and supported features of SQL Server 2022: SQL Server Agent niedostępny w edycji Express (odczyt 03.11.2026), Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2022

## Pytania i odpowiedzi

**Jak często powinna powstawać kopia bazy ERP?**

Co najmniej raz na dobę, po zakończeniu pracy. Ile danych firma może stracić, decyduje właściciel, a nie informatyk: jeśli utrata dnia pracy jest nie do przyjęcia, potrzebne są też kopie dziennika transakcji w ciągu dnia, które pozwalają odtworzyć bazę na wybraną godzinę.

**Czy kopia na drugim dysku w tym samym serwerze wystarczy?**

Nie. Chroni przed usunięciem danych przez pomyłkę, ale nie przed awarią serwera, pożarem, kradzieżą ani złośliwym oprogramowaniem, które szyfruje wszystko, do czego ma dostęp. Przynajmniej jedna kopia powinna leżeć poza serwerem bazy, a najlepiej także poza budynkiem.

**Czy sprawdzenie może coś zepsuć w programie?**

Oba zapytania z tego wpisu tylko czytają historię kopii z bazy msdb i nie zmieniają danych programu. Ostrożności wymaga dopiero wykonanie kopii albo test odtworzenia, bo obciążają dysk i zajmują miejsce. Te kroki warto zaplanować poza godzinami pracy.

**Mój program ma własną funkcję kopii. Czy to wystarczy?**

Może wystarczyć, jeśli wiadomo, kiedy ostatnio zadziałała, gdzie zapisuje plik i czy ktoś sprawdził odtworzenie. Funkcja w programie ma te same słabe punkty co każda inna: trzeba ją uruchamiać regularnie, a plik musi trafić poza serwer.

**Kto powinien za to odpowiadać?**

Jedna konkretna osoba, wpisana z nazwiska: firma informatyczna w umowie opieki albo pracownik. Odpowiedzialność obejmuje nie tylko ustawienie kopii, ale też odbieranie powiadomień o błędach i test odtworzenia w ustalonym terminie. Bez tego kopia działa tylko do pierwszej zmiany na serwerze.


---

SYSTEMBOX Sergiusz Siemak, Białystok. kontakt@systembox.pl, +48 570 923 234 (pn. do pt. 8 do 17).
Bezpłatna rozmowa 30 min: https://systembox.pl/umow-rozmowe. Jak wyceniam projekty: https://systembox.pl/jak-wyceniam. Cennik opieki IT: https://systembox.pl/opieka-it. Pełny kontekst: https://systembox.pl/llms-full.txt.
Projekty (systemy, integracje, automatyzacje, Recepcja AI) wyceniam indywidualnie po rozmowie. Kwoty opieki IT netto, doliczane 23% VAT.