Jak przenieść stronę lub aplikację na nowy serwer cloud
Aby bezpiecznie przejść na serwer cloud, nie ruszaj starej maszyny, dopóki nowa nie obsłuży prawdziwego ruchu. Ten poradnik to plan dla strony, sklepu lub aplikacji: trzy checklisty (przed, przełączenie, wycofanie), polecenia do dostosowania i uczciwe granice dotyczące przestoju. Najpierw dobierz zasoby według poradnika doboru serwera cloud, a region wybierz według poradnika lokalizacji w Europie.
Wybierz metodę migracji
Cztery metody pokrywają niemal każdą przeprowadzkę. Wiele projektów łączy dwie z nich.
| Metoda | Najlepsza dla | Główne ryzyko |
|---|---|---|
| rsync plików | Strony statyczne, uploady, kod aplikacji | Dane zmieniają się w trakcie kopiowania, potrzebna końcowa synchronizacja |
| Obraz lub przywrócenie z backupu | Ten sam system i układ, przetestowane przywracanie | Stare sterowniki i nazwy interfejsów, więcej danych do przesłania |
| Ponowne wdrożenie aplikacji | Kontenery i kod w git | Zapomniany ukryty stan na starym dysku |
| Replikacja bazy danych | Duże lub mocno obciążone bazy | Nakład pracy i ograniczenia wersji |
Zacznij od serwera cloud od EUR 15.00/mies., sprawdzono 2026-10 i przećwicz tam cały plan.
Checklista przed migracją
- Inwentaryzacja - wypisz usługi, porty, zadania cron, ustawienia poczty, certyfikaty, reguły zapory i każdą nazwę wskazującą na stary adres IP.
- Ukryty stan - znajdź pliki poza katalogiem głównym www: uploady, kolejki, sesje, licencje, sekrety w zmiennych środowiskowych.
- Backupy - zrób pełną kopię starego serwera i raz ją odtwórz gdzie indziej, bo nieprzetestowany backup to tylko nadzieja.
- Dostęp - tylko klucze SSH, zapora i użytkownik wdrożeniowy bez uprawnień root na nowym serwerze.
- Migawka - zrób migawkę nowego serwera przed pierwszą prawdziwą synchronizacją, by pomyłka kosztowała minuty.
Skopiuj pliki i dane
W przykładach nowy serwer ma adres dokumentacyjny 203.0.113.10. Podmień nazwy i ścieżki na swoje. Kroki 1 i 2 można bezpiecznie powtarzać, krok 5 uruchamiasz dopiero, gdy stara strona jest tylko do odczytu.
# 1. Bulk copy while the old server keeps serving (repeat any time)
rsync -aHAX --numeric-ids --info=progress2 \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
# 2. Database dump and restore (MySQL / MariaDB shown)
mysqldump --single-transaction --routines --triggers appdb \
| gzip | ssh deploy@203.0.113.10 'gunzip | mysql appdb'
# 3. Test the new server under the real hostname, DNS untouched
curl -sS --resolve example.com:443:203.0.113.10 \
https://example.com/ -o /dev/null -w '%{http_code}\n'
# 4. Check the TTL resolvers will honour
dig +noall +answer example.com A
# 5. Final sync after the old site is read-only
rsync -aHAX --numeric-ids --delete \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
Opcja --delete usuwa w celu pliki, których nie ma już w źródle. Używaj jej tylko w ostatnim przebiegu i tylko wtedy, gdy wiesz, która strona jest nadrzędna.
Najpierw test z plikiem hosts
Zanim zmieni się DNS, ustaw własny komputer tak, by otwierał stronę z nowego serwera. Dodaj wiersz do pliku hosts (/etc/hosts lub C:\Windows\System32\drivers\etc\hosts w Windows): 203.0.113.10 example.com www.example.com. Opcja --resolve w curl (krok 3) robi to samo dla pojedynczego żądania. Potem usuń wiersz, bo inaczej będziesz tygodniami testować nowy serwer, nie zauważając tego.
Obniż TTL w DNS i przełącz
Obniż TTL rekordów A i AAAA do około 300 sekund, co najmniej o jeden pełny okres starego TTL przed przeprowadzką. W przeciwnym razie resolvery trzymają stary adres tak długo, jak pozwala stary TTL. Część resolverów ignoruje krótki TTL, więc przez kilka godzin spodziewaj się ogona odwiedzających na starym IP (to szacunek, nie pomiar).
Checklista przełączenia:
- TTL - obniżona wartość obowiązuje, a stara już wygasła.
- Tylko odczyt - stara strona działa w trybie konserwacji lub tylko do odczytu.
- Końcowa synchronizacja - wykonano ostatni zrzut bazy i krok 5 z powyższego kodu.
- DNS - rekordy A i AAAA wskazują nowe IP; rekordy poczty bez zmian, chyba że poczta też się przenosi.
- Test dymny - logowanie, zamówienie, upload, e-mail, cron i certyfikat sprawdzone pod publiczną nazwą.
- Stary serwer - zostaw go włączonego, osiągalnego i nietkniętego.
Checklista wycofania
- Próg - z góry ustal, co uznajesz za porażkę, np. nieudane płatności lub odsetek błędów 5xx, i kto decyduje.
- DNS z powrotem - wskaż rekordy na stary IP; przy niskim TTL większość odwiedzających wraca w ciągu minut do godzin.
- Zapisy - otwórz starą stronę ponownie. Jeśli nowa przyjęła zamówienia lub uploady od przełączenia, najpierw je wyeksportuj i odtwórz na starej.
Czego naprawdę wymaga zero przestoju
Zero przestoju zależy od architektury aplikacji i nie jest obiecywane dla żadnego projektu. Wymaga aplikacji bez stanu, bazy, która replikuje lub przyjmuje zapisy po obu stronach, współdzielonego lub replikowanego magazynu i przetestowanego przełączenia. Klasyczna strona z jedną bazą ma zwykle krótkie okno tylko do odczytu, liczone w minutach.
Po przeprowadzce
Przez co najmniej tydzień obserwuj logi błędów, dysk, pamięć, czasy odpowiedzi i dostarczanie poczty. Gdy wszystko jest stabilne, podnieś TTL w DNS z powrotem. Wyłącz stary serwer dopiero po pełnym cyklu backupów na nowym; cotygodniowy backup jest wliczony w każdy preset. Przetestuj przed zakupem z pomocą checklisty okresu próbnego; krótki test może być możliwy po napisaniu na sales@dcxv.com, według uznania DCXV i bez gwarancji.
Skonfiguruj docelowy serwer cloud lub zapytaj inżyniera o migrację.
