Jak przenieść wszystkie konta cPanel z jednego serwera na drugi

Migracja wszystkich kont cPanel między serwerami to proces przenoszenia każdej hostowanej domeny, jej plików, baz danych MySQL, kont e-mail, stref DNS, certyfikatów SSL i zadań cron ze źródłowej instancji WHM do docelowej instancji WHM — zazwyczaj przy użyciu wbudowanego Narzędzia transferu WHM przez uwierzytelnione połączenie SSH. Prawidłowo wykonany proces nie wymaga ręcznego kopiowania plików i zachowuje nienaruszone wszystkie metadane kont.

Ten przewodnik obejmuje kompletny przepływ pracy migracji na poziomie produkcyjnym: kontrole wstępne, konfigurację Narzędzia transferu, strategię przełączenia DNS, walidację po migracji i czyszczenie — w tym przypadki brzegowe powodujące ciche błędy w rzeczywistych środowiskach.

Wymagania wstępne i lista kontrolna przed migracją

Pominięcie przygotowania jest najczęstszą przyczyną nieudanych lub niekompletnych migracji cPanel. Przed dotknięciem któregokolwiek serwera zweryfikuj każdy poniższy punkt.

Dostęp root na obu serwerach. Narzędzie transferu WHM uwierzytelnia się na serwerze źródłowym przez SSH jako root. Jeśli serwer źródłowy ma PermitRootLogin no w /etc/ssh/sshd_config, musisz tymczasowo włączyć tę opcję lub wcześniej skonfigurować uwierzytelnianie SSH oparte na kluczach dla roota.

Zgodne wersje cPanel/WHM. cPanel może przenosić konta ze starszych wersji do nowszych, ale nie odwrotnie. Serwer docelowy z cPanel 110 może pobierać dane ze źródła z cPanel 98, ale odwrotna sytuacja zakończy się niepowodzeniem. Sprawdź wersje w WHM w sekcji Informacje o serwerze lub uruchom:

cat /usr/local/cpanel/version

Zgodne lub kompatybilne wersje PHP i MySQL. Jeśli źródło działa na PHP 7.4 i MySQL 5.7, a cel na PHP 8.2 i MySQL 8.0, aplikacje mogą przestać działać po transferze, nawet jeśli pliki zostały skopiowane poprawnie. Przed kontynuowaniem sprawdź zainstalowane wersje PHP i domyślne procedury obsługi na obu serwerach.

Wystarczająca ilość miejsca na dysku na serwerze docelowym. Narzędzie transferu wymaga wolnego miejsca co najmniej równego łącznemu skompresowanemu rozmiarowi wszystkich przenoszonych kont, plus zapas na wypakowanie. Uruchom df -h na serwerze docelowym i porównaj z łącznym użyciem dysku przez konta widocznym w widoku Lista kont WHM na serwerze źródłowym.

Reguły zapory sieciowej zezwalające na SSH między serwerami. Serwer docelowy inicjuje wychodzące połączenie SSH do źródła. Upewnij się, że port 22 (lub niestandardowy port SSH) jest otwarty na zaporze sieciowej serwera źródłowego dla adresu IP serwera docelowego.

Pełne kopie zapasowe kont na serwerze źródłowym. Przed rozpoczęciem wygeneruj pełną kopię zapasową cPanel dla każdego konta. To jest punkt odzyskiwania w przypadku uszkodzenia lub częściowego skopiowania konta podczas transferu.

/scripts/pkgacct username /backup/directory

Jeśli uruchamiasz nowe środowisko na planie Hosting VPS, upewnij się, że Twój VPS ma już zainstalowaną i licencjonowaną wersję cPanel/WHM przed kontynuowaniem. Świeża instalacja cPanel wymaga ważnej licencji powiązanej z adresem IP serwera.

Krok 1: Instalacja i konfiguracja cPanel/WHM na serwerze docelowym

Jeśli cPanel nie jest jeszcze zainstalowany na serwerze docelowym, uruchom oficjalny instalator jako root. Proces ten zajmuje 20–45 minut w zależności od sprzętu:

cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest

Po zakończeniu instalacji uzyskaj dostęp do WHM pod adresem https://your-server-ip:2087 i ukończ kreator wstępnej konfiguracji. Zwróć szczególną uwagę na:

• Nazwa hosta: Ustaw w pełni kwalifikowaną nazwę domeny (FQDN), która rozwiązuje się do adresu IP serwera. Nierozwiązywalna nazwa hosta powoduje błędy dostarczania poczty po migracji.
• Serwery nazw: Skonfiguruj nazwy hostów serwerów nazw i ich adresy IP, jeśli planujesz hostować DNS na nowym serwerze.
• Procedury obsługi PHP: Zainstaluj te same wersje PHP dostępne na serwerze źródłowym, używając WHM > MultiPHP Manager, aby uniknąć problemów z kompatybilnością aplikacji.
• Wersja MySQL/MariaDB: Dopasuj wersję silnika bazy danych serwera źródłowego tam, gdzie to możliwe, lub przetestuj kompatybilność aplikacji z nowszą wersją przed migracją kont produkcyjnych.

Dla zespołów zarządzających wieloma środowiskami klientów, VPS z cPanel zapewnia wstępnie skonfigurowane środowisko, które całkowicie eliminuje fazę ręcznej instalacji.

Krok 2: Konfiguracja Narzędzia transferu WHM

Narzędzie transferu WHM jest autorytatywną metodą masowej migracji kont. Obsługuje pakowanie, transfer, wypakowanie i tworzenie kont atomowo dla każdego konta.

2.1 Dostęp do Narzędzia transferu

Na serwerze docelowym zaloguj się do WHM i przejdź do:

WHM > Transfery > Narzędzie transferu

To jest kluczowy punkt, który dezorientuje wielu administratorów: Narzędzie transferu jest zawsze uruchamiane z serwera docelowego, który pobiera konta ze źródła — nie odwrotnie.

2.2 Połączenie z serwerem źródłowym

Wprowadź następujące dane połączenia:

• Adres serwera zdalnego: Adres IP lub nazwa hosta serwera źródłowego
• Zdalny port SSH: Domyślnie 22; użyj rzeczywistego portu, jeśli został zmieniony (sprawdź /etc/ssh/sshd_config na serwerze źródłowym dla dyrektywy Port)
• Metoda uwierzytelniania: Hasło root lub klucz SSH (uwierzytelnianie oparte na kluczach jest zdecydowanie preferowane ze względów bezpieczeństwa i niezawodności)

Aby użyć uwierzytelniania kluczem SSH, skopiuj publiczny klucz root serwera docelowego do źródła:

ssh-copy-id -i /root/.ssh/id_rsa.pub -p 22 root@source-server-ip

Po połączeniu Narzędzie transferu odpytuje serwer źródłowy i zwraca listę wszystkich kont cPanel, pakietów i konfiguracji resellera.

2.3 Wybór kont i zakresu transferu

Możesz wybrać wszystkie konta lub ich podzbiór. Poza poszczególnymi kontami, Narzędzie transferu oferuje również:

• Pakiety: Przeniesienie definicji planów hostingowych, dzięki czemu konta zachowują swoje przydziały zasobów
• Strefy DNS: Kopiowanie wszystkich plików stref, co jest niezbędne, jeśli nowy serwer będzie działał jako autorytatywny serwer nazw
• Uprawnienia resellera i ACL: Zachowanie konfiguracji kont resellera i powiązanych z nimi uprawnień

2.4 Konfiguracja opcji transferu

Dwa ustawienia mają tu istotny wpływ operacyjny:

Transfer ekspresowy automatyzuje przełączenie DNS, aktualizując strefy DNS na serwerze źródłowym tak, aby wskazywały na IP serwera docelowego natychmiast po skopiowaniu każdego konta. Minimalizuje to okno czasowe, w którym domena rozwiązuje się do starego serwera. Używaj tej opcji tylko wtedy, gdy serwer docelowy jest gotowy do obsługi ruchu natychmiast i potwierdziłeś, że wszystkie aplikacje działają poprawnie.

Routing poczty: Ustaw na Automatyczny, chyba że masz konkretny powód, aby wymusić routing lokalny lub zdalny. Nieprawidłowy routing poczty jest jedną z głównych przyczyn błędów dostarczania poczty po migracji.

2.5 Inicjowanie transferu

Kliknij Kopiuj, aby rozpocząć proces. WHM wykona:

1. Połączenie SSH z serwerem źródłowym
2. Uruchomienie pkgacct w celu utworzenia skompresowanego archiwum każdego konta
3. Transfer archiwum do serwera docelowego przez SSH/SCP
4. Uruchomienie restorepkg na serwerze docelowym w celu wypakowania i utworzenia konta
5. Zapis wyniku dla każdego konta

Uważnie monitoruj dziennik transferu na żywo. Błędy dla poszczególnych kont nie zatrzymują całego procesu — konto może cicho zakończyć się niepowodzeniem, podczas gdy inne zakończą się sukcesem. Po zakończeniu transferu przejrzyj kompletny dziennik i ponownie uruchom nieudane konta indywidualnie.

Czas transferu zależy od łącznej ilości danych i przepustowości między serwerami. Serwer z 50 GB danych kont przez łącze 1 Gbps zazwyczaj kończy transfer w mniej niż 30 minut. Przez łącze 100 Mbps należy zaplanować 60–90 minut.

Krok 3: Strategia przełączenia DNS

Zarządzanie DNS jest miejscem, gdzie migracje najczęściej powodują przedłużone przestoje. Zrozumienie mechaniki propagacji jest niezbędne do minimalizacji wpływu na użytkowników.

3.1 Zmniejszenie TTL przed migracją

Najlepiej 24–48 godzin przed migracją zmniejsz TTL wszystkich rekordów A dla hostowanych domen do 300 sekund (5 minut). Zapewnia to, że po aktualizacji rekordów DNS zmiana propaguje się globalnie w ciągu minut, a nie godzin. Jeśli nie zrobiłeś tego wcześniej, musisz uwzględnić istniejącą wartość TTL jako maksymalne okno propagacji.

3.2 Aktualizacja stref DNS

Jeśli nowy serwer jest autorytatywnym serwerem nazw dla domen, zaktualizuj rekordy A w każdym pliku strefy przez WHM > Funkcje DNS > Edytuj strefę DNS, zmieniając IP ze starego adresu serwera na nowy.

Jeśli domeny używają zewnętrznego dostawcy DNS lub DNS rejestratora, zaloguj się do każdego rejestratora lub panelu zarządzania DNS i ręcznie zaktualizuj rekordy A. W przypadku masowych aktualizacji wielu domen większość rejestratorów oferuje dostęp przez API lub import CSV.

3.3 Aktualizacja rekordów glue serwerów nazw

Jeśli migrujesz również serwery nazw (np. ns1.yourdomain.com), musisz zaktualizować rekordy glue u rejestratora domeny — nie tylko plik strefy. Rekordy glue to mapowania adresów IP dla serwerów nazw zarejestrowanych pod tą samą domeną, której obsługują. Nieaktualizowanie rekordów glue jest częstym przeoczeniem, które powoduje całkowity błąd rozwiązywania DNS dla wszystkich hostowanych domen.

3.4 Weryfikacja propagacji

Użyj dig do sprawdzenia rozwiązywania z wielu lokalizacji geograficznych:

dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1

Porównaj z internetowym narzędziem do sprawdzania propagacji. Pełna globalna propagacja zazwyczaj kończy się w ciągu 1–4 godzin, gdy TTL zostało wcześniej zmniejszone, lub do 48 godzin, gdy TTL nie zostało wcześniej zmniejszone.

Jeśli Twoje domeny są zarejestrowane przez Rejestrację domen, aktualizacje serwerów nazw można zarządzać bezpośrednio z tego samego panelu sterowania, upraszczając proces przełączenia.

Krok 4: Walidacja po migracji

Nigdy nie ogłaszaj zakończenia migracji wyłącznie na podstawie dziennika sukcesu Narzędzia transferu. Niezależnie zweryfikuj każdą warstwę stosu.

4.1 Funkcjonalność aplikacji webowych

Uzyskaj dostęp do każdej przeniesionej domeny bezpośrednio przez IP, używając nadpisania pliku hosts (aby ominąć propagację DNS) i sprawdź, czy aplikacja ładuje się poprawnie:

# Add to /etc/hosts on your local machine temporarily
203.0.113.50  yourdomain.com www.yourdomain.com

Sprawdź błędy połączenia z bazą danych, brakujące ścieżki plików i uszkodzone konfiguracje aplikacji. Witryny WordPress często zawodzą, jeśli dane uwierzytelniające bazy danych wp-config.php odwołują się do localhost, ale ścieżka gniazda MySQL różni się między serwerami.

4.2 Integralność bazy danych

Zaloguj się do cPanel dla każdego konta i sprawdź, czy bazy danych istnieją i są dostępne. W przypadku krytycznych baz danych uruchom sprawdzenie integralności:

mysqlcheck -u root -p --all-databases --check

4.3 Funkcjonalność poczty e-mail

Przetestuj przychodzącą i wychodzącą pocztę e-mail dla każdego konta. Sprawdź, czy rekordy MX rozwiązują się poprawnie i czy serwer pocztowy akceptuje połączenia na portach 25, 465 i 587. Sprawdź /var/log/exim_mainlog pod kątem błędów dostarczania:

tail -f /var/log/exim_mainlog

Dla firm z dedykowaną infrastrukturą pocztową, Hosting poczty e-mail zapewnia izolowane środowiska pocztowe, na które nie mają wpływu migracje serwera webowego.

4.4 Weryfikacja certyfikatów SSL

Potwierdź, że certyfikaty SSL zostały poprawnie przeniesione i są aktywne. W WHM przejdź do SSL/TLS > Zarządzaj hostami SSL i sprawdź, czy każda domena ma ważny, nieprzeterminowany certyfikat. AutoSSL powinien automatycznie ponownie wystawić certyfikaty Let’s Encrypt dla tych, które nie zostały przeniesione, ale uruchom go ręcznie, aby uniknąć oczekiwania na zaplanowane uruchomienie:

/usr/local/cpanel/bin/autossl_check --all

Jeśli zarządzasz certyfikatami niezależnie, Certyfikaty SSL można zainstalować bezpośrednio na nowym serwerze bez zależności od procesu transferu.

4.5 Zadania cron i zaplanowane zadania

Zadania cron są przenoszone jako część pakietu konta, ale zweryfikuj je w cPanel > Zadania cron dla każdego konta. Zwróć szczególną uwagę na zadania cron odwołujące się do bezwzględnych ścieżek plików lub zmiennych środowiskowych specyficznych dla serwera, które mogą różnić się na nowym serwerze.

Krok 5: Czyszczenie i utwardzanie po migracji

5.1 Zawieszenie kont na serwerze źródłowym

Po propagacji DNS i zakończeniu walidacji zawieś wszystkie konta na serwerze źródłowym przez WHM > Lista kont > Zawieś. Nie usuwaj ich jeszcze. Zawieszenie zapobiega zapisywaniu nowych danych na serwerze źródłowym, zachowując go jako rezerwę w przypadku pojawienia się krytycznego problemu po migracji.

5.2 Kopia zapasowa po migracji

Utwórz świeżą pełną kopię zapasową wszystkich kont na nowym serwerze natychmiast po migracji. Przeniesiony stan jest Twoim nowym punktem bazowym:

/scripts/cpbackup --force

Sprawdź, czy kopie zapasowe zostały ukończone pomyślnie i są przechowywane w lokalizacji oddzielnej od samego serwera — najlepiej w zewnętrznym miejscu docelowym kopii zapasowych skonfigurowanym w WHM > Konfiguracja kopii zapasowych.

5.3 Monitorowanie wydajności

Monitoruj wykorzystanie zasobów nowego serwera przez 72 godziny po migracji. Kluczowe metryki do obserwowania:

• Średnie obciążenie CPU (powinno pozostawać poniżej liczby rdzeni CPU przy normalnym obciążeniu)
• Użycie pamięci i aktywność swap
• Czas oczekiwania na I/O dysku (podwyższony czas oczekiwania na I/O wskazuje na wąskie gardła pamięci masowej)
• Dziennik wolnych zapytań MySQL dla zapytań działających słabo na nowym schemacie lub wersji silnika

Używaj top, iostat i vmstat do monitorowania w czasie rzeczywistym oraz przeglądaj Monitor zasobów cPanel w WHM dla zużycia zasobów na poziomie konta.

5.4 Wycofanie serwera źródłowego

Po minimalnym 7-dniowym okresie obserwacji bez zgłoszonych problemów możesz wycofać serwer źródłowy. Przed zakończeniem działania starego serwera zarchiwizuj ostateczną kopię zapasową w zimnym magazynie. To archiwum służy jako zapis prawny i operacyjny i kosztuje bardzo mało, aby je przechowywać.

Migracja kont cPanel: Porównanie metod

Typowe pułapki i jak ich unikać

Ciche błędy transferu kont. Narzędzie transferu kontynuuje przetwarzanie nawet gdy poszczególne konta zawodzą. Zawsze czytaj kompletny dziennik transferu — nie zakładaj sukcesu tylko dlatego, że narzędzie zakończyło działanie bez zatrzymania.

Niezgodność uprawnień użytkowników MySQL. restorepkg odtwarza użytkowników bazy danych, ale jeśli nazwa użytkownika bazy danych przekracza 32-znakowy limit MySQL (częsty problem ze starszymi kontami), użytkownik jest tworzony z obciętą nazwą i dane uwierzytelniające bazy danych aplikacji przestają pasować. Przed migracją sprawdź długie nazwy użytkowników bazy danych.

Zależności modułów Perl i niestandardowego oprogramowania. Aplikacje opierające się na niestandardowo skompilowanych modułach Perl, pakietach Python lub bibliotekach systemowych zainstalowanych poza zarządzanymi ścieżkami cPanel nie zostaną przeniesione. Te zależności muszą być ręcznie ponownie zainstalowane na serwerze docelowym.

Rozbieżności limitów dyskowych. System limitów dyskowych cPanel używa limitów na poziomie systemu plików. Po migracji limity mogą nie odzwierciedlać dokładnie rzeczywistości, dopóki nie zostanie uruchomiony skrypt przeliczania limitów:

/scripts/fixquotas

Konflikty reguł ModSecurity. Jeśli serwer źródłowy miał niestandardowe reguły ModSecurity lub inną wersję zestawu reguł niż serwer docelowy, przeniesione witryny mogą otrzymywać nieoczekiwane błędy 403. Po migracji przejrzyj dzienniki ModSecurity pod adresem /usr/local/apache/logs/error_log.

Luki w uprawnieniach kont resellera. ACL resellera i przypisania pakietów są przenoszone, ale jeśli WHM serwera docelowego ma skonfigurowane inne listy funkcji, resellerzy mogą stwierdzić, że ich konta mają mniej lub inne możliwości niż oczekiwano. Po migracji sprawdź konfiguracje resellera.

W środowiskach o dużym ruchu, gdzie tolerancja przestojów jest bliska zeru, rozważ przeprowadzenie migracji na Serwerze dedykowanym z dedykowanymi zasobami, eliminując ryzyko rywalizacji o zasoby podczas faz transferu i walidacji.

Macierz decyzji technicznych

Użyj tej macierzy, aby określić podejście do migracji na podstawie charakterystyki środowiska:

FAQ

Czy mogę migrować konta cPanel bez dostępu root do serwera źródłowego?

Nie. Narzędzie transferu WHM wymaga dostępu SSH root do serwera źródłowego, aby uruchomić pkgacct i odczytać wszystkie dane konta. Jeśli dostęp root jest niedostępny, jedyną alternatywą jest zażądanie indywidualnych plików kopii zapasowych cPanel (archiwów .tar.gz) od administratora serwera źródłowego i ręczne przywrócenie ich za pomocą restorepkg na serwerze docelowym.

Jak długo trwa pełna migracja serwera cPanel?

Czas transferu zależy od łącznej ilości danych i przepustowości sieci między serwerami. Serwer ze 100 GB danych kont przez dedykowane łącze 1 Gbps zazwyczaj transferuje dane w 15–30 minut. Przez połączenia współdzielone lub z ograniczoną przepustowością te same dane mogą zająć kilka godzin. Propagacja DNS dodaje dodatkowe 1–48 godzin w zależności od wartości TTL.

Czy certyfikaty SSL zostaną przeniesione automatycznie?

Certyfikaty SSL zainstalowane przez AutoSSL (Let’s Encrypt) nie są przenoszone jako ważne certyfikaty — są ponownie wystawiane przez AutoSSL na serwerze docelowym, ponieważ są powiązane z adresem IP serwera i kontem. Certyfikaty zakupione komercyjnie przechowywane w cPanel są przenoszone jako część pakietu konta, ale muszą być zweryfikowane i ponownie aktywowane po migracji.

Co dzieje się z pocztą e-mail na starym serwerze podczas okna migracji?

Poczta e-mail dostarczona do starego serwera podczas okna migracji jest przechowywana w kolejce pocztowej i skrzynkach pocztowych użytkowników starego serwera. Nie replikuje się automatycznie na nowy serwer. Aby zapobiec utracie poczty, albo utrzymuj działające usługi pocztowe starego serwera do czasu pełnej propagacji DNS, albo skonfiguruj Exim starego serwera tak, aby przekazywał przychodzącą pocztę na adres IP nowego serwera podczas okresu przejściowego.

Czy Narzędzie transferu WHM może migrować konta między różnymi systemami operacyjnymi (np. CentOS na AlmaLinux)?

Tak. Narzędzie transferu jest niezależne od systemu operacyjnego na poziomie aplikacji — przenosi dane kont cPanel, a nie konfiguracje na poziomie systemu operacyjnego. Migracje z CentOS 7 na AlmaLinux 8 lub Rocky Linux 8 są w pełni obsługiwane i są najczęstszym scenariuszem migracji po zakończeniu wsparcia dla CentOS 7. Sprawdź, czy wszelkie niestandardowe konfiguracje na poziomie systemu (polityki SELinux, niestandardowe moduły jądra, usługi spoza cPanel) są ręcznie replikowane na serwerze docelowym.