Płatnik, Optima i Subiekt po awarii bazy — czego nie robić przed diagnozą

Jeżeli po awarii komputera, serwera albo dysku program księgowy nagle nie otwiera bazy, najgorsze decyzje zapadają zwykle w pierwszych minutach. W firmie rośnie presja czasu, ktoś chce "tylko uruchomić system", a w tle pojawiają się pomysły na szybką naprawę, kopiowanie plików MDB/MDF na oślep albo odbudowę środowiska bez sprawdzenia, co naprawdę uległo uszkodzeniu.

Kiedy problem wygląda jak awaria programu, a naprawdę zaczyna się od nośnika

Płatnik, Optima i Subiekt często są pierwszym miejscem, w którym firma zauważa incydent, ale nie zawsze są jego źródłem. Jeżeli wcześniej były zawieszenia, błędy wejścia/wyjścia, znikające katalogi, spowolnienie pracy albo restart po zaniku zasilania, to równie prawdopodobne jest uszkodzenie dysku, kontrolera, macierzy lub samego środowiska SQL.

W praktyce najgroźniejsze są sytuacje, w których ktoś zakłada, że "to tylko plik programu", i zaczyna przenosić bazę między stanowiskami, uruchamiać narzędzia naprawcze albo nadpisywać istniejące pliki nową instalacją. Taki ruch może utrudnić późniejsze odzyskanie i naprawę bazy danych albo całkowicie skasować ślady potrzebne do diagnozy.

Czego nie robić przed diagnozą

• Nie uruchamiaj CHKDSK ani innych napraw systemu plików na nośniku z bazą.
• Nie kopiuj plików bazy "na próbę" między uszkodzone a nowe środowisko.
• Nie aktualizuj programu księgowego, jeżeli nie masz potwierdzenia, że baza i nośnik są spójne.
• Nie przywracaj backupu na ten sam uszkodzony dysk, aby "sprawdzić, czy wstanie".
• Nie uruchamiaj wielu prób attach/repair na tej samej bazie, jeśli źródło problemu może leżeć w dysku lub SQL.

Jak zebrać informacje potrzebne do sensownej diagnozy

Zanim zgłosisz sprawę, przygotuj listę faktów zamiast hipotez. Najbardziej przydają się: nazwa programu, wersja systemu, typ bazy, dokładny komunikat błędu, ostatni moment poprawnej pracy, informacja o backupach i o tym, czy problem dotyczy pojedynczego stanowiska czy całej firmy.

Warto też od razu zapisać, gdzie fizycznie znajdują się pliki: na lokalnym SSD, na serwerze, NAS-ie, w maszynie wirtualnej albo na współdzielonym zasobie. Dla biur rachunkowych i działów finansowych to często ważniejsze niż sam komunikat o błędzie, bo pozwala odróżnić awarię aplikacji od awarii infrastruktury.

Objawy, które sugerują problem z dyskiem lub środowiskiem

Jeżeli oprócz błędu programu pojawiają się RAW, znikające woluminy, błędy CRC, nietypowe dźwięki HDD albo komunikaty o naprawie systemu plików, najpierw trzeba traktować incydent jako problem z nośnikiem. W takich przypadkach równolegle przydają się materiały o awarii dysku z danymi księgowymi oraz o pierwszych 24 godzinach po awarii serwera lub NAS.

Backup to nie wszystko, jeżeli nie wiesz, czy jest spójny

W wielu firmach istnieje przekonanie, że skoro "mamy kopię", to można od razu przywracać środowisko. Problem w tym, że po awarii dysku lub serwera backup bywa niepełny, stary albo logicznie niespójny. Dotyczy to zwłaszcza sytuacji, w których kopie były wykonywane podczas pracy programu albo bez testu odtwarzania.

Dlatego przed decyzją o przywróceniu warto odpowiedzieć na trzy pytania: z którego dnia jest ostatnia pewna kopia, czy obejmuje wszystkie komponenty programu i czy da się ją uruchomić poza produkcją. Jeżeli odpowiedź na któreś z nich brzmi "nie wiem", nie warto wykonywać kolejnych operacji na uszkodzonym środowisku bez konsultacji.

Jak wygląda bezpieczna ścieżka B2B po takim incydencie

W praktyce dobra ścieżka składa się z trzech warstw: zabezpieczenie środowiska, diagnoza nośnika/bazy i dopiero potem decyzja o naprawie albo odzysku. Dla firm ważne jest też to, kto ma dostęp do danych i jak dokumentowane są działania po incydencie. Gdy w bazie są dane klientów lub pracowników, od początku trzeba myśleć również o poufności i NDA.

Jeżeli sprawa dotyczy wielu stanowisk, procesów księgowych albo danych kadrowych, rozsądnym kierunkiem jest równoległe przejście do strony dla biur rachunkowych i księgowości oraz przygotowanie jednego właściciela incydentu po stronie firmy. To znacząco zmniejsza chaos i ogranicza liczbę ryzykownych decyzji podejmowanych równolegle.

FAQ przed kontaktem

Czy da się odzyskać bazę, jeśli program przestał się otwierać po restarcie?

Tak, ale najpierw trzeba ustalić, czy problem dotyczy samej bazy, systemu plików, dysku czy SQL Servera. Bez tej diagnozy łatwo pogorszyć sytuację.

Czy można od razu przywrócić backup?

Tak tylko wtedy, gdy masz pewność, że kopia jest spójna i że przywracasz ją poza uszkodzonym środowiskiem. W przeciwnym razie możesz stracić czas i nadpisać ważne ślady.

Kiedy potrzebne jest NDA?

W środowiskach B2B z danymi księgowymi, kadrowymi lub klientów warto ustalić to jeszcze przed przekazaniem nośnika albo kopii roboczej.

Kiedy przejść od analizy do zgłoszenia sprawy

Jeżeli nie masz pewności, czy problem leży w bazie, nośniku czy serwerze, a jednocześnie firma nie może długo czekać, nie warto mnożyć prób na produkcji. Najbezpieczniej zebrać objawy, wskazać krytyczne katalogi i przejść do kontaktu z laboratorium. W sprawach stricte bazodanowych właściwą ścieżką jest usługa naprawy i odzyskiwania baz danych, a jeżeli incydent dotyczy całej organizacji — także ścieżka B2B dla firm.