Tüm cPanel Hesapları Bir Sunucudan Diğerine Nasıl Taşınır

Tüm cPanel hesaplarını sunucular arasında taşımak; barındırılan her alan adını, dosyalarını, MySQL veritabanlarını, e-posta hesaplarını, DNS bölgelerini, SSL sertifikalarını ve cron görevlerini, kaynak WHM örneğinden hedef WHM örneğine aktarma işlemidir; bu işlem genellikle kimlik doğrulamalı bir SSH bağlantısı üzerinden yerleşik WHM Transfer Aracı kullanılarak gerçekleştirilir. Doğru şekilde uygulandığında bu süreç, manuel dosya kopyalamayı sıfıra indirir ve tüm hesap meta verilerini eksiksiz korur.

Bu kılavuz, üretim düzeyinde eksiksiz taşıma iş akışını kapsamaktadır: ön kontroller, Transfer Aracı yapılandırması, DNS geçiş stratejisi, taşıma sonrası doğrulama ve temizlik — gerçek ortamlarda sessiz hatalara yol açan uç durumlar dahil.

Ön Koşullar ve Taşıma Öncesi Kontrol Listesi

Hazırlığı atlamak, başarısız veya eksik cPanel taşımalarının en yaygın tek nedenidir. Her iki sunucuya dokunmadan önce aşağıdaki her öğeyi doğrulayın.

Her iki sunucuda da root erişimi. WHM Transfer Aracı, kaynak sunucuya SSH üzerinden root olarak kimlik doğrulaması yapar. Kaynak sunucuda /etc/ssh/sshd_config içinde PermitRootLogin no varsa, bunu geçici olarak etkinleştirmeniz ya da root için SSH anahtar tabanlı kimlik doğrulamasını önceden yapılandırmanız gerekir.

Uyumlu cPanel/WHM sürümleri. cPanel, hesapları eski sürümlerden yeni sürümlere aktarabilir; ancak bunun tersi mümkün değildir. cPanel 110 çalıştıran bir hedef, cPanel 98 çalıştıran bir kaynaktan çekme yapabilir; ancak bunun tersi başarısız olur. Sürümleri WHM’de Sunucu Bilgileri altında kontrol edin veya şunu çalıştırın:

cat /usr/local/cpanel/version

Eşleşen veya uyumlu PHP ve MySQL sürümleri. Kaynak sunucu PHP 7.4 ve MySQL 5.7 çalıştırırken hedef sunucu PHP 8.2 ve MySQL 8.0 çalıştırıyorsa, dosyalar temiz kopyalansa bile uygulamalar aktarım sonrasında bozulabilir. Devam etmeden önce her iki sunucuda da yüklü PHP sürümlerini ve varsayılan işleyicileri denetleyin.

Hedef sunucuda yeterli disk alanı. Transfer Aracı, aktarılan tüm hesapların toplam sıkıştırılmış boyutuna en az eşit, ayrıca açma işlemi için ek boş alan gerektirir. Hedef sunucuda df -h komutunu çalıştırın ve bunu kaynaktaki WHM’nin Hesapları Listele görünümünde görünen toplam hesap disk kullanımıyla karşılaştırın.

Sunucular arasında SSH’ye izin veren güvenlik duvarı kuralları. Hedef sunucu, kaynağa giden bir SSH bağlantısı başlatır. Kaynak sunucunun güvenlik duvarında 22 numaralı portun (veya özel SSH portunun) hedef sunucunun IP adresi için açık olduğundan emin olun.

Kaynaktaki tüm hesapların tam yedekleri. Başlamadan önce her hesap için tam bir cPanel yedeği oluşturun. Bu, aktarımın bir hesabı bozması veya kısmen kopyalaması durumunda kurtarma noktanızdır.

/scripts/pkgacct username /backup/directory

Yeni ortamınızı bir VPS Hosting planında çalıştırıyorsanız, devam etmeden önce VPS’inizde cPanel/WHM’nin lisanslı ve kurulu olduğunu doğrulayın. Yeni bir cPanel kurulumu, sunucunun IP adresine bağlı geçerli bir lisans gerektirir.

Adım 1: Hedef Sunucuya cPanel/WHM Kurulumu ve Yapılandırması

cPanel henüz hedef sunucuya kurulmamışsa, resmi yükleyiciyi root olarak çalıştırın. Bu işlem, donanıma bağlı olarak 20–45 dakika sürer:

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

Kurulum tamamlandıktan sonra https://your-server-ip:2087 adresinden WHM’ye erişin ve ilk kurulum sihirbazını tamamlayın. Özellikle şunlara dikkat edin:

• Ana Bilgisayar Adı: Sunucunun IP’sine çözümlenen tam nitelikli bir alan adı (FQDN) ayarlayın. Çözümlenemeyen bir ana bilgisayar adı, taşıma sonrasında posta teslim hatalarına neden olur.
• Ad Sunucuları: Yeni sunucuda DNS barındırmayı planlıyorsanız ad sunucusu ana bilgisayar adlarını ve IP adreslerini yapılandırın.
• PHP işleyicileri: Uygulama uyumluluk sorunlarını önlemek için WHM > MultiPHP Manager kullanarak kaynak sunucuda mevcut olan PHP sürümlerini yükleyin.
• MySQL/MariaDB sürümü: Mümkün olduğunda kaynak sunucunun veritabanı motoru sürümüyle eşleştirin ya da üretim hesaplarını taşımadan önce uygulamanın yeni sürümle uyumluluğunu test edin.

Birden fazla istemci ortamını yöneten ekipler için, cPanel’li VPS, manuel kurulum aşamasını tamamen ortadan kaldıran önceden yapılandırılmış bir ortam sağlar.

Adım 2: WHM Transfer Aracını Yapılandırma

WHM Transfer Aracı, toplu hesap taşıma için yetkili yöntemdir. Her hesap için paketleme, aktarım, açma ve hesap oluşturma işlemlerini atomik olarak gerçekleştirir.

2.1 Transfer Aracına Erişim

Hedef sunucuda WHM’ye giriş yapın ve şuraya gidin:

WHM > Transfers > Transfer Tool

Bu, birçok yöneticiyi şaşırtan kritik bir noktadır: Transfer Aracı her zaman hesapları kaynaktan çeken hedef sunucudan çalıştırılır — bunun tersi değil.

2.2 Kaynak Sunucuya Bağlanma

Aşağıdaki bağlantı bilgilerini girin:

• Uzak Sunucu Adresi: Kaynak sunucunun IP adresi veya ana bilgisayar adı
• Uzak SSH Portu: Varsayılan 22‘dir; değiştirildiyse gerçek portu kullanın (kaynak sunucuda Port yönergesi için /etc/ssh/sshd_config‘i kontrol edin)
• Kimlik doğrulama yöntemi: Root parolası veya SSH anahtarı (güvenlik ve güvenilirlik açısından anahtar tabanlı kimlik doğrulaması kesinlikle tercih edilir)

SSH anahtar kimlik doğrulamasını kullanmak için hedef sunucunun root ortak anahtarını kaynağa kopyalayın:

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

Bağlandıktan sonra Transfer Aracı, kaynak sunucuyu sorgular ve tüm cPanel hesaplarının, paketlerin ve bayi yapılandırmalarının bir listesini döndürür.

2.3 Hesapları ve Aktarım Kapsamını Seçme

Tüm hesapları veya bir alt kümeyi seçebilirsiniz. Bireysel hesapların ötesinde Transfer Aracı şunları da sunar:

• Paketler: Hesapların kaynak tahsislerini koruması için barındırma planı tanımlarını aktarın
• DNS Bölgeleri: Yeni sunucu yetkili ad sunucusu olarak görev yapacaksa tüm bölge dosyalarını kopyalayın
• Bayi Ayrıcalıkları ve ACL’ler: Bayi hesabı yapılandırmalarını ve ilgili izinleri koruyun

2.4 Aktarım Seçeneklerini Yapılandırma

Buradaki iki ayarın önemli operasyonel etkisi vardır:

Express Transfer, her hesap kopyalandıktan hemen sonra kaynak sunucudaki DNS bölgelerini hedefin IP’sine işaret edecek şekilde güncelleyerek DNS geçişini otomatikleştirir. Bu, bir alan adının eski sunucuya çözümlendiği pencereyi en aza indirir. Bunu yalnızca hedef sunucu trafiği hemen sunmaya hazırsa ve tüm uygulamaların işlevsel olduğunu doğruladıysanız kullanın.

Posta Yönlendirme: Yerel veya uzak yönlendirmeyi zorlamak için özel bir nedeniniz olmadıkça bunu Otomatik olarak ayarlayın. Yanlış posta yönlendirmesi, taşıma sonrası e-posta teslim hatalarının en başlıca nedenlerinden biridir.

2.5 Aktarımı Başlatma

İşlemi başlatmak için Kopyala‘ya tıklayın. WHM şunları yapacaktır:

1. Kaynak sunucuya SSH ile bağlanır
2. Her hesabın sıkıştırılmış arşivini oluşturmak için pkgacct çalıştırır
3. Arşivi SSH/SCP üzerinden hedefe aktarır
4. Hesabı açmak ve oluşturmak için hedefte restorepkg çalıştırır
5. Her hesap için sonucu kaydeder

Canlı aktarım günlüğünü dikkatlice izleyin. Bireysel hesaplardaki hatalar genel işlemi durdurmaz — bir hesap sessizce başarısız olurken diğerleri başarılı olabilir. Aktarım tamamlandıktan sonra tam günlüğü inceleyin ve başarısız hesapları tek tek yeniden çalıştırın.

Aktarım süresi, toplam veri hacmine ve sunucular arası bant genişliğine bağlıdır. 1 Gbps bağlantı üzerinden 50 GB hesap verisi içeren bir sunucu genellikle 30 dakikadan kısa sürede tamamlanır. 100 Mbps bağlantı üzerinden 60–90 dakika hesaplayın.

Adım 3: DNS Geçiş Stratejisi

DNS yönetimi, taşımaların en sık uzun süreli kesintiye neden olduğu alandır. Kullanıcı etkisini en aza indirmek için yayılma mekaniklerini anlamak şarttır.

3.1 Taşımadan Önce TTL’yi Azaltma

İdeal olarak, taşımadan 24–48 saat önce barındırılan alan adlarının tüm A kayıtlarındaki TTL’yi 300 saniyeye (5 dakika) indirin. Bu, DNS kayıtlarını güncellediğinizde değişikliğin saatler yerine dakikalar içinde küresel olarak yayılmasını sağlar. Bunu önceden yapmadıysanız, mevcut TTL değerini maksimum yayılma pencereniz olarak hesaba katmanız gerekir.

3.2 DNS Bölgelerini Güncelleme

Yeni sunucu alan adları için yetkili ad sunucusuysa, WHM > DNS Functions > Edit DNS Zone üzerinden her bölge dosyasındaki A kayıtlarını güncelleyin; IP’yi eski sunucunun adresinden yenisine değiştirin.

Alan adları harici bir DNS sağlayıcısı veya kayıt şirketi DNS’i kullanıyorsa, her kayıt şirketine veya DNS yönetim paneline giriş yapın ve A kayıtlarını manuel olarak güncelleyin. Birçok alan adında toplu güncellemeler için çoğu kayıt şirketi API erişimi veya CSV içe aktarma sunar.

3.3 Ad Sunucusu Glue Kayıtlarını Güncelleme

Ad sunucularını da taşıyorsanız (örn. ns1.yourdomain.com), yalnızca bölge dosyasını değil, alan adı kayıt şirketindeki glue kayıtlarını da güncellemeniz gerekir. Glue kayıtları, hizmet verdikleri alan adının altında kayıtlı ad sunucuları için IP adresi eşlemeleridir. Glue kayıtlarını güncellemek, barındırılan tüm alan adlarında tam DNS çözümleme hatasına neden olan yaygın bir gözetimdir.

3.4 Yayılmayı Doğrulama

Birden fazla coğrafi konumdan çözümlemeyi kontrol etmek için dig kullanın:

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

Web tabanlı bir yayılma denetleyicisiyle çapraz referans yapın. TTL önceden azaltıldığında tam küresel yayılma genellikle 1–4 saat içinde tamamlanır; TTL önceden azaltılmadığında ise 48 saate kadar sürebilir.

Alan adlarınız Alan Adı Kaydı aracılığıyla kayıtlıysa, ad sunucusu güncellemeleri doğrudan aynı kontrol panelinden yönetilebilir; bu da geçiş sürecini basitleştirir.

Adım 4: Taşıma Sonrası Doğrulama

Bir taşımayı yalnızca Transfer Aracının başarı günlüğüne dayanarak tamamlanmış ilan etmeyin. Yığının her katmanını bağımsız olarak doğrulayın.

4.1 Web Uygulaması İşlevselliği

DNS yayılmasını atlamak için hosts dosyası geçersiz kılma kullanarak her aktarılan alan adına doğrudan IP üzerinden erişin ve uygulamanın doğru yüklendiğini doğrulayın:

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

Veritabanı bağlantı hatalarını, eksik dosya yollarını ve bozuk uygulama yapılandırmalarını kontrol edin. wp-config.php veritabanı kimlik bilgileri localhost‘e başvuruyorsa ancak MySQL soket yolu sunucular arasında farklıysa WordPress siteleri genellikle başarısız olur.

4.2 Veritabanı Bütünlüğü

Her hesap için cPanel’e giriş yapın ve veritabanlarının mevcut ve erişilebilir olduğunu doğrulayın. Kritik veritabanları için bir bütünlük kontrolü çalıştırın:

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

4.3 E-posta İşlevselliği

Her hesap için gelen ve giden e-postayı test edin. MX kayıtlarının doğru çözümlendiğini ve posta sunucusunun 25, 465 ve 587 numaralı portlarda bağlantıları kabul ettiğini doğrulayın. Teslim hataları için /var/log/exim_mainlog‘i kontrol edin:

tail -f /var/log/exim_mainlog

Özel posta altyapısına sahip işletmeler için E-posta Hosting, web sunucusu taşımalarından etkilenmeyen izole posta ortamları sağlar.

4.4 SSL Sertifikası Doğrulaması

SSL sertifikalarının doğru aktarıldığını ve etkin olduğunu onaylayın. WHM’de SSL/TLS > Manage SSL Hosts bölümüne gidin ve her alan adının geçerli, süresi dolmamış bir sertifikaya sahip olduğunu doğrulayın. AutoSSL, aktarılamayan Let’s Encrypt sertifikalarını hedef sunucuda otomatik olarak yeniden yayımlamalıdır; ancak zamanlanmış çalışmayı beklemekten kaçınmak için manuel olarak tetikleyin:

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

Sertifikaları bağımsız olarak yönetiyorsanız, SSL Sertifikaları aktarım sürecine bağımlı olmadan doğrudan yeni sunucuya kurulabilir.

4.5 Cron Görevleri ve Zamanlanmış Görevler

Cron görevleri hesap paketi kapsamında aktarılır; ancak her hesap için cPanel > Cron Jobs bölümünde doğrulayın. Mutlak dosya yollarına veya yeni sunucuda farklı olabilecek sunucuya özgü ortam değişkenlerine başvuran cron görevlerine özellikle dikkat edin.

Adım 5: Temizlik ve Taşıma Sonrası Sertleştirme

5.1 Kaynak Sunucudaki Hesapları Askıya Alma

DNS yayıldıktan ve doğrulama tamamlandıktan sonra, WHM > List Accounts > Suspend üzerinden kaynak sunucudaki tüm hesapları askıya alın. Henüz silmeyin. Askıya alma, taşıma sonrasında kritik bir sorun ortaya çıkması durumunda geri dönüş noktası olarak kullanılabilir tutarken kaynağa yeni veri yazılmasını engeller.

5.2 Taşıma Sonrası Yedekleme

Taşımanın hemen ardından yeni sunucudaki tüm hesapların tam yedeğini oluşturun. Aktarılan durum yeni temel çizginizdir:

/scripts/cpbackup --force

Yedeklemelerin başarıyla tamamlandığını ve sunucunun kendisinden ayrı bir konumda depolandığını doğrulayın — ideal olarak WHM > Backup Configuration bölümünde yapılandırılmış sunucu dışı bir yedekleme hedefi.

5.3 Performans İzleme

Taşıma sonrası 72 saat boyunca yeni sunucunun kaynak kullanımını izleyin. İzlenecek temel metrikler:

• CPU yük ortalaması (normal yük altında CPU çekirdek sayısının altında kalmalıdır)
• Bellek kullanımı ve takas etkinliği
• Disk G/Ç bekleme süresi (yüksek G/Ç bekleme süresi depolama darboğazlarına işaret eder)
• Yeni şema veya motor sürümünde kötü performans gösteren sorgular için MySQL yavaş sorgu günlüğü

Gerçek zamanlı izleme için top, iostat ve vmstat kullanın; hesap başına kaynak tüketimi için WHM’deki cPanel Resource Monitor‘ı inceleyin.

5.4 Kaynak Sunucuyu Hizmetten Çıkarma

Bildirilen sorun olmaksızın en az 7 günlük gözlem süresinin ardından kaynak sunucuyu hizmetten çıkarabilirsiniz. Eski sunucuyu sonlandırmadan önce soğuk depolamaya son bir yedek arşivleyin. Bu arşiv yasal ve operasyonel bir kayıt olarak hizmet eder ve saklamak çok az maliyete neden olur.

cPanel Hesap Taşıma: Yöntem Karşılaştırması

Yaygın Tuzaklar ve Bunlardan Kaçınma Yolları

Sessiz hesap aktarım hataları. Transfer Aracı, bireysel hesaplar başarısız olsa bile işlemeye devam eder. Her zaman tam aktarım günlüğünü okuyun — araç durmadan tamamlandı diye başarı varsaymayın.

MySQL kullanıcı ayrıcalığı uyuşmazlığı. restorepkg veritabanı kullanıcılarını yeniden oluşturur; ancak bir veritabanı kullanıcı adı MySQL’in 32 karakterlik sınırını aşıyorsa (eski hesaplarda yaygın bir sorun), kullanıcı kesilmiş bir adla oluşturulur ve uygulamanın veritabanı kimlik bilgileri artık eşleşmez. Taşımadan önce uzun veritabanı kullanıcı adlarını denetleyin.

Perl modülü ve özel yazılım bağımlılıkları. Özel derlenmiş Perl modüllerine, Python paketlerine veya cPanel’in yönetilen yolları dışında yüklenen sistem kütüphanelerine dayanan uygulamalar aktarılmaz. Bu bağımlılıkların hedef sunucuya manuel olarak yeniden yüklenmesi gerekir.

Disk kotası tutarsızlıkları. cPanel’in disk kotası sistemi dosya sistemi düzeyinde kotalar kullanır. Taşıma sonrasında, kota yeniden hesaplama betiği çalışana kadar kotalar doğru yansımayabilir:

/scripts/fixquotas

ModSecurity kural çakışmaları. Kaynak sunucunun özel ModSecurity kuralları veya hedeften farklı bir kural seti sürümü varsa, aktarılan siteler beklenmedik 403 hataları alabilir. Taşıma sonrasında /usr/local/apache/logs/error_log adresindeki ModSecurity günlüklerini inceleyin.

Bayi hesabı izin eksiklikleri. Bayi ACL’leri ve paket atamaları aktarılır; ancak hedef WHM farklı özellik listeleri yapılandırmışsa, bayiler hesaplarının beklenenden daha az veya farklı yeteneklere sahip olduğunu görebilir. Taşıma sonrasında bayi yapılandırmalarını denetleyin.

Kesinti toleransının neredeyse sıfır olduğu yüksek trafikli ortamlar için, aktarım ve doğrulama aşamalarında kaynak çekişmesi riskini ortadan kaldıran özel kaynaklara sahip bir Dedicated Server üzerinde taşıma yapmayı düşünün.

Teknik Karar Matrisi

Ortam özelliklerine göre taşıma yaklaşımınızı belirlemek için bu matrisi kullanın:

SSS

Kaynak sunucuya root erişimi olmadan cPanel hesaplarını taşıyabilir miyim?

Hayır. WHM Transfer Aracı, pkgacct çalıştırmak ve tüm hesap verilerini okumak için kaynak sunucuya root SSH erişimi gerektirir. Root erişimi mevcut değilse tek alternatif, kaynak sunucunun yöneticisinden bireysel cPanel yedek dosyaları (.tar.gz arşivleri) talep etmek ve bunları hedefte restorepkg kullanarak manuel olarak geri yüklemektir.

Tam bir cPanel sunucu taşıması ne kadar sürer?

Aktarım süresi, toplam veri hacmine ve sunucular arasındaki ağ bant genişliğine bağlıdır. 1 Gbps özel bağlantı üzerinden 100 GB hesap verisi içeren bir sunucu genellikle 15–30 dakikada aktarılır. Paylaşımlı veya kısıtlanmış bağlantılarda aynı veri birkaç saat sürebilir. DNS yayılması, TTL değerlerine bağlı olarak ek 1–48 saat ekler.

SSL sertifikaları otomatik olarak aktarılır mı?

AutoSSL (Let’s Encrypt) aracılığıyla yüklenen SSL sertifikaları geçerli sertifikalar olarak aktarılmaz — sunucunun IP’sine ve hesabına bağlı oldukları için hedef sunucuda AutoSSL tarafından yeniden yayımlanırlar. cPanel’de depolanan ticari olarak satın alınan sertifikalar hesap paketi kapsamında aktarılır; ancak taşıma sonrasında doğrulanmaları ve yeniden etkinleştirilmeleri gerekir.

Taşıma penceresi sırasında eski sunucudaki e-postalara ne olur?

Taşıma penceresi sırasında eski sunucuya teslim edilen e-postalar, eski sunucunun posta kuyruğunda ve kullanıcı posta kutularında depolanır. Yeni sunucuya otomatik olarak çoğaltılmaz. Posta kaybını önlemek için ya DNS tamamen yayılana kadar eski sunucunun posta hizmetlerini çalışır durumda tutun ya da geçiş dönemi boyunca eski sunucunun Exim’ini gelen postaları yeni sunucunun IP’sine iletecek şekilde yapılandırın.

WHM Transfer Aracı, farklı işletim sistemleri arasında hesap taşıyabilir mi (örn. CentOS’tan AlmaLinux’a)?

Evet. Transfer Aracı, uygulama katmanında işletim sisteminden bağımsızdır — işletim sistemi düzeyindeki yapılandırmaları değil, cPanel hesap verilerini aktarır. CentOS 7’den AlmaLinux 8’e veya Rocky Linux 8’e taşımalar tam olarak desteklenmekte olup CentOS 7’nin kullanım ömrünün sona ermesinin ardından en yaygın taşıma senaryosudur. Özel sistem düzeyindeki yapılandırmaların (SELinux politikaları, özel çekirdek modülleri, cPanel dışı hizmetler) hedef sunucuya manuel olarak çoğaltıldığını doğrulayın.