Bezpieczna migracja danych VPS za pomocą rsync

Przed kopiowaniem sporządź spis

Wypisz pliki aplikacji, właścicieli, listy ACL, atrybuty rozszerzone, bazy danych, sekrety, zadania cykliczne, usługi, reguły zapory, DNS, certyfikaty i pamięć zewnętrzną. Potwierdź wystarczającą pojemność serwera docelowego oraz zgodność użytkowników, systemów plików, pakietów systemowych i wersji aplikacji. Obniż TTL DNS przed przełączeniem tylko wtedy, gdy pasuje to do planu DNS; wpisy w pamięci podręcznej mogą pozostać dłużej, niż oczekujesz.

Utwórz niezależną kopię zapasową źródła i zweryfikuj ją. Podczas początkowego transferu zachowaj źródło bez zmian i w pełni dostępne. Zanim ogłosisz okno serwisowe, określ kryteria powodzenia oraz warunki decyzji o powrocie.

• Nie kopiuj wirtualnych systemów plików, takich jak /proc, /sys, /dev lub /run, jak zwykłych danych.
• W razie potrzeby użyj natywnych narzędzi bazy danych do kopii, replikacji lub zrzutu.
• Nigdy nie umieszczaj kluczy prywatnych w historii poleceń ani wspólnych notatkach.

Skopiuj dane aplikacji etapowo, zaczynając od próby

Dla katalogu takiego jak /srv/app/ przetestuj operację ze źródła poleceniem sudo rsync -aHAX --numeric-ids --info=progress2 --dry-run -e "ssh -i /root/.ssh/migration_key" /srv/app/ admin@DESTINATION:/srv/app/. Zastąp użytkownika, ścieżkę klucza, cel i ścieżki danych. Końcowy ukośnik oznacza skopiowanie zawartości katalogu źródłowego zamiast utworzenia dodatkowego poziomu katalogu.

Przejrzyj każdą ścieżkę i każdy błąd. Upewnij się, że konto zdalne może bezpiecznie zapisywać w miejscu docelowym; logowanie roota nie jest potrzebne i często pozostaje wyłączone. Gdy wynik próby jest poprawny, powtórz polecenie bez --dry-run. Nie dodawaj --delete tylko po to, aby katalogi wyglądały identycznie — błędne źródło lub miejsce docelowe mogłoby doprowadzić do usunięcia cennych danych.

• Przy dużych transferach uruchom polecenie w trwałej sesji terminala.
• Ogranicz przepustowość, jeśli kopiowanie mogłoby wpływać na ruch produkcyjny.
• Zapisz opcje polecenia i wersje narzędzi w dokumentacji migracji.

Wycisz zapisy i wykonaj ostatni przebieg

Przełącz aplikację w udokumentowany tryb serwisowy lub tylko do odczytu. Zatrzymaj dokładnie te usługi, które zapisują dane, korzystając z ich obsługiwanej procedury, a następnie wykonaj końcową kopię bazy albo dokończ replikację. Ponownie uruchom to samo polecenie rsync, aby przesłać wyłącznie zmienione pliki. Zachowaj tryb serwisowy do zakończenia weryfikacji.

Uruchom usługi na serwerze docelowym z właściwą konfiguracją, początkowo ograniczając dostęp publiczny, jeśli to możliwe. Sprawdź stan usług, logowanie, zapis, kolejki, certyfikaty, dzienniki i zależności. Zmień DNS lub routing dopiero po pomyślnym przejściu testów. Nie zmieniaj w jednym oknie zarówno wersji aplikacji, jak i lokalizacji hostingu, chyba że połączone ryzyko zostało wyraźnie zaakceptowane.

• Zapisz czas ostatecznego zatrzymania zapisów i wynik synchronizacji.
• Zweryfikuj właścicieli plików i obowiązkowe mechanizmy kontroli dostępu.
• Podczas przejścia DNS obserwuj stary i nowy punkt końcowy.

Zweryfikuj, obserwuj i zachowaj możliwość powrotu

Aby dokładniej porównać pliki, w odpowiednim oknie uruchom pierwotne polecenie rsync z --checksum --dry-run; obliczanie sum kontrolnych odczytuje oba zbiory danych i może być kosztowne. W przypadku baz danych i magazynów obiektowych preferuj kontrole integralności na poziomie aplikacji. Po przełączeniu monitoruj błędy, opóźnienia, wykorzystanie zasobów, zadania w tle i zewnętrzne wywołania zwrotne.

Pozostaw źródło nienaruszone, ale do końca okna powrotu nie dopuszczaj do równoległych zapisów po obu stronach. Następnie zastosuj plan retencji i bezpiecznego usuwania. Migracja kończy się dopiero wtedy, gdy kopie zapasowe, monitoring, dokumentacja i procedury odzyskiwania odnoszą się do nowego miejsca.