İşe Yarayan Sunucu Paneli Taşıma Kılavuzu
12 Ağustos 2026 tarihinde yayımlandı
Bir sunucu paneli taşıma işlemi, birinin web sitesi klasörünü kopyalamayı unuttuğu için nadiren başarısız olur. DNS, veritabanı kullanıcıları, cron işleri, SSL yenilemesi, posta yönlendirme, izinler gibi birbiriyle bağlantılı küçük parçalar, tek bir üretim sistemi yerine ayrı sorunlar olarak ele alındığında başarısız olur. Bu sunucu paneli taşıma kılavuzu, kontrollü şekilde taşıma yapmanız, herkes görmeden önce test etmeniz ve bir ayrıntı beklenmedik davranırsa geri dönüş yolunu korumanız için size pratik bir yöntem sunar.
Taşıma nedeninizle başlayın
Yeni bir panel, işi sadece farklı bir arayüze taşımak yerine iş yükünü azaltmalıdır. Bir taşıma tarihi seçmeden önce, neyin değiştiği ve neyin tamamen aynı kalması gerektiği konusunda net olun. Kullanımı zor bir panelden ayrılıyor, sunucuları birleştiriyor, hesap izolasyonunu iyileştiriyor veya daha iyi performans ve destek sunan bir altyapıya geçiyor olabilirsiniz.
Bu hedefler planı etkiler. Beş WordPress sitesini taşıyan bir serbest çalışan, hıza ve basit yönetime öncelik verebilir. Yüzlerce müşteri hesabını taşıyan bir hosting sağlayıcısı, tekrarlanabilir süreçlere, izin eşlemesine ve bir iletişim planına ihtiyaç duyar. Yeni panel farklı bir web yığını, PHP sürüm modeli, posta sunucusu veya yedekleme yöntemi destekliyorsa, bunu basit bir aktarım değil teknik bir değişiklik olarak ele alın.
Pazarlık konusu olmayanları yazın: kabul edilebilir kesinti süresi, beklenen performans, uygunsa korunacak IP adresleri, e-posta sürekliliği ve geri alma son tarihi. Bu, taşımayı umut dolu bir gece yarısı projesinden sınırları olan bir operasyona dönüştürür.
Üretim ortamına dokunmadan önce bir envanter oluşturun
Eski paneliniz, hatırladığınız sitelerden daha fazlasını içerir. Her hesabın ve hizmetin envanterini çıkarın, ardından bunu yeni ortamın destekleyebilecekleriyle karşılaştırın. Bir elektronik tablo gayet uygundur. Amaç, bağımlılıkları talebe dönüşmeden önce görünür hâle getirmektir.
Her alan adı için document root'u, uygulama türünü, PHP sürümü ve uzantılarını, veritabanı adı ve kullanıcısını, SSL durumunu, DNS bölgesini, e-posta hesaplarını, yönlendirmeleri, takma adları, cron işlerini, zamanlanmış yedeklemeleri ve tüm harici hizmetleri kaydedin. Staging alan adlarını ve eski alt alan adlarını da ekleyin. Bir API geri çağırması veya müşteri gelen kutusu bunlardan birine bağımlı olana kadar önemsiz görünebilirler.
Ayrıca neyin taşınmaması gerektiğini de belirleyin. Eski arşivler, kullanılmayan posta kutuları, terk edilmiş staging kopyaları ve eski hesaplar, bir taşımayı daha yavaş ve doğrulanması daha zor hâle getirir. Temizlik işlemleri yararlıdır, ancak bunları dikkatle yapın. Taşıma sırasında bir şeyi silmek, ona hâlâ ihtiyaç duyulduğunu keşfetmenin kötü bir yoludur.
Uygulama gereksinimlerini kontrol edin
WordPress, Laravel, Magento ve özel uygulamaların her biri kendi beklentilerini getirir. Desteklenen PHP sürümlerini, gerekli uzantıları, bellek ayarlarını, yükleme sınırlarını, dosya sahipliğini, Redis veya Memcached kullanımını, kuyruk çalışanlarını ve komut satırı görevlerini doğrulayın. Bir uygulama environment dosyaları, özel anahtarlar veya sunucu dışı nesne depolama kullanıyorsa, bunları taşıma kaydına ekleyin.
Bu aynı zamanda sürüm değişikliklerini fark etme anıdır. Eski bir uygulamayı doğrudan PHP 7.4'ten PHP 8.3'e taşımak değerli bir yükseltme olabilir, ancak risk ekler. Mümkün olduğunda, platform modernizasyonunu ilk taşımadan ayırın. Önce sitenin mevcut desteklenen yapılandırmasında çalıştığını kanıtlayın, ardından iyileştirmeleri planlayın.
Hedef sunucuyu doğru şekilde hazırlayın
Taşıma gününü, yeni sunucuda yeterli disk alanı olmadığını veya bir güvenlik duvarı kuralının eksik olduğunu keşfetmek için kullanmayın. Önce hedefi hazırlayın, paneli kurun, sistem güncellemelerini uygulayın ve temel yapılandırmasını doğrulayın. Müşteri verilerini içe aktarmadan önce sunucu ana makine adını, saat dilimini, izlemeyi, yedekleme hedefini ve yönetici erişimini ayarlayın.
Hesap sınırlarını bilinçli şekilde oluşturun. Ajanslar ve hosting sağlayıcıları, daha temiz sahiplik ve daha güvenli erişim için genellikle ayrı müşteri hesaplarına ihtiyaç duyar. Bireysel site sahipleri, birden fazla alan adını içeren tek bir hesabı tercih edebilir. Hiçbir model kendiliğinden doğru değildir. Faturalandırmayı, erişimi, yedeklemeleri ve gelecekteki devirleri kolaylaştıran yapıyı seçin.
FASTPANEL, web sitesi, alan adı, veritabanı ve hesap yönetimini tek bir yerde görünür tutmak için tasarlanmıştır, ancak aynı kural her panel için geçerlidir: geçiş başlamadan önce her kontrolün nerede bulunduğunu anlayın. Tanıdık bir iş akışı, zaman daralırken zaman kazandırır.
Önce yedeklemeleri ve geri alma kurallarını belirleyin
Mümkün olan yerlerde dosyalar, veritabanları, e-posta ve panel yapılandırması dâhil olmak üzere kaynak sunucunun veya etkilenen her hesabın tam yedeğini alın. En az bir yedeğin kaynak makine dışında bir yerde geri yüklenebildiğini doğrulayın. Hiç test edilmemiş bir yedek, kurtarma planı değil, iç rahatlatan bir fikirdir.
Geri alma tetikleyicisini açık bir dille tanımlayın. Örneğin: ödeme tamamlama başarısız olursa, posta teslimatı 15 dakikadan fazla kesilirse veya iki kritik site test planını geçemezse DNS'i eski sunucuya döndürün. Bu kararı kimin verebileceğine karar verin. Kesinti sırasında izin beklemek, kısa bir sorunun uzun bir soruna dönüşmesinin yoludur.
Doğru sırayla taşıyın
En güvenli sıra genellikle verileri erken kopyalamak, son pencere sırasında değişikliği azaltmak, yeniden senkronize etmek, özel olarak test etmek ve ardından trafiği değiştirmektir. Bu, eski ve yeni sunucular arasında sapabilecek veri miktarını sınırlar.
Site dosyalarını ve veritabanlarını hedefe taşıyarak başlayın. Daha büyük veritabanları veya aktif mağazalar için, geçişten çok önce ilk kopyayı kullanın, ardından uygulamayı bakım moduna alıp yazma işlemlerini durdurduktan sonra son dışa aktarma veya senkronizasyonu gerçekleştirin. Statik siteler daha basittir, ancak yine de yakın zamanda yüklenen dosyalar için son bir kontrole ihtiyaç duyar.
E-posta özel dikkat gerektirir. Posta kutuları büyük olabilir ve siz taşıma yaparken iletiler gelmeye devam eder. E-posta aynı sunucuda barındırılıyorsa, DNS değişikliğine yakın bir zamanda son senkronizasyonu planlayın. Üçüncü taraf bir sağlayıcı tarafından yönetiliyorsa, alan adının MX, SPF, DKIM ve DMARC kayıtlarının doğru kaldığından emin olun. Müşteri postası yanlış sunucuya kayboluyorsa çalışan bir web sitesi çok da yardımcı olmaz.
DNS TTL değerini önceden düşürün
Bölgeyi kontrol ettiğiniz durumlarda, geçişten 24 ila 48 saat önce DNS TTL değerlerini azaltın. Daha düşük bir TTL, çözümleyicilerin yeni IP adresini daha erken almasına yardımcı olur. Bu, anında küresel yayılımı zorlamaz ve bazı sağlayıcılar veya yerel önbellekler kayıtları beklenenden daha uzun süre tutabilir. Geçişin sıfır saniye süreceğini vaat etmek yerine çakışma süresi için plan yapın.
DNS değiştikten sonra eski sunucuyu çevrimiçi ve değişmeden tutun. Yeni sunucu diğer herkese hizmet verirken, eski adresi hâlâ çözen ziyaretçilere hizmet vermeye devam edebilir. Site sipariş, form gönderimi veya kullanıcı yüklemesi kabul ediyorsa, bu çakışma süresi ekstra dikkat gerektirir. Verilerin iki kopya arasında bölünmemesi için bir bakım penceresi veya salt okunur mod düşünün.
Herkese açık DNS'i değiştirmeden önce test edin
Taşınan her siteyi hosts-file override veya geçici bir önizleme adresi kullanarak test edin. Herkese açık alan adı hâlâ eski sunucuyu gösterirken yeni sunucuya ulaşmak istersiniz. Ana sayfayı, önemli sayfaları, oturum açma alanlarını, iletişim formlarını, yüklemeleri, aramayı, yönlendirmeleri ve hata günlüklerini kontrol edin. E-ticaret i çin sepeti, ödeme tamamlama sürecini, ödeme geri çağırmalarını, işlemsel e-postayı ve sipariş durumu güncellemelerini test edin.
Ardından kullanıcıların görmediği bölümleri test edin. Veritabanı bağlantılarını, zamanlanmış görevleri, SSL sertifikası kurulumunu, yedekleme işlerini, dosya izinlerini ve önbellek davranışını doğrulayın. Uygulamadan e-posta gönderimini ve taşınan gelen kutularına gelen iletilerin teslimini gözden geçirin. Bu kontrolleri çalıştırırken sunucu kaynaklarını izleyin. Bir kez yüklenen bir site, mutlaka normal trafik için hazır olduğu anlamına gelmez.
Her hesap için kısa bir kabul kontrol listesi oluşturun ve mümkün olduğunda site sahibinin iş açısından kritik iş akışlarını doğrulamasını sağlayın. Hangi belirsiz raporun, formun veya üyelik girişinin faturaları ödediğini onlar bilir.
Sakin şekilde geçiş yapın ve yakından izleyin
Özel testler geçince DNS değişikliğini yapın ve her iki sunucuyu da izlemeye başlayın. Web erişim günlüklerini, hata günlüklerini, CPU ve bellek kullanımını, disk alanını, veritabanı hatalarını ve posta kuyruklarını izleyin. En önemli alan adlarını birden fazla ağ veya cihazdan kontrol edin. Bu, sizi gereksiz paniğe sürüklemeden yerel DNS önbelleği karışıklığını yakalar.
Eski sunucuyu hemen iptal etmeyin. Kabul edilen yayılım süresi boyunca ve yeni sistemde yedeklemeleri, yinelenen işleri ve zamanlanmış yenilemeleri doğrulayacak kadar uzun süre kullanılabilir tutun. Ödeme ağ geçitleri, güvenlik duvarı izin listeleri, izleme araçları, uzak yedekleme sistemleri ve üçüncü taraf DNS kayıtları dâhil olmak üzere eski IP adresini kullanabilecek harici hizmetleri güncelleyin.
İyi bir taşıma olaysız hissettirir, çünkü zor iş geçişten önce yapılmıştır. Kendinize bu avantajı sağlayın: envanteri dikkatle çıkarın, özel olarak test edin, doğrulanmış bir geri dönüş seçeneği bulundurun ve ancak tüm sistemi net şekilde görebildiğinizde taşıyın.