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, kopie zapasowe 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 laboratorium 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.
Przy SQL Server suspect mode, uszkodzonych plikach MDF/LDF, błędach Płatnika, Optimy albo Subiekta najpierw zabezpiecz kopię katalogów, logi i ostatni poprawny stan. Nie uruchamiaj automatycznej naprawy na produkcji, jeśli to jedyny egzemplarz danych.
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".
MDF / LDF / aplikacje księgowe
Uszkodzony plik MDF, LDF albo baza Płatnik, Optima lub Subiekt? Najpierw zatrzymaj naprawy na produkcji.
Jeśli SQL Server zgłasza suspect mode albo plik MDF/LDF nie daje się podłączyć, zatrzymaj naprawy na produkcji. To samo dotyczy Płatnika, Optimy i Subiekta po awarii dysku.
Nie uruchamiaj REPAIR_ALLOW_DATA_LOSS na jedynym egzemplarzu danych. Najpierw zabezpiecz pliki MDF, LDF, logi, kopie zapasowe i informację o wersji SQL oraz programu.
W zgłoszeniu podaj, czy baza działała na serwerze, macierzy RAID, NAS-ie albo maszynie wirtualnej, kiedy powstała ostatnia sprawna kopia i jakie komunikaty pokazuje aplikacja.
MDF / LDF / suspect mode
Zapisz komunikat błędu, wersję SQL Servera i ostatnią sprawną kopię. Nie odłączaj ani nie nadpisuj logów, jeśli baza była na macierzy, NAS-ie lub serwerze.
Baza księgowa nie startuje
Przygotuj katalog programu, pliki bazy, logi i informację, czy ktoś próbował importu, aktualizacji lub automatycznej naprawy po awarii.
Ścieżka dla firm i księgowości
Jeżeli przestój blokuje faktury, kadry lub rozliczenia, opisz priorytet biznesowy w zgłoszeniu. To pomaga dobrać bezpieczny kolejny krok.
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.
Płatnik, Optima lub Subiekt nie otwiera bazy po awarii
SQL Server po awarii dysku lub serwera
Strona dla biur rachunkowych i księgowości
Główna ścieżka B2B po awarii danych firmowych
Ścieżka RAID po awarii serwera lub macierzy
Ścieżka NAS Synology/QNAP z bazami firmowymi
Analiza ransomware, gdy baza została zaszyfrowana
Cennik odzyskiwania baz danych i spraw B2B
FAQ: bazy danych, VM i systemy
Szybka konsultacja
Przekaż 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.
kopia zapasowa / 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.
Środowisko źródłowe
Baza z dysku, serwera, NAS albo kopii zapasowej — najpierw zabezpiecz oryginał
W sprawach Płatnik, Optima, Subiekt i SQL problem często nie leży wyłącznie w pliku bazy. Awaria dysku, macierzy RAID, NAS-a albo kopii zapasowej może powodować błędy spójności, brak logów, uszkodzone indeksy lub brak dostępu do ostatnich zapisów. Dlatego nie importujemy danych bez planu na oryginalnym nośniku i nie nadpisujemy ostatniej kopii roboczej bez planu.
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.