Plesk’ten cPanel’e (ve Tersi) Kesintisiz Geçiş: DNS, E‑posta ve SSL için Adım Adım Taşıma Planı

Nereden Başlamalı? Neden Taşıyoruz ve Neyi Kırmadan Geçiririz?

Hiç gece 03:17’de DNS kesintisi yüzünden telefonunuzun titreşimiyle yataktan fırladınız mı? Ben fırladım. Bir müşterinin Plesk’ten cPanel’e geçişinde “TTL’leri düşürdük, kayıtları kopyaladık, artık basarız NS değişimini” diye düşünürken, bir alt alanın eski sunucuda kalan bir wildcard kaydı bize ters köşe yapmıştı. O gece şunu bir kez daha gördüm: kesintisiz geçiş sadece veri kopyalamak değil, akıştaki kırılma noktalarını önceden görüp, küçük prova kesitleriyle doğrulamaktır. Bu yazıda tam da bunu yapacağız; Plesk’ten cPanel’e (ve tersi) geçişi DNS, e‑posta ve SSL/ACME ekseninde, gerçek operasyon notları ve ölçülebilir kontrollerle adım adım anlatacağım.

Plan şu: Önce riski çerçeveliyoruz, sonra DNS tarafında gölgeli yayın ve TTL yönetimiyle zemini yumuşatıyoruz. E‑posta hesaplarını ve itibar öğelerini (SPF, DKIM, DMARC ve gerektiğinde MTA‑STS) düzgünce taşıyıp, web içeriğini artımlı senkronlarla kesintisiz kapıya bırakıyoruz. SSL sertifikalarını önceden üretip HSTS ve CAA ile sürprizleri azaltıyor, gözlemlenebilirlik metrikleriyle geçiş anını izliyoruz. Araya gerçek bir gece operasyonunun post‑mortem notlarını serpiştirip, kapanışta da uygulanabilir bir runbook özetliyorum. Mesela şöyle düşünün: Büyük resmi sadeleştirip küçük ve geri alınabilir adımlara bölünce, geçiş gecesi sessiz olur.

Riskleri Haritalamak: Kırılma Noktularını Önceden Görmek

Kayıtlı Varsayımlar ve Doğrulamalar

Taşımanın başında ekipçe şu soruları cevaplarız: Alan adlarının yetkili DNS’i nerede? E‑posta akışı hangi MTA üzerinde ve kim imzalıyor? SSL nasıl yenileniyor, ACME mi panel uzantıları mı? Bu basit görünen sorular, kesinti noktalarını işaretler. Bir projede, DKIM özel anahtarlarını eski Plesk’te bırakıp yeni cPanel’de yeniden ürettik; gönderen itibarı bir anda dalgalandı. Root cause basitti: Alıcılar bir süre iki farklı selector ile farklı anahtarlar gördü. Çözüm, taşıma öncesi tek “kaynak gerçeği” belirlemek ve üretim imzalama anahtarlarını güvenle beraber taşımaktı.

Ölçülebilir Hazırlık

Geçişten önce referans metrikleri alırım: 95. yüzdelik yanıt süresi, 5xx hata oranı, MX kuyruk boyu, IMAP oturum sayısı. Bunu abartmayın, üç beş gösterge yeter. Geçiş anında bu çubuklar normal ritminde mi, yoksa bir şey mi kıpırdıyor, net görürsünüz. Operasyonda şu tip küçük denemeler de yaparım: “Yeni sunucudan staging alan adına trafik ver, gerçek içerikle yük altına sok, logların ritmini dinle.” Böylece final ana gelmeden sistemin terini ölçmüş olursunuz.

DNS’i Ağrısız Taşımak: TTL, Gölgeli Yayın ve Kesim

TTL’i Erken Düşür, Kayıtları İki Tarafta Paralel Tut

DNS’te sıfır kesintinin sırrı, zamanı bükmektir. Yani TTL’i üç dört gün önceden kademeli düşürmek. Önce 3600’den 900’e, sonra 300’e inmek. Böylece NS değiştiğinde dünyadaki önbellekler kısa sürede yeni yanıta döner. Bu arada eski yetkili DNS’te hangi kayıt varsa, yeni tarafta birebir oluştururum. Burada “gölgeli yayın” dediğim şey şu: NS’yi henüz değiştirmeden, hedef DNS üzerine tüm kayıtları eksiksiz yansıtıp gerçek sorgu simülasyonlarıyla doğrulamak.

Gerçek Sorgu ile Doğrulama

Basit ama etkili bir refleks: “Müşterinin en çok trafik alan alan adlarını” tek tek sorgulayıp yeni DNS’teki yanıta bakarım. Elim alışkanlıkla şunu yazar: dig A www.ornek.com @yeni-otori-dns ve çıkan IP eskiyle birebir mi, CDN CNAME’leri doğru mu, wildcard var mı kontrol ederim. Ayrıca alt alanlarda beklenmeyen örten wildcard kayıtlarını tespit etmek için “bilinmeyen” bir alt alanı da denerim. Geçişin birinde “api‑staging‑hidden” diye kimsenin dokunmadığı bir alt alan, üretimdeki ödeme webhook’larını örtüyordu; onu yakalayınca gecemiz kurtuldu.

NS Değişimi ve İzleme

NS’yi değiştirdiğiniz an, geri sayım başlar. O noktada dig +trace çıktısında yeni NS’lerin görünmesiyle beraber 5‑10 dakika içinde dünyadaki yoğun bölgelerde ilk dönüşleri görürsünüz. Ben geçiş anında terminalde küçük bir döngüyle en büyük ISP’leri sırasıyla denerim; “dig www.ornek.com @8.8.8.8” ve “dig www.ornek.com @1.1.1.1” yanıtları beklediğim IP’yi veriyorsa, nefes alırım. DNS tarafında daha derin stratejiye ihtiyacınız varsa, DNS geo‑routing ve felaket dayanıklılığı üzerine şu notlar planınızı rafine eder.

E‑posta: Hesaplar, İçerik ve İtibar Öğeleri (SPF, DKIM, DMARC)

Posta Kutularını Kırmadan Taşımak

E‑posta tarafında “kullanıcı + parolalar + posta içeriği + yönlendirmeler + listeler” dörtlüsünü bir arada görürüm. Hesapları panel araçlarıyla içe aktarmak genelde kolay, ama asıl sıkıntı yılların birikmiş kutu içeriğini taşımaktır. Burada yıllardır işimi gören yöntem, imapsync ile kaynak ve hedef sunucuyu eş zamanlı senkron tutmak. İlk büyük senkronu gündüz yapar, akşam son fark senkronunu alırım. Komut aklımda kalmıştır: “imapsync –host1 eski‑imap –user1 ali –password1 ‘***’ –host2 yeni‑imap –user2 ali –password2 ‘***’ –automap”. Araç detayları için imapsync aracı pratik açıklamalar sunuyor.

SPF, DKIM, DMARC Uyumunu Bozmadan Değiştirmek

İtibarın temel taşları olan SPF, DKIM ve DMARC geçişte kımıldar; biz onların sarsılmasına izin vermeyiz. SPF’te gönderen IP aralığınız değişiyorsa, önce yeni IP’leri include ederek çift taraflı bir döneme girin, sonra eskileri çıkarın. DKIM’de mümkünse eski anahtarların özel anahtarlarını güvenli şekilde yeni tarafa taşıyın; selector’ı koruyun. DMARC’ta raporlama adreslerini geçiş boyunca izlerim, akışta beklenmeyen bir gönderen çıktığında “dig txt _dmarc.ornek.com” ile doğrularım. Bu konuların dönüş yolunda baş ağrısı yapmaması için SPF/DMARC ve SRS/ARC notlarını geçmeden bir gözden geçirmenizi öneririm.

MTA‑STS, TLS‑RPT ve DANE ile İnce Ayar

Posta güvenliğinde bir adım ileri gitmek istiyorsanız, geçiş anı fırsattır. MTA‑STS politikası, TLS raporlaması ve DANE kayıtlarını yeni sunucuyla uyumlu hale getirip, teslim edilebilirliği artırabilirsiniz. Ben genelde finalden önce STS policy dosyasını yeni hostta yayımlar, DNS TXT kaydını düşük TTL ile denerim. Teslimatın nasıl yumuşadığını görmek için raporları birkaç gün izlemek yeter. Detaylar için MTA‑STS, TLS‑RPT ve DANE üzerine bu rehber geçiş planınıza güzel ekler katacaktır.

Web İçeriği ve Veritabanları: İlk Kopya, Artımlı Senkron, Son Kesim

Dosya İçeriğini Isıtmak

Web kökleri, upload klasörleri, logik önbellekler… Hepsini geçişten günler önce hedefe “ısıtırım”. Plesk’te vhosts dizininden cPanel’deki kullanıcı evine senkron için “rsync -aHAX –numeric-ids –info=progress2 /var/www/vhosts/ornek.com/ root@yeni:/home/USERNAME/” kullanmak pratik. İlk büyük kopyadan sonra her akşam kısa artımlı kopyalarla farkı küçültürüm. Böylece final kesimde taşınacak veri gramajı hafifler ve riskiniz düşer.

Veritabanında Donmadan Dondurmak

MySQL/MariaDB geçişlerinde veri tutarlılığını gözetirim. Trafiği tamamen kesmek istemiyorsanız, uygulamayı kısa süreli yazma kilidine alıp, uygulama‑tutarlı bir yedek çıkarın. LVM snapshot veya fsfreeze ile alınmış sıcak bir kopya, beklediğiniz rahatlığı verir. Bu yaklaşımı adım adım anlattığım uygulama‑tutarlı yedekler notlarına bakabilirsiniz. Finalde “mysqldump –single-transaction” ile artımlı son farkı kapatır, “mysql < dump.sql” ile hedefte ayağa kaldırırım; uygulamayı yazmaya yeniden açmadan önce indekslerin ritmini de dinlerim.

CDN, Cache ve Oturum Yönetimi

Geçiş sırasında CDN önbellekleri ve sunucu‑yanı cache katmanları (OPcache, Redis) kafa karıştırır. Ben şu yolu denerim: Yeni tarafta uygulamayı staging alan adıyla kısa süre canlıya yakın koşturur, CDN’de düşük TTL ve soft purge ile ısınmasını izlerim. Oturum saklamayı dosya tabanından Redis’e çekmek, kesim anında kullanıcıların oturum kaybını azaltır. Küçük ama kritik bir kazanım.

SSL/ACME: Sertifikayı Önceden Al, Yenilemeyi Kesmeyecek Şekilde Kurgula

ACME ile Önceden Provision

Geçişte en sevdiğim hamle, DNS‑01 ile sertifikaları finalden önce üretmek. Böylece HTTP doğrulamaya mecbur kalmaz, staging hostta veya yeni panelde hazır beklersiniz. “acme.sh –issue –dns dns_provider -d ornek.com -d *.ornek.com” ile wildcard sertifika bile önceden alınır. Doğrulama yöntemlerini seçerken ACME challenge türlerinin artı‑eksi taraflarını gözden geçirmek, final gecesi sürprizleri azaltır.

CAA ve Yetki Zinciri

CAA kayıtlarını yeni planla uyumlu hale getirmeyi unutmayın. Yeni CA’yı eklemeden sertifika isteği atarsanız, baştan kaybedersiniz. Ben NOC ekranında “dig CAA ornek.com” ile bir bakışta doğrularım. CAA’nın nasıl çoklu‑CA senaryolarını desteklediğini ve değişikliklerin ne zaman mantıklı olduğunu şu derinlemesine yazıda güzel özetledik. HSTS kullanıyorsanız süreleri fazla uzun tutmadan, geçişten önce bir iki adım aşağı çekmek de manevra alanı yaratır.

Panel Eklentileri ve Otomatik Yenileme

Plesk’in Let’s Encrypt eklentisi ile cPanel/AutoSSL farklı davranır. Geçişten önce hangi tarafın yenileme işini devralacağını netleştiririm. Eğer arada kısa bir “ikiz” dönem varsa, sadece bir tarafı aktif bırakır, diğerini pasifleştiririm. Yoksa çakışan yenileme görevleri rate limit’e toslayabilir. Resmi kılavuzlar için cPanel Transfer Tool kullanım kılavuzu ve Plesk Migrator rehberi işinizi kolaylaştırır.

Otomasyon ve Gözlemlenebilirlik: Geçiş Anını İzlemek ve Geri Almayı Hazır Tutmak

IaC ile Tekrar Edilebilir Altyapı

Yeni node’ları Ansible ile kurup, panel kurulumundan sonra servis sertleşmesini (SSH anahtarı, fail2ban, firewalld, TLS ön ayarları) otomatik uygularım. Böylece “şu sunucu farklı kaldı” sürprizi yaşamam. Çekirdek parametrelerden log rotasyonuna kadar her şey playbook’ta durursa, iki ay sonra bile aynı tarifi pişirirsiniz.

Metrikler, Loglar ve Canlı Sağlık Nabzı

Geçiş akşamı her zaman iki küçük komutum vardır. HTTP katmanını gözlemek için “curl -s -o /dev/null -w ‘%{http_code} %{time_total}n’ https://www.ornek.com”, SMTP el sıkışmasını görmek için “openssl s_client -starttls smtp -connect mx.ornek.com:25 -tlsextdebug -brief”. Bunlar küçük fenerlerdir; gözünüz karanlıkta kalmaz. Ayrıca Nginx/Apache 5xx oranı, PHP FPM bekleme kuyruğu, Exim kuyruğu ve Dovecot eşzamanlı oturumları grafikte normal mi, hepsine bakarım. Alarm eşiklerini geçiş gecesi gevşetmem; sadece mesaj metinlerini netleştirir, on‑call arkadaşın ihtiyacı olan bağlamı eklerim.

Rollback Kapısı

Her kesimde geri dönüş kapısını açık tutarım. DNS’te eski NS’lere dönmek bir seçenek, ama daha zarifi şudur: Yeni tarafta health check patlarsa, “maintenance CNAME” ile trafiği geçici olarak eski ortama çevirirsiniz. Bu hamle, kullanıcıların hissettiği sarsıntıyı minimal tutar. Kendi pratiklerimde canary yönlendirmeyi çok severim; eğer altyapınız uygunsa, trafiğin küçük bir yüzdesini yeni tarafa verip, metrikler normal ise kademeli artırmak rahat uyku getirir. Fikir olarak canary dağıtımıyla güvenli rollback yazısındaki yaklaşım panel taşımalarına da uyarlanabilir.

Araçlar: Plesk Migrator, cPanel Transfer Tool ve Küçük Hileler

Panel Araçlarının Ritmi

Plesk’ten cPanel’e giderken iki yanı kullanırım. cPanel tarafındaki Transfer Tool doğrudan Plesk kaynaklarını çekebilir; kullanıcı hesapları, DNS bölgeleri, posta kutuları ve web içeriğini düzgün kavrar. Tersi yönde Plesk Migrator cPanel kaynaklarını içeri alır. Bu araçlar işi yüzde seksen çözer; kalan yüzde yirmi “kıvrımlar”dır: özel Nginx kuralları, cron işleri, beklenmedik PHP ayarları. Cron’ları systemd timer’a taşıyorsanız, davranış farklarını bilmek için cron mu systemd timer mı rehberi iyi bir hatırlatma olur.

Küçük Ama Kurtarıcı Komutlar

DNS doğrulaması için “dig +short NS ornek.com”, DMARC için “dig +short TXT _dmarc.ornek.com”, posta kuyruğu için “exim -bp | exiqsumm”, IMAP canlılarını görmek için “ss -ltnp | grep 143”. Veritabanında uzun süren sorguları yakalamak için slow log’u kısa süre agresif açarım. Bu minik yardımcılar, geçiş anında karar alma hızınızı artırır; gereksiz panik önler.

Ters Yön: cPanel’den Plesk’e Geçerken Farklı Olan Ne?

Farklı Varsayılanlar, Aynı Hedef

cPanel’den Plesk’e dönerken dosya yolları ve servis kalıpları biraz değişir. cPanel’de kullanıcı merkezli “/home/USER/public_html” düzeni, Plesk’te vhost mantığıyla “/var/www/vhosts/DOMAIN/httpdocs” tarafına denk düşer. Bu, yedeklerden dönme ve rsync senaryolarında küçük yol düzeltmeleri gerektirir. PHP selector ve Apache/Nginx birleşimi Plesk’te farklı ayarlanır; özel .htaccess kurallarını Plesk’teki “Ek Nginx Yönergeleri” alanına uyarlamak gerekebilir. E‑posta tarafında da Dovecot/Exim sürümleri ve kutu dizin yapısı değiştiğinden, imapsync ile içerik senkronu yine en güvenli çıkış kapısıdır.

SSL ve ACME Uzantıları

Plesk’in Let’s Encrypt uzantısı, birden çok domain ve alt domaini tek panelden toparlamakta rahattır. cPanel/AutoSSL ise WHM tarafında kullanıcıların tamamına yayılmayı sever. Ters yönde geçerken sertifika yenileme sorumluluğunu yeniden çizip, CAA kayıtlarını kontrol etmek, “hedefte yenileme başarısız” sürprizini ortadan kaldırır. İki durumda da DNS‑01 ile önceden üretmek, geçiş gecesi için sigortadır.

Gerçek Operasyon: Post‑mortemden Kısa Notlar

DKIM Anahtarlarının İki Yüzü

Bir gece, Plesk’ten cPanel’e geçişte her şey pürüzsüz gitti derken, ertesi sabah müşteri “Giden postalar bazen Spam’a düşüyor” dedi. Log’larda göze çarpan bir şey yoktu. TLS tamam, SPF geniş, DMARC relax. Sonra Mail‑Tester benzeri araçta gördük: DKIM selector “s1” iki farklı anahtar geçmişe sahip. Eski Plesk’te tutulan özel anahtar kopyalanmamış, yeni tarafta aynı selector ile yeni anahtar üretilmiş. Bazı alıcılar eski DNS önbellekleri yüzünden bir süre eski public key’i görmüş. Root cause bu. Düzeltme basitti: Eski özel anahtarı güvenle yeni tarafa taşıdık, DNS’te de yeni anahtara tekilleştirdik. Etki penceresi kısa, ama ders büyük: İmzalama anahtarları veri gibi değil, kimlik gibidir; taşınırken bütünlüğü bozulmamalı.

Önleyici Aksiyonlar

Bu olaydan sonra runbook’a şu maddeleri ekledik: Geçişten 24 saat önce DKIM selector envanteri çıkar, özel anahtarların kasasını doğrula, DNS TTL’ini 300’e indir, NS kesiminden 1 saat sonra DMARC raporlarını erken okumaya başla. Bir de küçük script yazdık; “dig TXT default._domainkey.ornek.com” ile public key fingerprint’ini alıp, hedef taraftaki yerel private key ile eşleştiriyor. Küçük ama etkili bir güven testi.

Kapanış: Sakin Geçişlerin Sırrı Küçük Adımlar ve Net Runbook

Toparlayalım. Plesk’ten cPanel’e ya da tersine geçiş, tek bir gecenin işi gibi görünse de, sessiz geçen gecelerin temeli gündüzden atılır. DNS tarafında TTL’i erkenden düşürür, gölgeli yayınla kayıtları doğrularsınız. E‑postada hesapları imapsync ile ısıtır, SPF/DKIM/DMARC üçlüsünü çift taraflı geçiş dönemine göre ayarlarsınız. Web içeriğini rsync ile artımlı senkronlar, veritabanını uygulama‑tutarlı bir kopyayla taşır, finalde kısa bir yazma kilidiyle kapanışı yaparsınız. SSL’leri DNS‑01 ile önceden üretip, CAA ve HSTS ile uyumu kontrol ettiğinizde, geçiş gecesi sürpriz ihtimali azalır.

Uygulanabilir bir mini‑runbook şöyle akar: Bir, envanteri ve riskleri yaz; iki, DNS TTL ve kayıt gölgelemesini başlat; üç, posta kutularını imapsync ile ısıt; dört, web ve DB’yi artımlı senkronla; beş, ACME ile sertifikaları önceden al; altı, canlı metrikleri ve logları ekranda tut; yedi, kesim anında küçük ve geri alınabilir adımlar at; sekiz, DMARC ve kuyruk raporlarını hızlıca tara. Gözünüzü korkutmasın; ekipçe küçük provalar yaptıkça bu akış refleksiniz olur. Yol üstünde daha derinleşmek isterseniz, ACME doğrulama yöntemleri ve CAA stratejileri ile başlayın; e‑posta tarafında ise MTA‑STS ve TLS‑RPT notları güzel birer tamamlayıcıdır. Ekibinize güvenin; net bir runbook, ölçülebilir kontroller ve sakin bir komuta merkeziyle bu geçişler tatlı tatlı biter.