Migracja witryny cPanel na VPS bez przestoju
Opublikowano 10 września 2026
Aby przenieść witrynę cPanel na VPS bez niespodziewanego przestoju, potraktuj DNS jako końcowe przełączenie, a nie pierwsze zadanie. Przygotuj serwer docelowy, skopiuj konto, przetestuj je pod nowym adresem IP, zmniejsz DNS TTL, a następnie zmień rekordy dopiero po pomyślnym zakończeniu kontroli aplikacji, poczty i SSL. Witryna pozostaje dostępna, podczas gdy prace odbywają się w tle.
W przypadku witryny małej firmy, konta agencji lub sklepu z aktywnymi zamówieniami migracja polega mniej na przenoszeniu plików, a bardziej na zachowaniu działania usługi. Wersje PHP, uprawnienia do baz danych, zadania cron, routing poczty e-mail, przekierowania i reguły zapory muszą zostać przeniesione w sprawdzonym, poprawnym stanie. Pliki są zazwyczaj łatwą częścią. To drobne ustawienia ukryte wokół nich sprawiają, że migracje przyprawiają o siwe włosy.
Przed migracją witryny cPanel na VPS
Zacznij od inwentaryzacji istniejącego konta. Zanotuj nazwy domen i subdomen, użycie miejsca na dysku przez konto, wersję PHP i rozszerzenia, rozmiary baz danych, zadania cron, konta e-mail, przekierowania poczty, autorespondery, rekordy DNS, certyfikaty SSL oraz wszelkie usługi zewnętrzne zależne od adresu IP serwera. W przypadku obciążeń e-commerce i SaaS zidentyfikuj także callbacki płatności, listy dozwolonych adresów API, dostawców transakcyjnej poczty e-mail oraz procesy działające w tle.
Sprawdź, czy docelowy VPS ma wystarczający zapas zasobów. Przestrzeń dyskowa powinna wystarczyć na konto źródłowe, tymczasowe archiwum migracyjne, bazy danych, kopie zapasowe i normalny przyrost danych. Wymagania dotyczące RAM i CPU zależą od ruchu i stosu oprogramowania. Prosta witryna informacyjna może działać komfortowo na skromnym VPS; WooCommerce, Magento, duży WordPress multisite lub intensywnie używana aplikacja zwykle wymagają więcej pamięci i większej wydajności bazy danych.
Miejsce docelowe powinno być przygotowane przed skopiowaniem jakichkolwiek danych produkcyjnych. Ustaw hostname serwera, zainstaluj i zaktualizuj cPanel oraz WHM, jeśli to wybrany panel sterowania, skonfiguruj nameserwery, jeśli VPS będzie hostował DNS, i włącz zaporę z otwartymi tylko niezbędnymi portami. Potwierdź, że kopie zapasowe są skonfigurowane niezależnie od serwera źródłowego. Kopia zapasowa przechowywana wyłącznie na VPS jest przydatna, ale nie stanowi pełnego planu odzyskiwania, jeśli sam VPS będzie miał problem.
Jeśli przenosisz się z hostingu współdzielonego cPanel na VPS, sprawdź, czym wcześniej zarządzano za Ciebie. Stary hostingodawca mógł obsługiwać filtrowanie poczty, DNS, automatyczne odnawianie SSL, skanowanie malware lub kopie zapasowe poza serwerem. Na zarządzanym VPS te elementy mogą być sprawdzane i utrzymywane razem z Tobą. Na serwerze niezarządzanym stają się one Twoją odpowiedzialnością operacyjną. Żadne z tych podejść nie jest błędne, ale założenia bywają kosztowne.
Obniż DNS TTL przed przełączeniem
Około 24 do 48 godzin przed planowaną zmianą obniż TTL odpowiednich rekordów DNS do 300 sekund, jeśli to praktyczne. Dzięki temu zaktualizowane rekordy A, AAAA i MX rozprzestrzenią się szybciej, gdy nadejdzie czas przełączenia. Nie obniżaj go pięć minut przed przenosinami i nie oczekuj, że internet podejdzie do tego filozoficznie. Rekurencyjne resolvery mogą już mieć starą wartość w pamięci podręcznej.
Zachowaj zapis bieżącej strefy DNS przed jej edycją. Jeśli po przełączeniu pojawi się coś nieoczekiwanego, przywrócenie znanych rekordów jest szybsze niż odtwarzanie ich z pamięci.
Wybierz właściwą metodę transferu
Transfer Tool w WHM jest zwykle najczystszą metodą przenoszenia pełnych kont cPanel między zgodnymi serwerami. Przenosi dane konta, bazy danych, pocztę e-mail, informacje o strefie DNS oraz wiele ustawień na poziomie konta w jednym kontrolowanym procesie. W miarę możliwości używaj dostępu root lub na poziomie resellera i sprawdź, czy serwer źródłowy pozwala na wymagane połączenie SSH.
Pełna kopia zapasowa cPanel również może dobrze działać, gdy bezpośredni transfer z serwera na serwer jest niedostępny. Wygeneruj kopię zapasową, bezpiecznie przenieś ją na nowy VPS i odtwórz ją przez WHM. To podejście jest bardziej ręczne, a kopia zapasowa może odzwierciedlać określony moment w czasie, a nie najnowsze zmiany, dlatego ostrożnie zaplanuj końcową synchronizację.
W przypadku aplikacji o nietypowej konfiguracji ręczna migracja może być bezpieczniejsza. Skopiuj pliki witryny za pomocą rsync lub innej bezpiecznej metody transferu, wyeksportuj i zaimportuj bazy danych, odtwórz użytkowników i uprawnienia, a następnie odbuduj konfigurację poza kontem. To trwa dłużej, ale daje większą kontrolę, gdy system źródłowy ma niestandardowe reguły Nginx, niestandardowe ścieżki, pamięć zewnętrzną lub procesy aplikacji.
Unikaj kopiowania wyłącznie katalogu public_html, chyba że potwierdzono, że nie ma niczego więcej do zachowania. Poczta e-mail, bazy danych, ukryte pliki, definicje cron, materiały SSL i pliki konfiguracyjne często znajdują się poza tym folderem.
Przetestuj VPS przed publicznymi zmianami DNS
Po odtworzeniu konta zweryfikuj witrynę względem docelowego adresu IP bez zmiany publicznego DNS. Lokalny wpis w pliku hosts pozwala Twojemu komputerowi rozwiązywać domenę na nowy VPS, podczas gdy wszyscy inni nadal trafiają na stary serwer. To właściwy moment, aby znaleźć brakujące rozszerzenie PHP, uszkodzoną regułę rewrite lub użytkownika bazy danych, który nie został przeniesiony.
Przetestuj główne strony, proces logowania, formularze kontaktowe, checkout, obszar administracyjny, przesyłanie obrazów i zadania zaplanowane. Przejrzyj logi aplikacji i log błędów serwera WWW, robiąc to. Sprawdź, czy witryna używa zamierzonej wersji PHP i czy własność plików jest poprawna. Strona, która załaduje się raz, to nie cały test. Powinna także zapisywać do bazy danych, wysyłać wymagane wiadomości i normalnie obsługiwać uwierzytelnione sesje.
Zweryfikuj również SSL przed przełączeniem. Jeśli certyfikat ma zostać wydany ponownie po skierowaniu DNS na VPS, potwierdź, że virtual host serwera WWW jest poprawny oraz że porty 80 i 443 są osiągalne. Jeśli przenosisz istniejący certyfikat, bezpiecznie zainstaluj jego łańcuch certyfikatów i klucz. Przeglądarki są dość szczere w kwestii błędów certyfikatów, czasem z większym dramatyzmem, niż to konieczne.
Obsługuj pocztę e-mail oddzielnie od ruchu WWW
Poczta e-mail jest najczęściej pomijaną częścią migracji na VPS. Jeśli domena korzysta z zewnętrznej poczty e-mail, takiej jak Google Workspace lub Microsoft 365, zachowaj istniejące rekordy MX, SPF, DKIM i DMARC. Nie zastąp ich przez przypadek lokalnymi rekordami pocztowymi cPanel.
Jeśli poczta e-mail jest hostowana w cPanel, przenieś skrzynki pocztowe i przetestuj wysyłanie oraz odbieranie na VPS. Podczas przejścia DNS nowe wiadomości mogą trafiać na którykolwiek z serwerów. Pozostaw stare konto hostingowe aktywne przez co najmniej 48 do 72 godzin po przełączeniu i wykonaj końcową synchronizację poczty oraz plików, jeśli źródło pozostaje aktywne. W przypadku poczty o dużym wolumenie lub skrzynek krytycznych dla firmy zaplanuj bardziej przemyślane przełączenie poczty, zamiast traktować je jako sprawę drugorzędną.
Przełącz ostrożnie i pozostaw stary serwer dostępny
Gdy testy przebiegają pomyślnie, wprowadź dynamiczne części witryny na krótko w tryb konserwacji, jeśli aplikacja na to pozwala. Wykonaj końcowy eksport bazy danych lub synchronizację konta, aby przechwycić zamówienia, przesłania formularzy, zmiany użytkowników i aktualizacje treści wprowadzone od czasu początkowego transferu. Odtwórz lub zsynchronizuj te końcowe dane na VPS, a następnie wyłącz tryb konserwacji po przygotowaniu nowego środowiska.
Zaktualizuj rekord A do nowego adresu IPv4, a rekord AAAA tylko wtedy, gdy IPv6 jest skonfigurowane i przetestowane. Jeśli zmieniają się również nameserwery, wprowadź tę zmianę świadomie i potwierdź, że nowa strefa zawiera każdy wymagany rekord. Zmiana nameserwerów i jednoczesna przebudowa DNS zwiększają liczbę ruchomych elementów. Czasami jest to konieczne, ale nie jest to najpiękniejsza sytuacja DNS.
Obserwuj nowy serwer przez pierwsze godziny. Sprawdzaj logi dostępu WWW, błędy PHP i aplikacji, obciążenie CPU, presję na pamięć, użycie dysku, stan kolejki pocztowej i aktywność bazy danych. Potwierdź, że automatyczne kopie zapasowe uruchamiają się pomyślnie oraz że monitoring może dotrzeć do nowego VPS. W kodu.cloud to właśnie tutaj przydają się zarządzane operacje i monitoring FASTCARE: usługa znów działa spokojnie, ponieważ ktoś obserwuje rzeczywiste zachowanie serwera, a nie tylko stronę główną.
Nie anuluj starej usługi natychmiast. Pozostaw ją online, aż propagacja DNS się ustabilizuje, przepływ poczty zostanie potwierdzony, kopie zapasowe zostaną zweryfikowane, a kluczowi użytkownicy przetestują działającą witrynę. Dla większości standardowych witryn 72 godziny to rozsądne okno bezpieczeństwa. W tym okresie utrzymuj plan wycofania zmian: zachowaj stare wartości DNS, unikaj destrukcyjnych zmian w źródle i wiedz, kto podejmie decyzję, jeśli powrót okaże się konieczny.
Kontrole po migracji, które zapobiegają późniejszym problemom
Po przeniesieniu przejrzyj harmonogram kopii zapasowych, okresy retencji, testy odtwarzania, aktualizacje zabezpieczeń, działanie zapory oraz trendy wykorzystania zasobów. Usuń stare wpisy testowe z lokalnego pliku hosts. Zaktualizuj wszelkie zewnętrzne listy dozwolonych adresów, cele monitoringu, endpointy webhooków i dokumentację odwołujące się do starego adresu IP.
VPS daje też szansę na uporządkowanie długo narastającego bałaganu hostingowego. Usuń nieaktywne konta e-mail, stare kopie stagingowe, porzucone bazy danych oraz wtyczki lub rozszerzenia, które nie są już potrzebne. Zrób to po ustabilizowaniu migracji, a nie podczas krytycznego okna transferowego. Spokojne zmiany łatwiej cofnąć.
Dobra migracja zostawia po sobie więcej niż tylko witrynę, która akurat się ładuje. Pozostawia serwer, który możesz monitorować, odtwarzać, aktualizować i któremu możesz zaufać, gdy ruch pojawi się o niewygodnej godzinie. Uwzględnij ten margines operacyjny w migracji, a następne zadanie konserwacyjne będzie znacznie mniej przypominać akcję ratunkową.
Andres Saar Inżynier ds. obsługi klienta