Płatnik
Naprawa uszkodzonych baz .mdb (Access) oraz migracje do SQL.
Dysk i Spółka • Bazy danych / B2B
Naprawa i odzyskiwanie baz danych Płatnik, Optima, SQL i Subiekt
Diagnozujemy uszkodzone bazy, pliki logów, backupy i środowiska firmowe bez kolejnych prób naprawy na produkcji.
Płatnik / Optima
SQL Server
Subiekt / Access
NDA / B2B
Tryb B2B / bazy produkcyjne
Baza nie uruchamia się, serwer SQL zgłasza tryb suspect albo po awarii serwera nie widać danych? Najpierw zabezpiecz środowisko.
Awaria Płatnika, Optimy albo SQL Servera nie zawsze oznacza fizyczne uszkodzenie nośnika. Ta strona dotyczy sytuacji, w których kluczowy jest stan bazy, logów i środowiska aplikacyjnego — a nie ogólny odzysk z dowolnego dysku. W Dysk i Spółka diagnozujemy zarówno uszkodzenia plików baz, jak i przypadki, w których baza przestała działać po awarii systemu, zasilania, kontrolera RAID, serwera lub środowiska wirtualnego.
W sprawach firmowych liczy się nie tylko sam plik bazy, ale też spójność logów, konfiguracja usługi i bezpieczna procedura B2B. Dlatego przed naprawą lub migracją najpierw ustalamy, czy problem dotyczy nośnika, silnika SQL, plików bazy, wolumenu czy całego środowiska serwerowego.
Płatnik
Optima
Subiekt
SQL Server
Access
bazy księgowe
tryb B2B
Zakres systemów
Jakie bazy danych obsługujemy?
Odzyskujemy sprawność systemów finansowo-księgowych i magazynowych.
Optima / XL
Odzyskiwanie baz Microsoft SQL Server (.mdf, .ldf).
Subiekt / Rewizor
Naprawa baz po awarii zasilania lub dysku.
SQL Server
Diagnoza baz SQL, plików danych i logów po błędach spójności.
.mdb / .accdb
Praca z bazami Access używanymi w Płatniku i systemach biurowych.
Bazy księgowe i magazynowe
Systemy finansowo-księgowe, kadrowe i magazynowe po awarii środowiska.
.mdf / .ldf / .db
Pliki baz, logi transakcyjne, kopie robocze i eksporty z ostatniego dnia pracy.
VM / NAS / RAID
Diagnoza baz uruchamianych na serwerach, macierzach, NAS-ach i maszynach wirtualnych.
Scenariusze awarii
Kiedy możemy pomóc?
Awaria sprzętowa
Serwer lub dysk z bazą przestał działać (uszkodzenie fizyczne, RAID offline). Wykonujemy kopię sektorową i odzyskujemy możliwie spójny plik bazy.
Database Corrupted / Page Fault
Baza jest widoczna, ale silnik SQL zgłasza błąd spójności, Consistency Check Error albo Page Fault.
Suspect Mode
Serwer SQL oznaczył bazę jako uszkodzoną po restarcie lub przerwanym zapisie.
Skasowanie bazy
Przypadkowe usunięcie plików bazy lub sformatowanie woluminu.
Awaria po zaniku zasilania
Baza przestała działać po przerwie w zasilaniu, zawieszeniu systemu albo restarcie serwera.
Problem po naprawie lub migracji
Nieudana aktualizacja, ręczna naprawa indeksów albo przywracanie kopii pogorszyły stan środowiska.
Procedura ratunkowa
Bezpieczeństwo B2B
Wiemy, że przestój w firmie kosztuje fortunę, dlatego proces zaczynamy od zabezpieczenia stanu i ryzyka.
Priorytet firmowy
Zlecenia na bazy danych traktujemy jako pilne; awaryjny tryb pracy 24/7 jest możliwy po wcześniejszym uzgodnieniu.
Poufność / NDA
Podpisujemy NDA. Twoje dane finansowe są bezpieczne (pracujemy w trybie offline).
Praca na kopii
Najpierw zabezpieczamy materiał źródłowy, a diagnostykę prowadzimy na kopii roboczej.
Weryfikacja działania
Przed płatnością sprawdzamy, czy baza daje się poprawnie zamontować i czy można wyświetlić najnowsze faktury oraz deklaracje.
Pierwsze decyzje
Awaria bazy danych – co robić od razu, żeby nie pogorszyć sytuacji
Gdy baza (np. Płatnik, Optima, SQL, Subiekt) przestaje się otwierać, najgorszym rozwiązaniem są wielokrotne "naprawy" i kolejne próby uruchamiania. Często problemem jest uszkodzenie plików bazy, błędy dysku albo brak miejsca — a każda kolejna próba potrafi dopisać nowe błędne dane.
Zrób teraz
- przerwij pracę na komputerze/serwerze i zabezpiecz kopię aktualnych plików bazy
- zapisz komunikaty błędów (zrzut ekranu) – to często klucz do diagnozy
- jeśli pilnie potrzebujesz rozliczeń lub deklaracji, zaznacz to w zgłoszeniu
Nie rób
- nie instaluj niczego i nie przenoś plików pochopnie
- nie uruchamiaj wielu "napraw" i nie nadpisuj starych plików bazy nowymi
- nie pracuj dalej na oryginalnym nośniku, jeśli pojawiły się błędy odczytu
W laboratorium najpierw wykonujemy bezpieczny obraz nośnika, a dopiero potem pracujemy na kopii. Dzięki temu nie ryzykujesz utraty resztek danych.
Decyzja diagnostyczna
Jak odróżnić problem bazy od problemu dysku (bez wchodzenia w detale)
Jeśli komputer nagle zwalnia, pliki otwierają się bardzo długo albo pojawiają się błędy kopiowania, to często sygnał, że problem leży w nośniku, a nie w samej aplikacji. Z kolei komunikaty o "uszkodzonej bazie", brak dostępu do tabel lub błędy spójności mogą wynikać z przerwanego zapisu.
Problem logiczny
Komunikaty o uszkodzonej bazie, brak dostępu do tabel, Consistency Check Error, Page Fault albo Suspect Mode po restarcie.
Problem dysku lub serwera
Długi odczyt, błędy kopiowania, znikające pliki, awaria zasilania, RAID offline albo zawieszanie się systemu.
błędy spójności
długi odczyt
błędy kopiowania
suspect mode
przerwany zapis
awaria zasilania
W praktyce najbezpieczniej jest potraktować sytuację jak potencjalną awarię danych: nie generować nowych zapisów i zabezpieczyć stan "tu i teraz".
Powiązane ścieżki
To problem z bazą danych czy szersza awaria środowiska firmowego?
Jeżeli problem dotyczy Płatnika, Optimy, SQL lub Subiekta, wybierz tę ścieżkę. Dla pionu księgowego i ogólnej awarii B2B masz osobne strony.
Szybka konsultacja
Zgłoś bazę do analizy z pomocą laboratorium
Masz pytania? Skontaktuj się z nami, zanim kolejne próby naprawy nadpiszą pliki lub logi.
Jak przygotować pliki, logi i środowisko do diagnozy bazy danych
W zgłoszeniach bazodanowych liczą się nie tylko pliki .mdf, .ldf, .db i kopie robocze. Przyspiesza też kontekst: nazwa programu, wersja systemu, ostatni poprawny zapis oraz komunikaty błędów z konsoli lub aplikacji.
Pliki bazy
.mdf, .ldf, .db, .mdb, kopie robocze i oryginalne katalogi programu.
Logi SQL / aplikacji
Komunikaty błędów z konsoli, SQL Servera lub programu księgowego.
Backup / snapshot
Aktualna kopia zapasowa, snapshot albo eksport z ostatniego dnia pracy.
Wersja programu
Nazwa programu, wersja systemu i informacja, czy baza była na serwerze czy komputerze.
Komunikaty błędów
Treść błędu, zrzut ekranu i moment ostatniego poprawnego uruchomienia.
Ostatnia poprawna praca
Informacja, czy po awarii ktoś robił naprawę SQL, aktualizację lub przywracanie kopii.
Skrócenie diagnozy
Jakie pliki i informacje naprawdę przyspieszają diagnozę
Najsprawniej pracujemy, gdy razem z bazą dostajemy podstawowy kontekst: strukturę katalogów programu, logi serwera, nazwy użytkowników i datę ostatniego prawidłowego zapisu. Ważna jest też informacja, czy problem pojawił się po awarii prądu, błędzie dysku, aktualizacji systemu czy ataku ransomware.
struktura katalogów programu
logi serwera i nazwy użytkowników
data ostatniego prawidłowego zapisu
informacja o kopiowaniu plików "na gorąco"
ręczna naprawa indeksów lub przywracanie kopii
decyzja: kopia logiczna, obraz nośnika czy struktura bazy
Ryzykowne próby
Czego nie robić po błędzie bazy danych
- Nie uruchamiaj kilku narzędzi naprawczych jedno po drugim "żeby coś zaskoczyło".
- Nie przywracaj starych kopii na te same pliki bez zachowania oryginału.
- Nie kompresuj i nie przenoś uszkodzonej bazy między komputerami bez kopii binarnej.
- Nie zakładaj, że problem jest wyłącznie programowy, jeśli wcześniej były błędy dysku, zanik zasilania albo zawieszanie systemu.
Kiedy eskalować
Kiedy kontakt z laboratorium ma największy sens
Jeżeli aplikacja przestała otwierać bazę po awarii prądu, system zgłasza błędy odczytu, serwer znika z sieci albo pliki mają nienaturalne rozmiary, lepiej nie wykonywać kolejnych prób na oryginale.
Błędy odczytu lub kopiowania
Problem może wychodzić poza samą bazę i dotyczyć nośnika albo środowiska serwerowego.
Awaria prądu lub restart
Przerwany zapis może uszkodzić spójność bazy, logów i katalogu programu.
Serwer znika z sieci
Warto zabezpieczyć stan "tu i teraz", zanim kolejne próby pracy zwiększą chaos.
Pliki mają nienaturalne rozmiary
To sygnał, że potrzebna jest spokojna diagnostyka zamiast improwizowanej naprawy na oryginale.
Logika czy nośnik
Kiedy problem z bazą jest logiczny, a kiedy może oznaczać awarię nośnika?
Nie każdy błąd bazy danych oznacza od razu fizyczne uszkodzenie dysku, ale są sytuacje, w których trzeba brać to pod uwagę: opóźniony zapis, problemy z kopiowaniem, zawieszanie się systemu albo znikające pliki.
FAQ
FAQ — odzyskiwanie i naprawa baz danych Płatnik, Optima, SQL i Subiekt
Czy naprawiacie bazę, czy odzyskujecie ją z kopii?
To zależy od przypadku. Czasem potrzebna jest naprawa struktury bazy, a czasem bezpieczniejsze jest odtworzenie i odzysk danych z kopii roboczej lub uszkodzonego środowiska.
Jakie pliki i informacje warto przygotować przed diagnozą?
Najlepiej zgromadzić pliki bazy, logi, informacje o wersji systemu, komunikatach błędów oraz opis momentu awarii. To skraca czas wejścia w właściwą diagnozę.
Czy pracujecie z przypadkami pilnymi dla księgowości i firm?
Tak, bo takie awarie często blokują bieżącą pracę operacyjną. Zakres i tryb działania ustalamy po ocenie ryzyka oraz dostępności materiału źródłowego.
Czy po naprawie można sprawdzić spójność danych?
Tak, po stronie technicznej da się ocenić, czy baza uruchamia się poprawnie i czy zachowuje wymaganą strukturę. Zakres testów zależy od systemu i danych wejściowych.
Zabezpiecz środowisko
Zabezpiecz bazę zanim kolejne próby nadpiszą dane
Pracujemy w trybie B2B, na kopii, z możliwością NDA i weryfikacją działania bazy przed przekazaniem wyniku.