Kesinti Olmadan Web Sitesi Sunucusu Nasıl Taşınır
15 Temmuz 2026 tarihinde yayımlandı
Taşımaya tam, geri yüklenebilir bir yedek ve yazılı bir geçiş planıyla başlayın. Bir web sitesi sunucu altyapısının, rutin bir taşıma işlemini kesintiye dönüştürmeden nasıl taşınacağı sorusunun en güvenli cevabı budur. Yeni sunucunuz, DNS herhangi bir ziyaretçiyi ona yönlendirmeden önce kurulmuş, güvenliği sağlanmış ve test edilmiş olmalıdır. Eski sunucu, yeni ortam gerçek kontrollerden geçene kadar çevrimiçi kalır.
Bir sunucu taşıma işlemi, web sitesi dosyalarını kopyalamaktan fazlasıdır. Web sitesi, veritabanı, zamanlanmış görevler, posta yönlendirme, SSL sertifikaları, uygulama çalışma zamanı, önbellek davranışı, DNS kayıtları ve güvenlik duvarı kuralları hizmetin bir parçası olabilir. Küçük bir bağımlılığın bile gözden kaçırılması, bir sitenin ana sayfada düzgün görünmesine rağmen ödeme e-postaları, formlar veya arka plan işlerinin sessizce başarısız olmasına yol açabilir. Pek gösterişli bir başarısızlık değil, ama yine de maliyetli.
Taşımadan önce mevcut sunucunun haritasını çıkarın
İşe gerçekten nelerin çalıştığının envanteriyle başlayın. Yalnızca barındırma kontrol panelinin gösterdiklerine güvenmeyin. Belge kökünü, uygulama sürümünü, veritabanı motorunu ve sürümünü, PHP veya Node.js ayarlarını, cron job'ları, kuyruk çalışanlarını, depolama yollarını, yönlendirmeleri, ortam değişkenlerini ve giden e-posta yapılandırmasını kontrol edin.
Bir işletme web sitesi için, ana alan adının dışındaki her şeyi de belirleyin. Buna alt alan adları, hazırlık siteleri, API uç noktaları, ödeme geri çağrıları, nesne depolama, üçüncü taraf e-posta sağlayıcıları, analitik betikleri ve doğrulama için kullanılan DNS kayıtları dahil olabilir. Sunucu postayı doğrudan gönderiyorsa, gönderim IP'sini, reverse DNS kurulumunu, SPF, DKIM ve DMARC kayıtlarını not edin. E-posta çoğu zaman en son fark edilen ve müşterilerin ilk şikâyet ettiği öğedir.
Mevcut sunucunun kaynak kullanımını da belgeleyin. CPU yükünü, bellek tüketimini, disk alanını, veritabanı boyutunu, trafik örüntülerini ve hata günlüklerini inceleyin. Bu, yeni VPS veya dedicated server'ın doğru boyutlandırılıp boyutlandırılmadığını gösterir. Bir taşıma, yetersiz boyutlandırılmış bir diski, eski bir PHP sürümünü ya da büyük ölçüde iyimserlikle ayakta kalan bir sunucuyu geride bırakmak için faydalı bir andır.
Önce yeni ortamı hazırlayın
Üretim verilerini kopyalamadan önce hedef sunucuyu hazırlayın. İşletim sistemi güncellemelerini uygulayın, kısıtlı yönetici erişimi oluşturun, güvenlik duvarını yapılandırın ve yalnızca sitenin ihtiyaç duyduğu hizmetleri kurun. Mümkün olan yerlerde yalnızca parola ile erişim yerine SSH anahtarlarını kullanın. Gereksiz hizmetleri devre dışı bırakın ve otomatik güvenlik güncellemelerinin operasyon politikanızla uyumlu olduğundan emin olun.
Uygulama gereksinimlerini dikkatle eşleştirin. PHP 7.4'ten PHP 8.3'e veya MySQL'den daha yeni bir MariaDB sürümüne geçen bir site, doğru çalışmadan önce kod değişiklikleri gerektirebilir. Aynı durum web sunucusu yapılandırması için de geçerlidir. Apache rewrite kuralları, Nginx location'ları, dosya izinleri ve PHP uzantıları her zaman bire bir karşılık gelmez.
İzlemeyi, olay yaşandıktan sonra değil geçişten önce kurun. Kullanılabilirliği, yanıt süresini, CPU'yu, belleği, disk kullanımını, SSL sona erme tarihini ve temel hizmet portlarını izleyin. Arka plan işleme kullanan uygulamalarda kuyruk derinliğini ve başarısız işleri de izleyin. Yönetilen altyapı ve izleme devredeyken günlükler artık aynı hikâyeyi anlatır; ziyaretçiler sorun bildirdikten sonra tahmin yürütmek zorunda kalmazsınız.
Yalnızca iç rahatlığı için değil, kurtarma için yedek alın
Taşıma aralığından hemen önce yeni bir yedek oluşturun. Buna web sitesi dosyaları, veritabanları, yapılandırma dosyaları, kullanıcı tarafından yüklenen içerikler ve web kökünün dışında saklanan uygulama sırları dahil olmalıdır. Yedeğin ayrı bir konuma geri yüklenebildiğini doğrulayın. Hiç test edilmemiş bir yedek, kurtarma planı değil umutlu bir arşivdir.
Veritabanları için tutarlı bir dışa aktarma kullanın. Büyük veya aktif veritabanları, veri değişirken kopyalamaktan kaçınmak için özel işlem gerektirebilir. Veritabanına ve uygulamaya bağlı olarak bir bakım aralığı, salt okunur mod, çoğaltma veya son bir artımlı eşitleme kullanabilirsiniz. E-ticaret mağazaları, rezervasyon sistemleri, SaaS ürünleri ve üyelik siteleri özellikle dikkat gerektirir çünkü siparişler ve hesap değişiklikleri her dakika gelebilir.
Taşıma sırasında orijinal sunucuyu değiştirmeden bırakın. Dosyalar hedefte görünür görünmez onu iptal etmeyin veya verileri silmeyin. Eski ortamı korumak, geçişten sonra gizli bir bağımlılık ortaya çıkarsa size temiz bir geri dönüş yolu sağlar.
Dosyalar ı ve veritabanlarını aşamalı olarak aktarın
Mevcut site canlı kalırken ilk veri kümesini kopyalayın. SSH üzerinden rsync gibi güvenli dosya aktarım araçları kullanışlıdır çünkü daha sonraki son geçiş sırasında yalnızca değişen dosyaları eşitleyebilirler. Veritabanları için ilk dökümü yeni sunucuya içe aktarın, ardından uygulamayı geçici bir ana makine adı veya yerel hosts dosyası geçersiz kılması kullanarak buna karşı test edin.
Yalnızca ön sayfayı test etmekten kaçının. Yönetici olarak da normal kullanıcı olarak da oturum açın. Bir iletişim formu gönderin, parolayı sıfırlayın, bir dosya yükleyin, uygunsa test satın alımı yapın, işlem e-postalarını inceleyin ve zamanlanmış görevlerin çalıştığını doğrulayın. Test ederken uygulama günlüklerini ve web sunucusu hata günlüklerini kontrol edin. Başarılı bir HTTP 200 yanıtı, hizmetin sağlıklı olduğunun kanıtı değildir.
Aynı anda sunucu mimarisini de değiştiriyorsanız, mümkün olduğunda değişiklikleri birbirinden ayırın. Örneğin, yeni bir VPS'ye geçmek; veritabanını yeniden tasarlamadan, önbellek katmanını değiştirmeden ve uygulama çatısını aynı akşam yükseltmeden de yeterince iştir. Ayrı projeler, arızaları teşhis etmeyi ve geri almayı kolaylaştırır.
Geçişten önce DNS TTL'yi düşürün
DNS, teknik olarak ba şarılı bir taşımanın ziyaretçiler için kafa karıştırıcı hâle gelebileceği yerdir. Planlanan geçişten 24 ila 48 saat önce ilgili A, AAAA, CNAME ve postayla ilgili kayıtların TTL değerini azaltın. Daha düşük TTL, alan adını yeni sunucuya yönlendirdikten sonra çözümleyicilerin kayıtları daha hızlı yenilemesini teşvik eder.
Bu, her çözümleyicinin anında güncelleneceğini garanti etmez. Bazı ağlar istenenden daha uzun süre önbelleğe alır ve kullanıcıların yerel DNS önbelleklemesi olabilir. Trafiğin küçük bir bölümünün hâlâ eski sunucuya ulaşabileceği bir geçiş dönemi planlayın. Site değişen veri kabul ediyorsa, bu çakışma için bir stratejiye ihtiyacınız vardır. Son eşitleme sırasında bakım modu kullanmak, iki ayrı sunucuda yeni siparişler kabul etmekten çoğu zaman daha güvenlidir.
DNS barındırmasını da taşımak için bir neden yoksa nameserver'ları değiştirmeyin. Yetkili nameserver'ları değiştirmek, bir ek yayılım katmanı ve doğrulanacak daha fazla kayıt ekler. Mümkün olduğunca taşımanın sıkıcı olmasını sağlayın. Sıkıcı altyapı genellikle sağlıklı altyapıdır.
Son eşitlemeyi yapın ve trafiği yönlendirin
Müşteri verisi yazıyorsa, kararlaştırılan geçiş zamanında uygulamayı bakım moduna alın. Eski sunucudaki kuyruk çalışanlarını ve zamanlanmış görevleri durdurun ki aynı görevi iki kez işleyemesinler. Son dosya eşitlemesini ve veritabanı dışa aktarma/içe aktarma işlemini çalıştırın, ardından hedef yapılandırmayı üretim veritabanı kimlik bilgileri, uygulama anahtarları ve doğru URL'lerle güncelleyin.
Uygulamayı yeni sunucuda etkinleştirin ve DNS'i onun IP adresine güncelleyin. SSL sertifikasının kurulu olduğunu ve HTTP'nin HTTPS'ye doğru şekilde yönlendirildiğini doğrulayın. Sitenin önünde bir load balancer, CDN veya proxy bulunuyorsa, origin yapılandırmasını güncelleyin ve yeni sunucunun sağlık kontrollerini tanıdığını doğrulayın.
Yayılım sırasında her iki sunucuyu da izleyin. Yeni sunucu gelen istekleri göstermeli, eski sunucu ise giderek daha az trafik almalıdır. 404, 500 ve izin hatalarını, ayrıca uygulamaya özgü uyarıları inceleyin. Kaynak kullanımını izleyin çünkü yeni bir sunucu gerçek trafik altında testtekinden farklı davranabilir.
Taşıma sonrası hizmeti doğrulayın
Trafik yeni ortama ulaşmaya başladığında, odaklı bir üretim kontrolü gerçekleştirin. Ana sayfaların yüklendiğini, kullanıcıların kimlik doğrulaması yapabildiğini, formların teslim edildiğini, ödeme veya rezervasyon akışlarının çalıştığını, panoların güncel verileri gösterdiğini ve yüklenen dosyalara erişilebildiğini doğrulayın. Mümkünse birden fazla ağdan test edin, çünkü kendi bilgisayarınızda hâlâ önbelleğe alınmış DNS olabilir.
Önümüzdeki birkaç saat boyunca zamanlanmış etkinliği kontrol edin. Cron job'lar, yedekler, yenilemeler, raporlar, kuyruk çalışanları ve webhook alıcıları, ilk doğrulama geçildikten sonra taşıma sorunlarını sıkça ortaya çıkarır. Posta günlüklerini ve teslimat raporlarını da inceleyin. Site uzak bir SMTP hizmeti kullanıyorsa, yeni sunucunun IP'sinin veya ana makine adının yetkilendirildiğini doğrulayın.
Eski sunucuyu en az 48 ila 72 saat erişilebilir bırakın; karmaşık uygulamalar veya yavaş DNS ortamları için daha uzun süre bırakın. Bu süre boyunca her iki taraftaki yedekleri koruyun ve ilgisiz yapılandırma değişiklikleri yapmayın. İzleme temiz olduğunda, trafik kararlı olduğunda ve geri dönüş penceresi geçtiğinde, eski sunucuyu güvenli şekilde hizmetten çıkarın.
Ne zaman yönetilen destek kullanılacağını bilin
Basit bir tanıtım sitesi genellikle dikkatli hazırlık ve kısa bir bakım aralığıyla taşınabilir. Yüksek trafikli bir mağaza, çok sayıda müşteri sitesine sahip bir ajans portföyü, SaaS platformu veya özel hizmetlere sahip sunucu daha kontrollü bir planı hak eder. Veritabanı çoğaltma, aşamalı yayınlar, trafik boşaltma ve aktif izleme riski azaltır, ancak bunlar deneyimli eller de gerektirir.
kodu.cloud, hedef sunucu hazırlığı ve yedeklerden izleme ve doğrulamaya kadar bir taşımanın operasyonel tarafında yardımcı olabilir. Amaç, süreci gizemli hâle getirmek değildir. Amaç, siz işi sürdürürken birinin altyapıyı izlediğinden emin olmaktır.
İyi bir taşıma sessizce sona erer: ziyaretçiler siteyi kullanır, zamanlanmış işler çalışır, yedekler tamamlanır ve kimsenin gergin bir toplu mesaj göndermesi gerekmez. Kanıtlar hizmetin yeniden sakin olduğunu söyleyene kadar planı, yedeği ve eski sunucuyu saklayın.
Andres Saar Müşteri Hizmetleri Mühendisi