Uszkodzenia bazy danych

Najlepszą strategią wobec uszkodzeń bazy są regularne kopie zapasowe przechowywane poza komputerem na którym jest baza. Pełny opis: Kopie baz danych →. Zalecamy też usługę kopii w chmurze.

Najczęstsze przyczyny uszkodzeń

Przyczyna	Jak się objawia	Dotyczy
Brak miejsca na dysku podczas zapisu	nagłe komunikaty „disk image is malformed"	SQLite, MariaDB
Zanik zasilania w trakcie zapisu	bazą nie da się otworzyć po starcie systemu	SQLite (mniej przy MariaDB z domyślnym `innodb_flush_log_at_trx_commit=1`)
Synchronizatory chmurowe (OneDrive, Dropbox, Google Drive) na katalogu z bazą	uszkodzenia po jednoczesnym zapisie z 2 komputerów; sync „zlewa" pliki	SQLite
Dysk sieciowy (SMB/CIFS) jako lokalizacja bazy SQLite	pliki blokowane częściowo, race conditions	SQLite — nieobsługiwane
Antywirus blokujący WAL/SHM SQLite	sporadyczne błędy zapisu, baza staje się read-only	SQLite
Przerwane połączenie sieciowe ze stanowiska klienckiego do serwera MariaDB w trakcie transakcji	komunikaty „MySQL server has gone away"	MariaDB
Problemy sprzętowe (uszkodzony RAM bez ECC, wadliwy SSD)	losowe corruption-y w różnych miejscach	wszystko
Atak ransomware / malware	pliki zaszyfrowane przez trzecią stronę	wszystko
`max_allowed_packet` za mały w MariaDB	duże zapisy KSeF / faktur padają w połowie	MariaDB
Ręczne kopiowanie pliku bazy podczas pracy programu	kopia jest niespójna, baza oryginalna może też uszkodzić	SQLite

Kiedy rozważać uszkodzenie bazy

Typowe komunikaty ze strony TaxMachine:

"Database disk image is malformed" — uszkodzenie pliku SQLite
"file is not a database" — uszkodzony header SQLite (zwykle nieodzyskiwalny)
"unable to open database file" — problem z prawami / z synchronizacją OneDrive
"MySQL server has gone away" — restart serwera lub max_allowed_packet
"Disk full" / "no space left on device" — brak miejsca, zatrzymaj zapis i zwolnij miejsce przed ponowną próbą

Nie pracuj na uszkodzonej bazie. Każda zmiana zwiększa ryzyko że uszkodzenie się rozszerzy, plus wszystkie zmiany wprowadzone po ostatniej prawidłowej kopii zostaną utracone przy odtwarzaniu kopii. Zatrzymaj program, zrób kopię uszkodzonego pliku (do osobnego katalogu) i dopiero wtedy zacznij diagnozować.

Pierwsza reakcja — odtworzenie kopii zapasowej

Jeżeli masz kopie zapasowe — to jest najszybsza i najpewniejsza ścieżka.

Zamknij TaxMachine
Skopiuj uszkodzoną bazę do osobnego katalogu (np. D:\backup-uszkodzona-2026-05-04\) — może się przydać do późniejszej forensycznej rekonstrukcji
Odtwórz najnowszą kopię (Konfiguracja → Przywróć kopię)

Uszkodzenie podczas aktualizacji schematu bazy: TaxMachine automatycznie robi kopię przed taką aktualizacją. Znajduje się w katalogu kopii (domyślnie C:\Users\Public\Documents\TaxMachine\kopie\). Odtwórz tę kopię.

MariaDB / MySQL: odtworzenie kopii do uszkodzonej bazy MySQL może nie naprawić problemu — pliki na dysku są dalej uszkodzone. Bezpieczniej utworzyć nową bazę w MariaDB i odtworzyć kopię tam, potem wskazać nową bazę w opcjach programu.

Sprawdzanie integralności pliku SQLite

Zanim ruszymy z naprawianiem — sprawdź skalę problemu. Wymaga narzędzia linii poleceń sqlite3.exe:

Instalacja sqlite3 CLI (Windows)

Wejdź na sqlite.org/download.html
W sekcji Precompiled Binaries for Windows pobierz sqlite-tools-win-x64-<wersja>.zip (~3 MB)
Rozpakuj do katalogu np. C:\Tools\sqlite\
Otwórz PowerShell (jako zwykły użytkownik) → przejdź do katalogu z bazą:
```
cd "C:\Users\Public\Documents\TaxMachine"
```

Test integralności

C:\Tools\sqlite\sqlite3.exe LocalDB.db "PRAGMA integrity_check;"

Możliwe wyniki:

ok — baza jest spójna; problem jest gdzie indziej (uprawnienia, WAL, antywirus, format wersji programu). Skonsultuj z pomocą TaxMachine.
lista błędów np. *** in database main ***\nPage 1234: btreeInitPage()… — uszkodzenia stron lub indeksów; spróbuj naprawy (sekcje niżej).
Error: file is not a database — header SQLite zniszczony; zwykle nie da się odzyskać bez backupu, idź do sekcji Forensic recovery.

Szybsza wersja (sprawdza tylko strukturę bez wszystkich rekordów):

C:\Tools\sqlite\sqlite3.exe LocalDB.db "PRAGMA quick_check;"

Naprawa metoda 1 — `.recover` (najmocniejsza)

sqlite3 .recover to dedykowane polecenie do wyciągnięcia wszystkich możliwych do odczytania danych z uszkodzonej bazy do nowej, czystej.

cd "D:\backup-uszkodzona-2026-05-04"
C:\Tools\sqlite\sqlite3.exe LocalDB.db ".recover" | C:\Tools\sqlite\sqlite3.exe LocalDB-recovered.db

Co to robi:

Czyta uszkodzony plik na poziomie B-tree
Generuje strumień SQL który odtwarza tabele, indeksy, dane (tylko te rekordy które nadal są czytelne)
Drugie wywołanie sqlite3 wykonuje ten SQL na nowym pliku

Po .recover zweryfikuj odzyskaną bazę:

C:\Tools\sqlite\sqlite3.exe LocalDB-recovered.db "PRAGMA integrity_check;"

Jeżeli ok — baza jest do użycia. Skopiuj ją do katalogu TaxMachine i wskaż w opcjach programu.

⚠️ Sprawdź zawartość! .recover może odzyskać 90% rekordów ale stracić 10% z nieczytelnych stron. Po odtworzeniu otwórz program i porównaj: liczbę dokumentów w KPiR / ewidencji ryczałtu za ostatni miesiąc, najnowsze faktury sprzedaży, podsumowanie ostatniego rejestru VAT, stan magazynu (jeśli używasz). Jeśli czegoś brakuje — mogłeś stracić ostatnie zapisy i lepiej odtworzyć starszą kopię, w której wszystko było.

Naprawa metoda 2 — `.dump` + reload

Mniej agresywna od .recover — eksportuje całą bazę do SQL-a i wczytuje z powrotem. Działa gdy uszkodzenie jest tylko w indeksach (nie w rekordach).

C:\Tools\sqlite\sqlite3.exe LocalDB.db ".dump" > dump.sql
C:\Tools\sqlite\sqlite3.exe LocalDB-rebuilt.db ".read dump.sql"
C:\Tools\sqlite\sqlite3.exe LocalDB-rebuilt.db "PRAGMA integrity_check;"

Jeśli .dump zatrzyma się na błędzie w połowie — wynikowy plik dump.sql zawiera tylko część danych do tego punktu. Lepiej wtedy iść metodą .recover.

Naprawa metoda 3 — `VACUUM INTO`

Działa tylko jeśli baza wciąż się otwiera mimo integrity_check zwracającego błędy. Tworzy nową, świeżą kopię bez fragmentacji i bez uszkodzeń tabeli wolnej (free-list).

C:\Tools\sqlite\sqlite3.exe LocalDB.db "VACUUM INTO 'LocalDB-vacuumed.db';"
C:\Tools\sqlite\sqlite3.exe LocalDB-vacuumed.db "PRAGMA integrity_check;"

Naprawa metoda 4 — przebudowa indeksów (`REINDEX`)

Gdy integrity_check wskazuje tylko na problemy w indeksach (nie w tabelach) — wystarczy:

C:\Tools\sqlite\sqlite3.exe LocalDB.db "REINDEX;"

To regeneruje wszystkie indeksy na podstawie zawartości tabel.

Naprawa metoda 5 — narzędzie konwersji baz danych w TaxMachine

Bez wychodzenia z programu TaxMachine ma własne narzędzie które przepisuje rekord-po-rekordzie z bazy źródłowej do nowej:

Narzędzie konwersji baz danych →

Jako bazę źródłową wskaż uszkodzoną
Jako bazę docelową wskaż nowy, pusty plik SQLite
Uruchom konwersję

Działa tylko jeśli rekordy są czytelne (uszkodzenie jest na poziomie indeksów lub metadanych). Po sukcesie wskaż nowy plik w opcjach programu.

Forensic recovery — gdy `.recover` nie działa

Pliki SQLite z uszkodzonym header-em (pierwsze 100 bajtów) są zwykle nieotwieralne standardowymi narzędziami. Wtedy zostają:

undark (github.com/inflex/undark) — czyta strony plik-po-pliku i wyciąga rekordy ignorując strukturę globalną; zwykle daje surową kopię tabel jako CSV/SQL
sqlite3-analyzer ze strony sqlite.org — diagnostyka która powie ile stron jest faktycznie czytelnych
Kontakt z pomocą TaxMachine — przy bardzo cennej bazie, pomożemy ocenić co da się odzyskać; w skrajnych przypadkach kontakt z firmą zajmującą się odzyskiwaniem danych (płatne, ale możliwe nawet z uszkodzonego dysku fizycznego)

Naprawa MariaDB / MySQL

Tabele w MariaDB używają InnoDB i zwykle samonaprawiają się przy starcie serwera (crash recovery z log-ów). Jeśli mimo wszystko serwer wskazuje na uszkodzoną tabelę:

-- Diagnostyka jednej tabeli (np. tabela faktur):
CHECK TABLE Faktury;

-- Zachowawcza próba naprawy (działa tylko dla MyISAM):
REPAIR TABLE Faktury;

Dla InnoDB (domyślny silnik MariaDB w nowych instalacjach) REPAIR TABLE nie działa. Zamiast tego:

Zatrzymaj serwer MariaDB
W my.ini w sekcji [mysqld] ustaw tymczasowo:
```
innodb_force_recovery = 1
```
Uruchom serwer (tryb read-only)

Wykonaj mysqldump całej bazy do pliku SQL:

"C:\Program Files\MariaDB 11.4\bin\mysqldump.exe" -u root -p taxmachine > dump.sql

Zatrzymaj serwer
Usuń innodb_force_recovery z my.ini
Utwórz nową bazę (np. taxmachine_recovered)

Wczytaj dump:

"C:\Program Files\MariaDB 11.4\bin\mysql.exe" -u root -p taxmachine_recovered < dump.sql

W TaxMachine wskaż nową bazę w opcjach

Jeżeli innodb_force_recovery = 1 nie wystarcza — możesz podnosić wartość do 6. Każdy stopień ignoruje więcej rzeczy z log-ów (i traci więcej danych) — używaj najmniejszej wartości która pozwala wykonać mysqldump.

Częste pułapki przy naprawie

❌ Praca na oryginale uszkodzonego pliku — zawsze najpierw skopiuj go do innego katalogu i pracuj na kopii
❌ Nadpisywanie kopii zapasowej odtworzoną bazą bez weryfikacji zawartości — sprawdź najpierw że baza jest kompletna
❌ Ignorowanie integrity_check — jeśli zwraca błędy, baza jest uszkodzona nawet gdy program ją otwiera; tylko kwestia czasu kiedy problem się objawi w gorszy sposób
❌ Praca z uszkodzoną bazą "tylko jeszcze parę godzin" — zwiększa rozmiar uszkodzenia, traci dane z ostatniej dobrej kopii

Po odzyskaniu danych

Zweryfikuj zawartość — najnowsze faktury, dokumenty, deklaracje za bieżący miesiąc, stan magazynu
Zrób natychmiast kopię odzyskanej bazy do bezpiecznego miejsca
Zdiagnozuj przyczynę — jeśli to dysk, wymień. Jeśli to synchronizator chmurowy, wyłącz dla katalogu bazy. Jeśli to antywirus, dodaj wyjątki dla *.db, *.db-wal, *.db-shm w katalogu TaxMachine
Wzmocnij strategię backupową — jeśli polegałeś tylko na wbudowanym mechanizmie, dodaj kopie off-site (chmura, NAS, dysk USB trzymany w innej lokalizacji)
Sprawdź harmonogram kopii — czy realnie jest wykonywany? Test odtworzenia →