Lista kontrolna migracji VPS: kopie zapasowe, DNS, TLS i wycofanie
Praktyczna kolejność migracji dla aplikacji hostowanej samodzielnie: inwentaryzacja, spójne kopie zapasowe, przetestowany cel, kontrolowane zapisy, przełączenie DNS i ścieżka przywracania.
W skrócie
Kontrolowana migracja VPS inwentaryzuje usługi i dane, tworzy spójną kopię zapasową, weryfikuje przywrócony cel, testuje nazwę hosta i routing TLS, koordynuje końcowe zapisy i DNS oraz zachowuje wycofanie uwzględniające dane. Żadna lista kontrolna sama nie gwarantuje zerowego przestoju.
Zinwentaryzuj aplikację przed jej przeniesieniem
Wymień usługi, wersje, porty, zadania zaplanowane, bazy danych, przesłane pliki i konfigurację potrzebną do działania aplikacji. Zidentyfikuj, gdzie odbywają się zapisy i od jakich usług zewnętrznych zależy aplikacja. Skopiowany katalog internetowy nie jest pełną migracją, gdy dane znajdują się gdzie indziej.
Zapisz bieżące nazwy DNS, aktywne rekordy IPv4 i IPv6, metody odnawiania certyfikatów i ścieżkę dostępu do odzyskiwania. Sekrety trzymaj w prywatnych narzędziach wdrożeniowych. Nie umieszczaj haseł, kluczy prywatnych ani zrzutów bazy danych w publicznym katalogu głównym dokumentów ani we wspólnej liście kontrolnej migracji.
Utwórz spójną kopię zapasową i udowodnij, że się przywraca
Użyj mechanizmu kopii zapasowej obsługiwanego przez bazę danych, zamiast kopiować dowolne pliki, gdy zapisy trwają. Dla SQLite funkcja Online Backup API tworzy spójny zrzut bazy danych. W trybie WAL plik WAL uczestniczy w trwałym stanie bazy danych, więc kopiowanie tylko głównego pliku bazy danych może pominąć zatwierdzone zmiany.
Spójna kopia zapasowa bazy danych nie jest automatycznie spójna z osobno przechowywanymi plikami przesłanymi, kolejkami lub plikami. Skoreluj ich przechwycenie ze swoją aplikacją. Przywróć do osobnej lokalizacji testowej i zweryfikuj rekordy, odwołania do plików i zachowanie aplikacji, zanim uznasz kopię zapasową za użyteczną.
Przygotuj cel przed zmianą DNS
Utwórz zamierzonych użytkowników, uprawnienia, wersje środowiska uruchomieniowego, usługi i katalogi aplikacji na nowym serwerze. Przywróć kopię zapasową testową do docelowej lokalizacji danych, w stosownych przypadkach poza publicznym katalogiem internetowym. Sprawdź własność i dostęp przy użyciu konta usługi, które faktycznie uruchomi aplikację.
Zachowaj niepowiązane witryny na serwerze współdzielonym. Użyj dedykowanego katalogu głównego dokumentów, hosta wirtualnego i środowiska uruchomieniowego, zweryfikuj konfigurację serwera WWW i przygotuj wycofanie przywracające wyłącznie pliki i konfigurację należące do tej zmiany.
Przetestuj rzeczywistą nazwę hosta i certyfikat na nowym serwerze
Żądanie przeglądarki do samego adresu IP nie odtwarza routingu opartego na nazwie hosta ani walidacji certyfikatu. curl --resolve pozwala testowi użyć zamierzonej nazwy hosta i wybranego docelowego adresu IP, zachowując normalne sprawdzanie nazwy hosta i TLS. Sprawdź także status HTTP i oczekiwaną treść aplikacji. Przykład używa wartości wyłącznie dokumentacyjnych; zastąp je własną zweryfikowaną domeną i celem.
Aby ten test się powiódł, ważny certyfikat i dozwolona ścieżka sieciowa muszą już istnieć. Nigdy nie wyłączaj weryfikacji certyfikatu, aby uznać migrację za gotową. Walidacja ACME oparta na DNS może zweryfikować domenę bez zmiany adresu serwera WWW; walidacja oparta na HTTP ma inne wymagania dotyczące osiągalności. Przetestuj odnawianie osobno od początkowego wystawienia.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Wybierz plan kontroli zapisów i końcowej synchronizacji
Zaplanuj krótki okres konserwacji lub inny odpowiedni dla aplikacji mechanizm spójności. Zatrzymaj lub przekieruj zidentyfikowanych piszących, wykonaj końcową spójną kopię zapasową bazy danych, zsynchronizuj odpowiednie zmienne pliki i zweryfikuj wynik. Procesy robocze kolejek, webhooki i zadania cron mogą zapisywać, nawet gdy publiczny interfejs wygląda na spokojny.
Przed synchronizacją plików wykonaj próbę na sucho. Nie dodawaj flag usuwania ani nie kopiuj całych katalogów systemowych jako skrótu. Utrzymuj starą usługę w stanie odzyskiwalnym, dopóki nie sprawdzisz nowej aplikacji i nie ustalisz, która lokalizacja jest autorytatywna dla zapisów.
Zmień DNS, potem obserwuj obie rodziny adresów
Zaktualizuj rekordy wymagane dla usługi i uwzględnij istniejące pamięci podręczne resolverów. Sprawdź odpowiedzi autorytatywne i kilka normalnych ścieżek klienckich. Jeśli przestarzały rekord AAAA pozostanie aktywny, klienci IPv6 mogą nadal trafiać do starego serwera, podczas gdy klienci IPv4 trafiają do nowego.
Przetestuj logowanie, odczyty, zapisy, przesyłanie plików, zadania w tle i wywołania zwrotne zewnętrznych usług w nowej usłudze. Unikaj uruchamiania dwóch niezależnych kopii tej samej aplikacji z możliwością zapisu podczas przejścia. Ustal jasną regułę postępowania z ruchem, który nadal trafia do starego celu.
Uczyń wycofanie decyzją o danych, a nie tylko decyzją o DNS
Zdefiniuj warunki awarii wyzwalające wycofanie i to, kto kontroluje przełączenie. Cofnięcie samego DNS nie wystarczy, gdy nowe zapisy dotarły do celu: musisz zachować lub uzgodnić te dane przed powrotem do starszej kopii.
Zachowaj źródło i kopie zapasowe przez odpowiedni okres odzyskiwania. Usuń stary dostęp i wycofaj zasoby dopiero po sprawdzeniu celu, kopii zapasowych, odnowienia i monitorowania. Przechowywanie i usuwanie powinny wynikać z rzeczywistej polityki usługi, a nie z ogólnej stałej liczby godzin.