Jak przenieść VPS do nowego dostawcy bez przestoju

Każda straszna historia o przeprowadzce ma ten sam środek: ktoś najpierw zmienił DNS, a potem zaczął kopiować. Przestój podczas przeprowadzki prawie nigdy nie wynika z wolnego kopiowania. Wynika z wykonania kroków w złej kolejności.

Oto kolejność, która działa, niezależnie od tego, czy odchodzisz od innego dostawcy, czy przenosisz się między dwiema naszymi taryfami.

1. Dwa dni wcześniej: obniż TTL

Znajdź rekordy DNS, które będziesz zmieniać (zwykle A, AAAA i wszystkie CNAME, które na nie wskazują), i obniż ich TTL do 300 sekund. Potem odczekaj co najmniej tyle, ile wynosił stary TTL. Rekord z TTL równym dobie oznacza, że część resolwerów będzie podawać stary adres jeszcze przez dobę po zmianie, i nic, co zrobisz na serwerze, tego nie przyspieszy.

To krok, który ludzie pomijają najczęściej, i to on zamienia pięciominutowe przełączenie w dzień, w którym połowa użytkowników widzi stary serwer.

2. Zrób inwentaryzację starego serwera

Będziesz odbudowywać tę maszynę gdzie indziej, więc zapisz, co ona naprawdę robi. Nie to, co pamiętasz. To, co robi:

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

Dopisz do listy: certyfikaty TLS i sposób ich odnawiania, pliki środowiskowe z sekretami, reguły firewalla, użytkowników i ich klucze SSH, bazę danych i jej rozmiar oraz wszystko, co łączy się z serwerem po adresie IP. Ta ostatnia grupa jest najbardziej podstępna: allowlista partnera, ustawienia webhooków u operatora płatności, sprawdzenie z monitoringu.

3. Postaw nowy serwer obok starego

Zamów nowy serwer, a starego nie ruszaj. Wybierz taryfę z listy VPS z takim samym lub większym dyskiem, niż faktycznie używasz, a nie niż ci sprzedano. Jeśli do starej maszyny trafia jakikolwiek ruch przychodzący (strona, webhooki, API), nowa potrzebuje własnego IPv4. Taryfa NAT przyjmuje połączenia przychodzące tylko na swoim porcie SSH, a dlaczego to ważne, wyjaśnia artykuł Co może, a czego nie może jeden przekierowany port.

Połącz się, zainstaluj te same pakiety, odtwórz użytkowników i firewall. Klucze i pierwsze logowanie opisuje przewodnik po połączeniu.

4. Zsynchronizuj pliki dwa razy

Pierwsza synchronizacja kopiuje wszystko, gdy stary serwer dalej pracuje. Może trwać godzinami; to normalne.

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids zachowuje właścicieli plików według numerów, co chroni przed klasyczną niespodzianką „wszystko należy do niewłaściwego użytkownika”, gdy oba systemy tworzyły użytkowników w innej kolejności. Jeśli nigdy nie używałeś rsync przez SSH, artykuł Jak przesłać pliki na VPS przeprowadzi cię krok po kroku.

Druga synchronizacja, tuż przed przełączeniem, kopiuje tylko to, co zmieniło się od pierwszej. Zwykle trwa sekundy.

5. Przenieś bazę danych świadomie

Pliki są proste. Baza, która przyjmuje zapisy, to jedyne miejsce, w którym „bez przestoju” wymaga albo drobnego kompromisu, albo dodatkowej pracy.

Prosta droga: raz zrobić zrzut i odtworzyć go do testów, a w momencie przełączenia zatrzymać zapisy na minutę (przełączyć aplikację w tryb tylko do odczytu albo ją zatrzymać), zrobić świeży zrzut, odtworzyć go na nowym serwerze i tam uruchomić aplikację. W większości małych projektów to przerwa na minutę czy dwie, zapowiedziana wcześniej.

Droga bez przerwy: skonfigurować replikację ze starej bazy do nowej, pozwolić jej nadgonić, a w chwili przełączenia awansować nową na główną. Więcej konfiguracji, i warto, gdy nawet minuta utraconych zapisów jest nie do przyjęcia.

6. Przetestuj nowy serwer, zanim ktoś inny go zobaczy

DNS nadal wskazuje stary serwer, więc nowy możesz przetestować bez świadków. Wyślij żądanie do swojej prawdziwej domeny pod nowy adres:

curl --resolve example.com:443:203.0.113.10 https://example.com/health

Jeśli certyfikatu jeszcze nie ma, przetestuj tak samo po HTTP albo dodaj tymczasową linię w pliku hosts i przeklikaj stronę w przeglądarce. Sprawdź logowanie, przesyłanie plików, zadania w tle i pocztę wychodzącą. To najtańszy moment, żeby odkryć brakujące rozszerzenie PHP.

7. Przełącz i nie wyłączaj starego serwera

Zrób ostatnią synchronizację plików i krok z bazą, a potem zmień rekordy DNS. Przy TTL równym 300 sekund większość ruchu przeniesie się w kilka minut. Obserwuj log dostępu starego serwera: wciąż będzie tam spływać strużka żądań od resolwerów i klientów, którzy ignorują TTL. Zostaw go włączonego i niezmienionego na kilka dni. Potem zaktualizuj wszystko, co wskazuje stary IP: allowlisty partnerów, adresy webhooków, a dla poczty odwrotny DNS nowego adresu (w naszych taryfach z dedykowanym IP ustawiasz go sam, zob. odwrotny DNS) i rekord SPF.

Co psuje się najczęściej

Mniej więcej w kolejności, w jakiej to widujemy: timer systemd, którego nikt nie wpisał na listę, plik konfiguracyjny z wpisanym na sztywno starym IP, pliki należące do niewłaściwego użytkownika, firewall blokujący własny port aplikacji, certyfikat odnawiany na starym serwerze, ale nie na nowym, i poczta lądująca w spamie, bo nowy adres nie ma jeszcze odwrotnego DNS.

Gdzie ta checklista się nie sprawdzi

Mocno obciążona baza z ciągłymi zapisami i zerową tolerancją na przerwę potrzebuje porządnej replikacji i próby generalnej, a nie checklisty z bloga. Serwery Windows przenosi się innymi narzędziami niż rsync. A jeśli przeprowadzka tak naprawdę dotyczy rozmiaru, przeczytaj najpierw to: tutaj taryfy rosną na miejscu. Przejście na większą taryfę tego samego typu sieci dodaje vCPU, RAM i dysk jednym restartem, bez żadnej przeprowadzki. Nowy serwer jest potrzebny tylko do zmniejszenia. Jeśli przenosisz się, bo nie masz pewności, czy maszyna wystarcza, artykuł Kiedy naprawdę potrzebujesz 64 GB RAM może oszczędzić ci tej podróży, a VPS, hosting współdzielony, serwer dedykowany czy chmura pomoże, jeśli wątpisz, czy VPS to w ogóle właściwy dom.