Przy dużym serwisie informacyjnym skopiowanie plików i bazy to tylko część migracji. Nowe środowisko musi odtworzyć również konfigurację serwera, certyfikaty, zadania cykliczne i zachowanie domen wykorzystywanych przez integracje. W tym projekcie przygotowaliśmy środowisko zapasowe dla rozbudowanego serwisu instytucji publicznej oraz mechanizm jego nocnej aktualizacji. Prace były częścią przygotowania disaster recovery (DR), czyli odtwarzania działania serwisu po poważnej awarii.
Cel disaster recovery: działająca kopia serwisu i powtarzalne odtwarzanie
Zadanie polegało na przeniesieniu serwisu do środowiska failover, które można zweryfikować przed ewentualnym przełączeniem ruchu. Produkcja pozostawała źródłem danych. Serwer zapasowy miał odtwarzać jej stan poprzez zaplanowaną synchronizację.
W opisywanym etapie uruchomiliśmy i przetestowaliśmy kopię w sieci dostępnej przez VPN. Nie było to jeszcze przełączenie publicznego ruchu na nową infrastrukturę. To rozróżnienie ma znaczenie: działający serwer zapasowy jest podstawą planu awaryjnego, a gotowość do przełączenia wymaga także sprawdzenia wszystkich zależności.
Skala projektu
Baza zawierała 85 tabel i około 3,42 GB danych oraz indeksów po imporcie. Zrzut SQL miał około 2,18 GiB przed kompresją. W trakcie kopiowania liczba pozycji w drzewie plików przekroczyła 200 tysięcy. Dużą część transferu stanowiła biblioteka materiałów publikowanych w serwisie.
Pierwsza pełna synchronizacja, obejmująca również katalog przesłanych materiałów, trwała około 6 godzin i 7 minut. Kolejne zweryfikowane przebiegi przyrostowe zajęły 6 minut i 58 sekund oraz 6 minut i 38 sekund. To pomiary z tego wdrożenia, zależne od wielkości zmian i warunków transferu.
Najpierw kod aplikacji, potem duża biblioteka materiałów
Pełne kopiowanie plików trwało na tyle długo, że opóźniało test aplikacji. Wprowadziliśmy więc osobny tryb synchronizacji pomijający bibliotekę przesłanych materiałów. Pozwolił szybciej domknąć kod aplikacji i sprawdzić uruchomienie serwisu. Pełny tryb nadal obejmował materiały i został wykorzystany w nocnym przebiegu.
Podczas transferu niekompletna aplikacja zwracała błędy. Analiza wykazała, że część wymaganych plików WordPressa jeszcze nie dotarła. Po zakończeniu szybkiego przebiegu test HTTPS na właściwej ścieżce sieciowej zwrócił poprawną odpowiedź. Dzięki sprawdzeniu przyczyny nie wprowadzaliśmy zmian w kodzie na podstawie błędu wynikającego z trwającego kopiowania.
Konfiguracja ma znaczenie tak samo jak dane
Przenosiliśmy konfigurację nginx, HTTPS i zadania aplikacyjne. Nowe środowisko korzystało z PHP 8.4, więc dostosowania wymagało wskazanie procesu obsługującego PHP. Poprawiliśmy też przestarzałą składnię konfiguracji HTTP/2. Zmiany sprawdzaliśmy testami konfiguracji i odpowiedzi serwisu.
Osobnej uwagi wymagała domena używana przez integrację płatności. Dodaliśmy ją jawnie do konfiguracji, zweryfikowaliśmy certyfikat i zachowanie żądań względem produkcji. Takie porównanie jest przydatne, ale nie zastępuje pełnego testu rzeczywistego callbacku płatności.
Dalszy audyt wskazał dodatkowe pliki reguł dostępu i konfiguracji adresów źródłowych oraz techniczny vhost, które wymagały uwzględnienia. Kompletność aliasów DNS należało sprawdzić także u dostawcy DNS. To pokazuje, dlaczego w projekcie migracyjnym warto mieć osobną listę zależności do zweryfikowania przed przełączeniem.
Nocna synchronizacja i kontrola wyniku
Pełna synchronizacja została zaplanowana codziennie na 02:30 czasu warszawskiego. Obejmuje pliki aplikacji, bibliotekę materiałów, bazę i SSL. Stare logi serwera wyłączyliśmy z kopiowania. Zweryfikowane kolejne przebiegi zakończyły się sukcesem, a kontrola potwierdziła import bazy, 85 tabel oraz zgodność certyfikatu i klucza.
Sprawdziliśmy również dostęp z Windowsa przez VPN, przekierowanie HTTP do HTTPS i działanie wymaganych usług. Kopia serwisu odpowiadała poprawnie na tej ścieżce. Osobna gałąź konfiguracji używana przez lokalne żądania pozostawała przedmiotem dalszej weryfikacji.
Nocna kopia odzwierciedla stan z ostatniego udanego przebiegu. Treści dodane później trafiają na serwer zapasowy przy kolejnej synchronizacji. Ten model trzeba uwzględnić w planie awaryjnym i dobrać częstotliwość do potrzeb instytucji.
Rezultat i dalszy etap
Rezultatem opisanego etapu była działająca kopia dużego serwisu na osobnym środowisku oraz sprawdzony mechanizm jej cyklicznej aktualizacji. Pierwszy wielogodzinny transfer ustąpił miejsca krótkim przebiegom przyrostowym. Powstały też skrypty odtworzeniowe i udokumentowane kontrole.
Przed uznaniem całego środowiska za gotowe do przełączenia pozostaje domknięcie konfiguracji i zależności wskazanych w audycie, weryfikacja DNS oraz rzeczywistych integracji. Case study pokazuje więc przygotowanie środowiska failover w ramach disaster recovery, bez deklaracji zakończonej migracji produkcji lub automatycznego przełączania.
Planujesz migrację lub disaster recovery?
Porozmawiaj z Projectic o przeniesieniu dużej strony, przygotowaniu serwera zapasowego lub uporządkowaniu procesu disaster recovery. Pomożemy określić zakres, rozpoznać zależności i zaplanować testy odtwarzania przed przełączeniem ruchu.