Naprawa i odzyskiwanie baz danych Płatnik, Optima, SQL i Subiekt — tryb B2B

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.

Co przygotować do pierwszego kontaktu w sprawie bazy danych:

nazwę programu lub silnika bazy oraz objaw błędu (np. suspect, corrupted, page fault)
informację, czy problem dotyczy pojedynczego komputera, serwera, NAS-a czy macierzy RAID
czy istnieje aktualna kopia zapasowa, snapshot albo ostatni poprawny backup

Jeśli to sprawa pilna, opisz objawy przez formularz albo zadzwoń — ustalimy, co zabezpieczyć przed dalszymi próbami naprawy.

Jakie bazy danych obsługujemy?

Odzyskujemy sprawność systemów finansowo-księgowych i magazynowych:

ZUS Płatnik: Naprawa uszkodzonych baz .mdb (Access) oraz migracje do SQL.
Comarch ERP Optima/XL: Odzyskiwanie baz Microsoft SQL Server (.mdf, .ldf).
InsERT (Subiekt GT/Nexo, Rewizor): Naprawa baz po awarii zasilania lub dysku.
Symfonia/Sage: Odzyskiwanie danych z baz Pervasive PSQL i MS SQL.
Bazy SQL: Microsoft SQL Server, MySQL, PostgreSQL, Firebird.
Poczta e-mail: Naprawa dużych plików .PST i .OST (Microsoft Outlook).

Kiedy możemy pomóc?

Awaria sprzętowa: Serwer lub dysk z bazą przestał działać (uszkodzenie fizyczne, RAID offline). To nasza główna specjalizacja — wykonujemy kopię sektorową i odzyskujemy możliwie spójny plik bazy.
Błąd "Database Corrupted": Baza jest widoczna, ale silnik SQL zgłasza błąd spójności (Consistency Check Error, Page Fault).
Błąd "Suspect Mode": Serwer SQL oznaczył bazę jako uszkodzoną po restarcie.
Skasowanie bazy: Przypadkowe usunięcie plików bazy lub sformatowanie woluminu.

Procedura ratunkowa (Bezpieczeństwo B2B)

Wiemy, że przestój w firmie kosztuje fortunę.

Priorytet: Zlecenia na bazy danych traktujemy jako pilne (możliwy tryb pracy 24/7).
Poufność: Podpisujemy NDA. Twoje dane finansowe są bezpieczne (pracujemy w trybie offline).
Weryfikacja: Przed płatnością sprawdzamy, czy baza daje się poprawnie zamontować i czy można wyświetlić najnowsze faktury oraz deklaracje.

Zadzwoń: 573 532 490 Opisz awarię bazy online

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.

Jeśli to możliwe, przerwij pracę na komputerze/serwerze i zabezpiecz kopię aktualnych plików bazy. W firmach najczęstszy scenariusz to: awaria dysku, błąd kontrolera, przerwa w zasilaniu albo nieudana aktualizacja. Dobrą wiadomością jest to, że w wielu przypadkach da się odzyskać dane lub przywrócić spójność bazy.

W laboratorium najpierw wykonujemy bezpieczny obraz nośnika, a dopiero potem pracujemy na kopii. Dzięki temu nie ryzykujesz utraty resztek danych. Jeśli pilnie potrzebujesz rozliczeń lub deklaracji, zaznacz to w zgłoszeniu, aby nadać sprawie odpowiedni priorytet.

Zatrzymaj zapisy na dysk (nie instaluj niczego, nie przenoś plików pochopnie).
Nie uruchamiaj wielu "napraw" i nie nadpisuj starych plików bazy nowymi.
Zapisz komunikaty błędów (zrzut ekranu) – to często klucz do diagnozy.

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 (np. podczas awarii zasilania).

W praktyce najbezpieczniej jest potraktować sytuację jak potencjalną awarię danych: nie generować nowych zapisów i zabezpieczyć stan "tu i teraz". Dzięki temu możemy odtworzyć bazę albo odzyskać jej kopie robocze bez utraty kolejnych rekordów.

Nie wykonuj pochopnej reinstalacji systemu — to często nadpisuje pliki i logi.
Jeśli masz kopie zapasowe – nie przywracaj ich na to samo miejsce bez konsultacji.
W zgłoszeniu wpisz nazwę programu (Płatnik/Optima/Subiekt/SQL) i datę ostatniego poprawnego uruchomienia.

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.

Najważniejsze strony w tym klastrze:

Zgłoś nośnik do analizy – odzyskaj dane z pomocą ekspertów

Masz pytania? Skontaktuj się z naszym laboratorium odzyskiwania danych. Zadzwoń 573 532 490

Jak przygotować pliki, logi i środowisko do diagnozy bazy danych

W zgłoszeniach bazodanowych największą wartość mają nie tylko same pliki .mdf, .ldf, .db czy kopie robocze, ale też kontekst: nazwa programu, wersja systemu, ostatni moment poprawnej pracy i komunikaty błędów z konsoli lub aplikacji. Dzięki temu szybciej odróżniamy awarię samej bazy od awarii środowiska, dysku albo maszyny wirtualnej.

Jeżeli masz dostęp do kopii zapasowej, logów SQL Servera, katalogu programu albo eksportu z ostatniego dnia pracy, nie nadpisuj nimi oryginalnych plików. Najbezpieczniej zachować stan "tu i teraz" i dopiero potem ustalić kolejny krok diagnostyczny. W sprawach firmowych, księgowych i kadrowych często największym problemem nie jest sama baza, tylko pośpiech i seria przypadkowych prób naprawy.

zapisz nazwę programu i wersję bazy: Płatnik, Optima, Subiekt, SQL Server, Access lub inny system,
zachowaj komunikaty błędów, datę ostatniego poprawnego uruchomienia i informację, czy po awarii ktoś robił naprawę SQL lub przywracanie kopii,
nie reinstaluj programu i nie podmieniaj plików bazy bez kopii oryginału.

Jakie pliki i informacje naprawdę przyspieszają diagnozę

W praktyce najszybciej pracuje się wtedy, gdy razem z bazą dostajemy również podstawowy kontekst: strukturę katalogów programu, logi serwera, nazwy użytkowników, datę ostatniego prawidłowego zapisu i informację, czy problem pojawił się po awarii prądu, błędzie dysku, aktualizacji systemu czy ataku ransomware. Bez tego trzeba najpierw odtworzyć historię zdarzeń, a dopiero potem diagnozować uszkodzenie logiczne lub fizyczne.

W przypadku systemów księgowych i kadrowych często znaczenie mają też pozornie drobne rzeczy: czy baza była na serwerze czy na pojedynczym komputerze, czy pracowała przez udział sieciowy, czy ktoś kopiował pliki "na gorąco", czy wykonywano ręczną naprawę indeksów. To są szczegóły, które mogą decydować o tym, czy bezpieczniej będzie pracować na kopii logicznej, obrazie nośnika czy bezpośrednio na strukturze bazy.

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.

Jeżeli problem dotyczy środowiska produkcyjnego, najpierw zabezpiecz to, co jest: aktualny stan plików, katalog programu, logi i ewentualny nośnik. Dopiero potem warto zdecydować, czy to scenariusz dla odzyskiwania danych z dysku, odzyskiwania z serwera lub RAID, czy stricte dla naprawy bazy. W wielu przypadkach awaria bazy to tylko objaw większego problemu z pamięcią masową.

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. Dotyczy to szczególnie baz Płatnika, Optimy, Subiekta oraz środowisk SQL, gdzie uszkodzenie może dotyczyć zarówno struktury logicznej, jak i samego nośnika. W takich sytuacjach liczy się szybkie zabezpieczenie stanu i spokojna diagnostyka, a nie improwizowana "naprawa na ślepo".

Jeśli chcesz wcześniej uporządkować temat od strony firmowej, zobacz też materiały o obsłudze biur rachunkowych i księgowości, awarii dysku z danymi księgowymi i RODO oraz pierwszych 24 godzinach po awarii serwera lub NAS.

Jak przygotować pliki i informacje, żeby nie wydłużać naprawy bazy?

W przypadku baz danych ogromne znaczenie ma nie tylko sam plik, ale też kontekst awarii. Warto zapisać nazwę programu, wersję systemu, treść komunikatu błędu, moment wystąpienia problemu i to, czy równolegle były wykonywane aktualizacje, restart serwera albo kopia bezpieczeństwa. Dla systemów takich jak Płatnik, Optima, SQL Server czy Subiekt takie informacje pomagają ocenić, czy problem dotyczy logicznej spójności bazy, uszkodzenia plików, czy może awarii samego nośnika.

Jeżeli dostępne są kopie zapasowe, pliki logów albo wcześniejsze wersje bazy, warto je zabezpieczyć i nie nadpisywać. To samo dotyczy eksportów, archiwów i lokalnych plików roboczych. Im mniej chaotycznych prób "naprawy" na żywym środowisku, tym większa szansa, że odzysk danych i odbudowa struktury bazy przebiegną szybciej i bez dodatkowych strat.

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ę. Jeżeli obok błędów aplikacji pojawiają się też komunikaty o opóźnionym zapisie, problemy z kopiowaniem, zawieszanie się systemu albo znikające pliki, problem może wychodzić poza samą bazę. Wtedy szybka próba dalszej pracy na tym samym nośniku bywa ryzykowna, bo może prowadzić do dalszej degradacji danych.

W praktyce warto wtedy równolegle spojrzeć na scenariusze opisane w artykułach Awaria dysku, dane księgowe i RODO, pierwsze 24 godziny po awarii serwera lub NAS oraz odzyskiwanie danych dla firm. Dzięki temu łatwiej zdecydować, czy temat zamyka się w naprawie logicznej, czy wymaga już pełnej diagnostyki nośnika w laboratorium.

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.