Awaria komputera z Subiektem GT - co zrobić, żeby nie stracić danych?

Awaria komputera z Subiektem GT to dla wielu małych firm jeden z najgorszych scenariuszy. Program nie uruchamia się, komputer nie startuje, dysk wydaje dziwne dźwięki albo system Windows pokazuje błąd. Nagle okazuje się, że na tym jednym stanowisku były faktury, magazyn, kontrahenci, rozrachunki i cała historia pracy firmy. W takiej sytuacji najważniejsze są dwie rzeczy: nie pogorszyć sytuacji i jak najszybciej ustalić, gdzie znajdują się dane.

Subiekt GT korzysta z bazy danych SQL Server. To bardzo ważne, bo dane firmy nie są zwykłym plikiem zapisanym w folderze z programem. Baza może znajdować się na tym samym komputerze, na osobnym serwerze albo w środowisku chmurowym. Od tego zależy, jak poważna jest awaria i jakie działania trzeba podjąć.

Pierwsze pytanie brzmi: czy uszkodzony komputer był tylko stanowiskiem pracy, czy pełnił też rolę serwera? Jeżeli baza Subiekta znajduje się na innym komputerze, serwerze lub w chmurze, awaria pojedynczego stanowiska zwykle nie oznacza utraty danych. W takim przypadku trzeba naprawić komputer albo przygotować nowe stanowisko i ponownie podłączyć je do istniejącej bazy.

Gorzej, jeśli uszkodzony komputer był jedynym miejscem, na którym działał Subiekt i SQL Server. Wtedy awaria dotyczy nie tylko programu, ale również bazy danych. To częsty scenariusz w małych firmach, gdzie Subiekt przez lata działał na jednym komputerze przy biurku, a kopie zapasowe wykonywano nieregularnie albo wcale.

Jeżeli nie masz pewności, gdzie jest baza, nie warto działać na ślepo. Trzeba sprawdzić konfigurację programu, nazwy instancji SQL, kopie zapasowe, pliki bazy i historię pracy. Chaotyczne naprawianie systemu może utrudnić późniejsze odzyskanie danych.

Jednym z najgorszych ruchów przy awarii jest szybka reinstalacja Windowsa bez sprawdzenia danych. Jeżeli na dysku znajduje się baza SQL, formatowanie lub nadpisanie systemu może utrudnić albo uniemożliwić odzyskanie informacji. Nawet jeśli komputer „i tak nie działa”, dysk może nadal zawierać ważne dane.

Przed reinstalacją należy zabezpieczyć nośnik. Najlepiej wyjąć dysk i wykonać jego kopię lub sprawdzić go na innym komputerze w trybie, który nie modyfikuje danych. Jeżeli dysk jest fizycznie uszkodzony, klika, znika z systemu albo bardzo wolno się odczytuje, lepiej nie próbować wielokrotnych uruchomień. Każda kolejna próba może pogorszyć stan nośnika.

W przypadku bazy SQL ważne jest także to, czy posiadasz aktualną kopię zapasową wykonaną z poziomu programu lub SQL Servera. Taka kopia jest znacznie bezpieczniejsza niż przypadkowo skopiowane pliki z katalogu danych.

Jeżeli komputer z Subiektem uległ awarii, kopia zapasowa jest najważniejszym elementem ratunkowym. Warto sprawdzić, czy firma posiada archiwum Subiekta, backup bazy SQL, kopię całego serwera, kopię na zewnętrznym dysku, kopię w chmurze albo backup wykonywany przez dostawcę IT.

Problem polega na tym, że wiele firm myli samo wykonywanie kopii z posiadaniem działającego backupu. Kopia może być stara, niepełna, uszkodzona albo zapisywana na tym samym dysku, który właśnie uległ awarii. Dlatego trzeba sprawdzić nie tylko to, czy plik istnieje, ale również czy da się go odtworzyć.

Dobra praktyka jest prosta: kopia powinna być wykonywana regularnie, przechowywana poza głównym komputerem i okresowo testowana. Jeśli firma nigdy nie sprawdzała odtwarzania kopii, to w dniu awarii może się okazać, że backup daje fałszywe poczucie bezpieczeństwa.

Zakres odzyskiwania zależy od rodzaju awarii. Jeżeli uszkodził się system Windows, ale dysk jest sprawny, często można odzyskać bazę, pliki konfiguracyjne i archiwa. Jeżeli uszkodził się zasilacz, płyta główna lub pamięć RAM, dane na dysku mogą być nienaruszone. Wtedy przeniesienie bazy do nowego środowiska jest zwykle możliwe.

Trudniejsza sytuacja występuje przy awarii dysku. Jeśli nośnik jest uszkodzony logicznie, czasem da się odzyskać pliki. Jeśli jest uszkodzony mechanicznie lub elektronicznie, potrzebne może być specjalistyczne odzyskiwanie danych. W przypadku firmowych baz danych liczy się czas, ale też ostrożność. Lepiej nie wykonywać przypadkowych napraw narzędziami znalezionymi w internecie, bo mogą nadpisać dane.

Jeżeli uda się odzyskać pliki bazy, trzeba je poprawnie podłączyć do SQL Servera lub odtworzyć z kopii. Sama obecność plików nie oznacza jeszcze, że program od razu ruszy. Ważna jest zgodność wersji, konfiguracja SQL, uprawnienia i poprawne środowisko pracy.

Najlepszy scenariusz to odtworzenie Subiekta na nowym komputerze lub serwerze z aktualnej kopii zapasowej. Wtedy można zainstalować odpowiednie oprogramowanie, przygotować SQL Server, przywrócić bazę, skonfigurować użytkowników, drukarki i dostęp do programu. Jeżeli backup jest aktualny i sprawny, przestój może być stosunkowo krótki.

Jeżeli kopia jest stara, trzeba ustalić, jak dużo danych brakuje i czy da się je odtworzyć z dokumentów papierowych, plików JPK, faktur PDF, e-maili lub innych źródeł. To mniej komfortowe, ale czasem pozwala zminimalizować straty.

W firmach, które nie mogą pozwolić sobie na dłuższy przestój, warto rozważyć przeniesienie środowiska do chmury. Wtedy Subiekt nie jest uzależniony od jednego komputera w biurze. Nawet jeśli zepsuje się laptop użytkownika, można połączyć się z innego urządzenia i kontynuować pracę.

Najważniejsze jest odejście od modelu, w którym cały biznes zależy od jednego komputera stojącego pod biurkiem. Jeśli na tym komputerze jest Subiekt, baza SQL, kopie zapasowe i codzienna praca użytkownika, ryzyko jest zbyt duże. Awaria sprzętu, przypadkowe usunięcie danych, zaszyfrowanie plików przez złośliwe oprogramowanie albo zwykły błąd systemu mogą zatrzymać firmę.

Bezpieczniejsze podejście obejmuje kilka elementów. Baza powinna działać na stabilnym serwerze lub w chmurze. Kopie zapasowe powinny być automatyczne i przechowywane poza głównym środowiskiem. Dostęp użytkowników powinien być kontrolowany. Należy też regularnie sprawdzać, czy backup można odtworzyć.

Warto również przygotować prostą procedurę awaryjną. Kto odpowiada za kontakt z obsługą techniczną? Gdzie są dane dostępowe? Gdzie znajdują się kopie? Jak szybko można uruchomić Subiekta na innym stanowisku? Takie pytania wydają się przesadne tylko do momentu pierwszej poważnej awarii.

Praca w chmurze nie zwalnia firmy z myślenia o bezpieczeństwie, ale zmniejsza zależność od lokalnego sprzętu. Program i baza działają na przygotowanym serwerze, a użytkownicy łączą się zdalnie. Jeżeli komputer pracownika przestanie działać, nie oznacza to automatycznie utraty bazy. Wystarczy inne urządzenie z dostępem do internetu i odpowiednimi uprawnieniami.

Dobrze przygotowana chmura obejmuje nie tylko samo uruchomienie programu, ale też administrację, kopie zapasowe, bezpieczeństwo dostępu, aktualizacje i wsparcie techniczne. Dla małej firmy to często bardziej przewidywalne rozwiązanie niż utrzymywanie lokalnego serwera bez stałej opieki.

Awaria komputera z Subiektem GT nie musi oznaczać katastrofy, jeśli dane są poprawnie zabezpieczone. Najgorsza sytuacja to brak kopii, brak wiedzy, gdzie znajduje się baza, i pochopna reinstalacja systemu. Najlepsza sytuacja to aktualny backup, oddzielony serwer lub chmura oraz jasna procedura odtworzenia pracy. W praktyce różnica między spokojnym przywróceniem programu a wielodniowym chaosem zależy od przygotowań wykonanych przed awarią.