Przywracanie na innym serwerze

Przywracanie na innym serwerze wymaga sprawdzenia zgodności wersji i dostępności odpowiednich loginów.

Na czym polega przywracanie na innym serwerze

Przywracanie na innym serwerze oznacza odtworzenie danych, konfiguracji lub całej usługi z kopii zapasowej w środowisku różniącym się od pierwotnego. Taki proces może służyć migracji, odtworzeniu działania po awarii albo przygotowaniu środowiska testowego. Sama obecność pliku kopii nie gwarantuje poprawnego uruchomienia systemu. Serwer docelowy musi mieć odpowiedni system operacyjny, wymagane składniki programowe, dostęp do przestrzeni dyskowej oraz ustawienia sieciowe zgodne z odtwarzaną usługą.

Przed rozpoczęciem należy ustalić, co dokładnie zawiera kopia: pliki użytkownika, bazę danych, konfigurację aplikacji, certyfikaty, zadania automatyczne czy dane uwierzytelniające. Istotny jest także sposób wykonania kopii. Kopia plikowa, obraz dysku i eksport danych aplikacji mają różne wymagania dotyczące odtwarzania. Należy sprawdzić datę utworzenia kopii, jej kompletność oraz możliwość odczytu. Jeżeli kopia jest uszkodzona albo nie obejmuje wymaganych składników, przywrócenie na drugim serwerze może zakończyć się uruchomieniem usługi bez części danych lub konfiguracji.

Zgodność wersji i wymagania środowiska

Jednym z pierwszych zadań jest porównanie wersji oprogramowania na serwerze źródłowym i docelowym. Dotyczy to systemu operacyjnego, silnika bazy danych, środowiska uruchomieniowego, sterowników oraz samej aplikacji. W niektórych rozwiązaniach kopię można odtworzyć tylko w tej samej wersji albo w wersji nowszej, która formalnie obsługuje dany format. Nie należy zakładać, że starsze oprogramowanie odczyta kopię utworzoną przez nowszy silnik. Przy różnicy wersji trzeba sprawdzić dokumentację konkretnego produktu i ewentualnie wykonać pośrednią konwersję lub eksport logiczny.

Weryfikacji wymagają również architektura procesora, typ systemu plików, dostępna ilość pamięci i wolnego miejsca oraz układ katalogów. Jeżeli w konfiguracji zapisano bezwzględne ścieżki, nazwy hostów, adresy IP albo identyfikatory urządzeń, po przeniesieniu mogą wskazywać nieistniejące zasoby. Należy przejrzeć pliki konfiguracyjne i zmienić wyłącznie te wartości, które odnoszą się do nowego środowiska. Trzeba też sprawdzić strefę czasową, synchronizację zegara i ustawienia DNS, ponieważ różnice czasu mogą powodować błędy certyfikatów, wygasanie sesji oraz nieprawidłową kolejność zadań.

Loginy, uprawnienia i zależności sieciowe

Odtwarzana usługa często korzysta z kont systemowych, kont aplikacyjnych, grup, udziałów sieciowych, certyfikatów lub kluczy szyfrujących. Konta istniejące na serwerze źródłowym nie muszą istnieć na serwerze docelowym, a identyczna nazwa użytkownika nie zawsze oznacza ten sam identyfikator zabezpieczeń. Dlatego trzeba utworzyć wymagane konta zgodnie z dokumentacją aplikacji, nadać im minimalne uprawnienia konieczne do pracy i sprawdzić właścicieli oraz prawa dostępu do odtworzonych katalogów. Szczególnej uwagi wymagają pliki, do których usługa musi mieć jednocześnie prawo odczytu, zapisu i wykonywania.

Przed uruchomieniem należy potwierdzić dostęp do wszystkich zależności: serwerów DNS, usług katalogowych, udziałów plikowych, repozytoriów aktualizacji, systemów licencjonowania oraz endpointów używanych przez aplikację. Reguły zapory sieciowej na nowym serwerze mogą blokować porty, które wcześniej były dostępne. Warto wykonać kontrolowane próby połączeń i przejrzeć logi aplikacji oraz systemu. Jeżeli kopia została zaszyfrowana, potrzebny jest właściwy klucz, certyfikat lub hasło. Bez nich pliki mogą być fizycznie obecne, ale ich zawartość pozostanie niedostępna. Dane uwierzytelniające należy przekazywać bez wpisywania ich do publicznych raportów lub zwykłych plików tekstowych.

Kontrola wyniku i bezpieczne przełączenie

Po odtworzeniu należy przeprowadzić test techniczny obejmujący uruchomienie usługi, odczyt istniejących danych, zapis nowego rekordu lub pliku, działanie zaplanowanych zadań oraz komunikację z wymaganymi zależnościami. Wynik trzeba porównać z kopią źródłową, korzystając z liczby plików, rozmiarów, sum kontrolnych albo raportów integralności dostępnych w danym narzędziu. Sam fakt, że proces przywracania zakończył się komunikatem „sukces”, nie potwierdza poprawności całej aplikacji. Należy sprawdzić także logi po uruchomieniu, ponieważ część błędów pojawia się dopiero podczas obsługi rzeczywistego żądania.

Przełączenie użytkowników na nowy serwer powinno mieć określony moment rozpoczęcia i procedurę powrotu. Przed zmianą trzeba zatrzymać zapisy na serwerze źródłowym albo ustalić, jak zostaną uwzględnione zmiany wykonane po utworzeniu kopii. Następnie aktualizuje się właściwy wpis DNS, adres połączenia lub konfigurację klienta, zależnie od sposobu udostępniania usługi. Stary serwer warto pozostawić nienaruszony do czasu zakończenia testów i potwierdzenia kompletności danych. Po migracji należy wykonać nową kopię zapasową już z serwera docelowego oraz zapisać wersje komponentów, użyte konta techniczne, zmienione ścieżki i wyniki testów. Taka dokumentacja ułatwia kolejne odtworzenie i pozwala szybko ustalić, które elementy wymagają korekty.