Sunucudan Sunucuya Site Taşıma: VDS'ten VDS'e Kesintisiz Geçiş

Sunucudan Sunucuya Site Taşıma: VDS'ten VDS'e Kesintisiz Geçiş

Bir web sitesini ya da uygulamayı bir sunucudan başka bir sunucuya taşımak, çoğu sistem yöneticisinin kariyerinde en az bir kez yapmak zorunda kaldığı, ama her seferinde stres yaratan bir işlemdir. Kaynak yetersiz kaldı, performans beklentiyi karşılamıyor, farklı bir konumdaki veri merkezine geçmek gerekiyor ya da sadece daha güncel bir işletim sistemi şablonuna ihtiyaç var — sebep ne olursa olsun, sonuç aynı soruya çıkar: Site çalışırken, ziyaretçi kaybetmeden, mail akışını bozmadan nasıl taşınır?

Bu yazıda VDS'ten VDS'e taşımayı uçtan uca ele alıyoruz: planlama aşamasından DNS geçişine, dosya ve veritabanı senkronizasyonundan taşıma sonrası doğrulamaya kadar. Amaç, "kopyala-yapıştır" mantığıyla değil, kesinti süresini dakikalara — ideal senaryoda saniyelere — indiren bir yöntemle ilerlemek.

Neden Sunucu Taşıma İhtiyacı Doğar?

Taşıma kararının arkasında genellikle şu nedenlerden biri vardır:

• Kaynak yetersizliği: Trafik artmış, veritabanı büyümüş, mevcut CPU/RAM paketi darboşluk yapıyor.
• Performans sorunları: Disk I/O yavaş, ağ gecikmesi yüksek, sunucu optimizasyonu yapılmış olsa bile donanım tavanına dayanılmış.
• İşletim sistemi / panel yenileme: Eski bir dağıtımdan güncel bir sürüme geçiş, ya da farklı bir kontrol paneline taşınma isteği.
• Konsolidasyon: Birden fazla küçük sunucudaki hizmetleri tek bir güçlü VDS'te toplama.
• Sözleşme veya konum değişikliği: Farklı bir veri merkezi bölgesine, farklı bir sağlayıcıya ya da farklı bir pakete geçiş.

Hangi sebep olursa olsun, taşıma sırasında en çok korkulan şey aynıdır: DNS yayılırken ya da dosyalar kopyalanırken oluşan kesinti penceresi. İyi planlanmış bir taşımada bu pencere dakikalara, hatta paralel çalıştırma yapılırsa saniyelere indirilebilir.

Büyükweb notu: VDS paketlerimizde altyapı VMware vSphere üzerinde çalışır ve kurulum panel üzerinden hazır işletim sistemi şablonu seçilerek yapılır. Yeni sunucuyu hazırlarken kaynak sunucudaki dağıtım ve sürüm bilgisiyle uyumlu bir şablon seçmek, taşıma sonrası paket/servis uyumsuzluklarını en aza indirir.

Taşıma Öncesi Hazırlık ve Planlama

Kesintisiz taşımanın yüzde sekseni, taşımadan önceki hazırlıkta gizlidir. Aceleyle başlanan bir taşıma neredeyse her zaman uzun bir kesintiyle sonuçlanır.

1. Envanter Çıkarın

Kaynak sunucuda tam olarak neyin çalıştığını yazılı hale getirin:

• Web sunucusu ve sürümü (Nginx veya Apache)
• Veritabanı motoru ve sürümü (MySQL/MariaDB/PostgreSQL)
• Çalışan servisler (mail, cron job'lar, PM2 ile yönetilen Node.js süreçleri, Docker konteynerleri)
• Firewall kuralları ve fail2ban gibi güvenlik yapılandırmaları
• SSL sertifikaları ve hangi domainlere bağlı oldukları
• Cron görevleri (crontab -l)
• Kullanıcı hesapları ve dosya izinleri

2. Hedef Sunucuyu Hazırlayın, Ama Devreye Almayın

Yeni VDS'i kurun, gerekli paketleri yükleyin, web sunucusu ve veritabanı motorunu kaynak sunucuyla aynı sürüme getirin. Bu aşamada domain'i henüz yeni sunucuya yönlendirmeyin — hedef, "hazır ama pasif" bir ortam oluşturmaktır.

3. DNS TTL Değerini Düşürün

Taşımadan 24-48 saat önce DNS kayıtlarınızdaki TTL (Time To Live) değerini düşük bir değere (örneğin 300 saniye) çekin. Normalde TTL 3600-86400 saniye gibi yüksek tutulur; bu, DNS sunucularının önbellekte kaydı uzun süre tutması demektir. TTL yüksekken yaptığınız değişiklik saatlerce, hatta bir gün boyunca yayılmayabilir. Düşük TTL ile geçiş anında değişiklik dakikalar içinde yayılır.

example.com.    300    IN    A    <eski_ip>

Taşıma tamamlandıktan ve doğrulandıktan sonra TTL değerini tekrar makul bir seviyeye (3600 saniye gibi) yükseltebilirsiniz.

4. Yedek Alın

Taşımaya başlamadan önce hem kaynak hem hedef ortamda güncel bir yedek bulunmalı. VDS paketlerinde günlük otomatik yedekleme çalışsa da, taşıma öncesi manuel bir "son dakika" yedeği almak, senkronizasyon sırasında oluşabilecek herhangi bir hatada geri dönüş imkânı sağlar. Şifreli ve dış bir depolama noktasına yedek almak isteyenler için restic ile Backblaze B2 üzerine şifreli yedekleme rehberi pratik bir referans.

Büyükweb bakış açısı: Taşıma sırasında "geri dönülemez" bir adım atmadan önce iki bağımsız yedeğin var olduğundan emin olun — biri kaynak sunucuda, biri harici depolamada. Yedek olmadan yapılan taşımalar, küçük bir rsync hatasının bile felakete dönüşmesine yol açabilir.

Taşıma Yöntemleri: Hangi Senaryoda Hangisi?

Tek bir "doğru" taşıma yöntemi yoktur; site tipine ve kesinti toleransına göre değişir.

Yöntem	Ne Zaman Kullanılır	Kesinti Süresi
rsync ile dosya senkronizasyonu	Statik dosyalar, WordPress/PHP siteleri, büyük medya klasörleri	Düşük (son fark senkronizasyonu saniyeler sürer)
Veritabanı dump/restore (mysqldump, pg_dump)	Tüm veritabanı motorları için standart yöntem	Orta (dump/restore süresi veritabanı boyutuna bağlı)
Panel içi taşıma araçları (cPanel/Plesk)	Panel kullanan hosting benzeri kurulumlar	Düşük-orta
Uygulama seviyesinde replikasyon (MySQL master-slave, PostgreSQL streaming replication)	Büyük, sürekli değişen veritabanları	Çok düşük (saniyeler)
Tam disk imajı / snapshot kopyalama	Karmaşık, çok bileşenli sunucular	Orta-yüksek

rsync ile Dosya Taşıma

rsync, dosya taşımada en güvenilir araçlardan biridir çünkü fark tabanlı çalışır — ilk çalıştırmada tüm dosyaları kopyalar, sonraki çalıştırmalarda sadece değişen kısımları aktarır. Bu özellik kesintisiz taşımanın temelini oluşturur:

# İlk tam senkronizasyon (site çalışırken yapılabilir)
rsync -avz --progress -e ssh /var/www/site/ kullanici@yeni-sunucu-ip:/var/www/site/

# Kesinti penceresinde son fark senkronizasyonu
rsync -avz --delete -e ssh /var/www/site/ kullanici@yeni-sunucu-ip:/var/www/site/

İlk komut saatler sürebilir ama site hâlâ eski sunucuda canlı çalışıyor olur. Kesinti penceresinde çalıştırılan ikinci komut ise yalnızca aradaki farkı taşıdığı için genellikle birkaç saniye ile birkaç dakika arasında tamamlanır.

Veritabanı Taşıma

MySQL/MariaDB için:

# Kaynak sunucuda dump alma
mysqldump -u kullanici -p --single-transaction --quick veritabani_adi > yedek.sql

# Hedef sunucuya aktarma
mysql -u kullanici -p yeni_veritabani_adi < yedek.sql

--single-transaction parametresi, InnoDB tabloları için dump alırken tabloyu kilitlemeden tutarlı bir anlık görüntü almanızı sağlar — bu, site canlıyken dump almak için kritik bir ayrıntı.

PostgreSQL için benzer mantık pg_dump ve pg_restore ile uygulanır.

Büyük veritabanlarında (birkaç GB üzeri) dump/restore süresi kesinti penceresini uzatabilir. Bu durumda replikasyon kurup son anda sadece "fark"ı senkronize etmek daha sağlıklıdır.

Adım Adım Kesintisiz Taşıma Süreci

Aşağıdaki sıralama, kesinti süresini minimuma indiren pratik bir akıştır.

1. Hazırlık (taşımadan günler önce)
DNS TTL'i düşürün, hedef VDS'i kurun, gerekli yazılımları yükleyin, firewall ve güvenlik kurallarını (fail2ban dahil) hedefte de tanımlayın.

2. İlk tam senkronizasyon (site canlıyken)
rsync ile dosyaları, mysqldump ile veritabanını hedef sunucuya aktarın. Bu adım saatler sürebilir, sitenin kullanıcıları hiçbir şey fark etmez çünkü kaynak sunucu hâlâ trafiği karşılıyor.

3. Hedefte doğrulama testi
Yeni sunucuda hosts dosyasını geçici olarak düzenleyerek (ya da doğrudan IP + Host header ile) siteyi domain adı olmadan test edin. Sayfa yükleniyor mu, veritabanı bağlantısı çalışıyor mu, form gönderimleri doğru mu işleniyor kontrol edin.

4. Kısa kesinti penceresini açın
Kaynak sunucuda siteyi bakım moduna alın (veya salt-okunur hale getirin) ki senkronizasyon sırasında veri kaybı yaşanmasın.

5. Son fark senkronizasyonu
rsync --delete ile dosyalardaki son farkı, mysqldump ile veritabanındaki son değişiklikleri aktarın. Bu adım genellikle birkaç dakikadan kısa sürer.

6. DNS kaydını güncelleyin
A kaydını yeni sunucunun IP adresine yönlendirin. TTL düşük olduğu için yayılım hızlı gerçekleşir.

7. Trafiği izleyin ve doğrulayın
İstek loglarını hem eski hem yeni sunucuda izleyin. Trafik yeni sunucuya kaydıkça eski sunucu üzerindeki bağlantı sayısının düştüğünü göreceksiniz.

8. Eski sunucuyu bir süre canlı tutun
DNS TTL'i düşük olsa bile bazı çözümleyiciler (özellikle kurumsal ağlar, mobil operatörler) eski kaydı beklenenden uzun tutabilir. Eski sunucuyu en az 48-72 saat kapatmayın; bu sürede gelen istekleri loglayarak kimin hâlâ eski IP'ye ulaştığını görebilirsiniz.

Büyükweb bakış açısı: "Kesintisiz" taşıma aslında sıfır kesinti anlamına gelmez — amaç, kesinti süresini kullanıcının fark etmeyeceği kadar kısaltmaktır. Bakım moduna alma + son fark senkronizasyonu + DNS geçişi adımlarının toplamı, iyi planlanmış bir taşımada genellikle 5-15 dakika arasında tamamlanır.

DNS Geçişi ve TTL Yönetimi

DNS, taşımanın en çok yanlış anlaşılan parçasıdır. Şu noktaları netleştirmek gerekir:

• TTL değeri, kaydın önbellekte ne kadar tutulacağını belirler, sunucudaki değişikliğin hızını değil. TTL'i taşımadan önce düşürmeniz gerekir, taşıma anında düşürmek işe yaramaz çünkü eski TTL değeri zaten önbelleklere yayılmıştır.
• A kaydı yalnızca alan adının IPv4 adresini gösterir. VDS'iniz tek bir IPv4 adresiyle çalışıyorsa, taşıma sonrası tek yapmanız gereken A kaydını yeni IP'ye çevirmektir; MX, TXT, CNAME gibi diğer kayıtları da unutmadan kontrol edin.
• Mail akışını ayrı planlayın. Web sitesi taşınırken mail hizmeti hâlâ eski sunucuda çalışıyorsa MX kaydına dokunmayın. Mail de taşınacaksa, mail kutularının senkronizasyonu ayrı bir süreç olarak ele alınmalı ve web taşımasıyla aynı anda yapılmamalıdır — aynı anda iki kritik servisi taşımak, sorun çıktığında hangi bileşenin arızalandığını tespit etmeyi zorlaştırır.
• Uptime kaybını en aza indirmek için taşıma penceresini trafiğin en düşük olduğu saat dilimine (genellikle gece 02:00-05:00 arası) planlamak, olası sorunların etkisini azaltır.

Taşıma Sonrası Doğrulama Checklist

Taşıma tamamlandıktan sonra aşağıdaki kontrolleri sırayla yapın:

• Site ana sayfa, giriş formu ve dinamik sayfalar hedef sunucuda hatasız açılıyor mu?
• SSL sertifikası doğru domain(ler) için geçerli mi, tarayıcı uyarısı var mı?
• Veritabanı bağlantı bilgileri (host, kullanıcı, şifre) yeni ortamda güncellendi mi?
• Cron görevleri yeni sunucuda tanımlı ve çalışıyor mu?
• Dosya izinleri (özellikle upload/cache klasörleri) doğru mu?
• Firewall ve fail2ban kuralları hedefte aktif mi?
• 502 Bad Gateway veya 504 Gateway Timeout gibi proxy/upstream hataları alınıyor mu — özellikle Nginx-PHP-FPM veya reverse proxy zincirlerinde bu hatalar taşıma sonrası yapılandırma uyuşmazlığının ilk işaretidir.
• Trafik ve kaynak kullanımı izleniyor mu? Taşıma sonrası ilk 48 saat için Zabbix veya Nagios gibi bir izleme aracı kurmak, beklenmedik yük artışlarını veya servis kesintilerini erken yakalamanızı sağlar.
• E-posta gönderimi (varsa) test edildi mi — SPF/DKIM kayıtları yeni IP ile uyumlu mu?

Yeni VDS'te kaynak kullanımını izlemeye başlamak, sadece taşımanın başarısını doğrulamakla kalmaz, gelecekteki kapasite planlamasına da veri sağlar. VDS Sunucu paketlerinde kaynak (CPU, RAM, disk) tahsisi net olduğundan, taşıma sonrası ölçümlerle "bir sonraki büyümede hangi pakete geçilmeli" sorusunun cevabı daha somut hale gelir.

Sık Karşılaşılan Sorunlar ve Çözümleri

Dosya izinleri bozuluyor. rsync varsayılan olarak izinleri korur, ama kullanıcı/grup ID'leri kaynak ve hedef sunucuda farklıysa (örneğin www-data kaynak sunucuda 33, hedefte 1000 numaralı kullanıcıya karşılık geliyorsa) dosya sahiplikleri karışabilir. Taşıma sonrası chown -R www-data:www-data /var/www/site gibi bir komutla sahiplikleri yeniden düzeltmek gerekebilir.

Veritabanı karakter seti uyuşmazlığı. Kaynak utf8, hedef utf8mb4 gibi farklı varsayılan karakter setleriyle kurulmuşsa, Türkçe karakterler veya emoji içeren kayıtlarda bozulmalar görülebilir. Dump alırken --default-character-set=utf8mb4 gibi parametrelerle tutarlılığı garanti altına alın.

Disk alanı yetersizliği. Büyük bir siteyi taşırken hedef sunucuda geçici olarak hem eski hem yeni dosyaların bir arada bulunması gerekebilir; disk doluluğu kontrol edilmezse 452 Insufficient System Storage benzeri disk kaynaklı hatalarla karşılaşılabilir. Taşımadan önce hedef sunucuda yeterli boş alan olduğundan emin olun.

Panel erişim yönetimi ile ilgili karışıklıklar. VMware vSphere altyapılı bir VDS'te sanallaştırma paneline erişimi kısıtlamak isteyenler için, taşıma sonrası güvenlik sıkılaştırması kapsamında ESXi web paneline IP erişim kısıtlaması rehberi faydalı bir referans olabilir.

DNS geçişinin beklenenden uzun sürmesi. TTL düşürülmüş olsa bile bazı ISS'lerin DNS önbellekleri kuralları görmezden gelip kaydı daha uzun tutabilir. Bu durumda sabırlı olun; eski sunucuyu birkaç gün daha aktif tutmak, geç güncellenen çözümleyicilerden gelen kullanıcıların da kesintisiz devam etmesini sağlar.

SSH bağlantı sorunları taşıma sırasında. Uzun süren rsync transferlerinde SSH oturumu zaman aşımına uğrayabilir. screen veya tmux içinde çalıştırmak, bağlantı koptuğunda transferin devam etmesini sağlar.

Sıkça Sorulan Sorular

VDS'ten VDS'e taşıma ne kadar sürer?

Bu tamamen site büyüklüğüne ve veritabanı boyutuna bağlıdır. İlk tam senkronizasyon (site canlıyken) birkaç saat sürebilir, ancak asıl kesinti penceresi — bakım moduna alma, son fark senkronizasyonu ve DNS geçişi — genellikle 5-15 dakika arasında tamamlanır.

Taşıma sırasında siteyi tamamen kapatmam gerekir mi?

Hayır, tam kapatmaya gerek yoktur. Doğru sırayla ilerlenirse (önce büyük veri kaynak sunucudayken senkronize edilir, sonra kısa bir pencerede son fark aktarılır) site sadece birkaç dakika boyunca bakım modunda kalır, bu süre dışında erişilebilir olur.

DNS yayılımını hızlandırmak mümkün mü?

Doğrudan hızlandıramazsınız ama taşımadan 24-48 saat önce TTL değerini düşürerek yayılım süresini büyük ölçüde kısaltabilirsiniz. TTL'i taşıma anında düşürmek işe yaramaz çünkü eski değer zaten önbelleklerde beklemektedir.

Veritabanı çok büyükse ne yapmalıyım?

Birkaç GB'ı aşan veritabanlarında tek seferlik mysqldump/restore işlemi kesinti süresini uzatabilir. Bu durumda master-slave replikasyon kurup, kesinti penceresinde sadece son birkaç saniyelik farkı senkronize etmek daha sağlıklı bir yaklaşımdır.

Mail hizmetini de aynı anda mı taşımalıyım?

Önerilmez. Web sitesi ve mail servisini aynı anda taşımak, bir sorun çıktığında kaynağını tespit etmeyi zorlaştırır. Mail kutuları için ayrı bir taşıma planı yapmak, MX kaydını web sitesinden bağımsız yönetmek daha güvenlidir.

Taşıma sonrası eski sunucuyu ne zaman kapatabilirim?

DNS TTL düşük tutulmuş olsa bile bazı ağlarda eski kayıt birkaç gün önbellekte kalabilir. Eski sunucuyu en az 48-72 saat aktif tutup gelen istek loglarını izlemek, kimsenin hâlâ eski IP'ye ulaşmadığından emin olmanın en güvenli yoludur.

Taşıma sırasında SSL sertifikası ile ilgili ne yapmalıyım?

Sertifikayı (varsa özel sertifika dosyalarını) hedef sunucuya önceden kopyalayın ve web sunucusu yapılandırmasında tanımlayın. Let's Encrypt gibi otomatik yenilenen sertifikalar kullanıyorsanız, hedef sunucuda domain doğrulaması ancak DNS geçişi tamamlandıktan sonra başarılı olur; bu nedenle geçiş sonrası ilk yenileme denemesini takip edin.

Büyükweb Hizmetleri

Sunucudan sunucuya taşıma sürecinde ihtiyaç duyacağınız kaynak esnekliği ve altyapı için:

• VDS Sunucu — VMware vSphere altyapılı, panel üzerinden hazır işletim sistemi şablonlarıyla kurulan, günlük otomatik yedeklemeli VDS paketleri

Taşıma planınızı oluştururken ya da süreçte teknik destek almak istediğinizde 0850 302 60 70 numaralı satış öncesi destek numaramızdan bize ulaşabilir, ya da iletişim sayfası üzerinden bizimle iletişime geçebilirsiniz.