Yerli bulut sunucu geçişi: yurt dışı VPS'ten Türkiye'ye kesintisiz taşıma planı ve maliyet kontrolü

Hetzner, DigitalOcean ya da Contabo gibi bir yurt dışı VPS kullanıyorsanız ve kur ya da KVKK yüzünden yerli bulut sunucu seçeneğine geçmeye karar verdiyseniz, asıl soru artık taşımanın kesintisiz nasıl yapılacağıdır. Bu rehber, sitesi, uygulaması ya da veritabanı tek bir Linux VPS üzerinde çalışan KOBİ sahipleri ve sistem yöneticileri için hazırlandı. Envanterden kesme gecesine ve eski sağlayıcıyı kapatmaya kadar her adımın sonunda neyi kontrol edeceğinizi bulacaksınız.

Yerli bulut sunucuya geçiş ne zaman mantıklı

Geçiş kararını üç ölçütle sınayın. Hiçbiri tutmuyorsa taşıma emeği karşılığını vermeyebilir.

Kur ve fatura. Yurt dışı VPS faturası euro ya da dolar üzerinden kesilir. Aylık rakam küçük görünse de kur değişimi, kartla yurt dışı ödemede banka masrafı ve muhasebe tarafında yurt dışı faturanın işlenmesi toplam maliyeti büyütür. TL faturalı bir hizmette bütçe en azından sözleşme dönemi boyunca öngörülebilir olur. Hesabı kendi rakamlarınızla yapmak için yerli bulut sunucu ile yurt dışı VPS'in 12 aylık maliyet karşılaştırmasına bakabilirsiniz.

KVKK. Sunucuda müşteri, çalışan ya da üye bilgisi gibi kişisel veri varsa, bu verinin yurt dışındaki bir sunucuda tutulması KVKK 9. madde kapsamında yurt dışına aktarım sayılır ve ek yükümlülük doğurur. Ayrıntılar için KVKK uyumlu sunucu ve standart sözleşme rehberini okuyun. Unutmayın: yedekleriniz hâlâ yurt dışındaysa sorun tam çözülmüş olmaz.

Gecikme. Kullanıcılarınızın çoğu Türkiye'deyse, sunucunun da Türkiye'de olması özellikle veritabanına çok sayıda küçük istek atan uygulamalarda ve uzak masaüstü kullanımında fark yaratır.

Geçişin mantıklı olmadığı durumlar da var: kitleniz büyük ölçüde Avrupa ya da Amerika'daysa, ya da yalnızca eski sağlayıcınızın sunduğu yönetilen bir servise sıkı bağlıysanız önce bu bağımlılığı çözün.

Geçiş öncesi envanter: neyi taşıyacağınızı bilin

Kesintisiz taşımanın en sık bozulduğu yer, unutulan küçük bir parçadır: bir cron işi, bir systemd timer, ayrı bir portta çalışan bir servis. Bu yüzden önce eski sunucunun fotoğrafını çekin.

Aşağıdaki betik eski sunucuda yalnızca okuma yapar, hiçbir ayarı değiştirmez. Ubuntu 24.04 ve Debian 12 için hazırlandı, diğer systemd tabanlı dağıtımlarda da büyük ölçüde çalışır. Root olarak çalıştırın. Geri almak için yalnızca oluşan metin dosyasını silmeniz yeterli; tekrar çalıştırmak güvenlidir, her seferinde dosyanın üzerine yazar.

#!/usr/bin/env bash
# envanter.sh: eski sunucunun servis, port, cron, disk ve veritabanı dökümünü çıkarır.
# Yalnız okuma yapar. Çıktı /root altında tarihli bir dosyaya yazılır.
set -u
CIKTI="/root/envanter-$(hostname)-$(date +%F).txt"
{
  echo "== Sistem =="; grep PRETTY_NAME /etc/os-release; uname -r
  echo "== Disk kullanımı =="; df -hT -x tmpfs -x devtmpfs
  echo "== Dinleyen portlar ve süreçler =="; ss -tulpn
  echo "== Çalışan servisler =="; systemctl list-units --type=service --state=running --no-pager
  echo "== root crontab =="; crontab -l 2>/dev/null || echo "root crontab yok"
  echo "== /etc/cron.d =="; ls -l /etc/cron.d 2>/dev/null
  echo "== Kullanıcı crontabları =="; ls /var/spool/cron/crontabs 2>/dev/null || echo "yok"
  echo "== systemd timer listesi =="; systemctl list-timers --all --no-pager
  echo "== Veri dizinleri =="; du -sh /var/www /home /srv /opt 2>/dev/null
  if command -v mysql >/dev/null 2>&1; then
    echo "== MySQL/MariaDB veritabanı boyutları (MB) =="
    mysql -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024) AS mb
              FROM information_schema.tables GROUP BY table_schema;"
  fi
  if command -v psql >/dev/null 2>&1; then
    echo "== PostgreSQL veritabanları =="; sudo -u postgres psql -c '\l+'
  fi
} > "$CIKTI" 2>&1
echo "Envanter yazıldı: $CIKTI"

Çıktıyı bir tabloya dökün ve her satıra "taşınacak", "yeni sunucuda yeniden kurulacak" ya da "artık gerekmiyor" notu düşün. Betiğin göremediği şeyleri elle ekleyin:

• DNS sağlayıcınızdaki tüm kayıtlar: A, AAAA, MX, TXT (SPF, DKIM, DMARC), CNAME.
• Sunucudan e-posta gidiyorsa PTR (ters DNS) kaydı.
• Dışarıdaki servislerde tanımlı IP izin listeleri: ödeme altyapısı geri çağırma adresleri, API sağlayıcıları, uzak veritabanı erişimleri.
• SSL sertifikalarının nasıl yenilendiği (Let's Encrypt, ücretli sertifika).
• Sağlayıcının snapshot ya da yedek özelliğine dayanan yedekleme düzeniniz. Taşımadan sonra bu yedek ortadan kalkacak.

Hedef sunucuyu boyutlandırma ve maliyeti 12 ay üzerinden doğrulama

Eski planınızı birebir kopyalamayın. Bazı yurt dışı sağlayıcılar düşük fiyata bol RAM ya da disk verir; siz bunun ne kadarını gerçekten kullanıyorsunuz, onu ölçün. Bir hafta boyunca free -m, vmstat 5 ve iostat -x 5 çıktılarına, CPU steal değerine ve disk gecikmesine bakın. Kalıcı bir ölçüm için bu komutları cron ya da systemd timer ile birkaç dakikada bir çalıştırıp çıktıyı tarihli bir dosyaya yazdırabilirsiniz.

Karar ölçütü basit: en yoğun saatte bellek kullanımı ve disk gecikmesi rahat bir pay bırakıyorsa küçük başlayın; bulut sunucuda kaynak sonradan büyütülebilir. Ölçüm yapmadan büyük paket almak ise 12 ay boyunca boşa ödeme demektir.

Maliyeti tek bir aylık etiketle değil, 12 aylık bir tabloyla karşılaştırın:

Son satırı atlamayın. Taşıma süresince iki sunucuya birden ödeme yaparsınız; eski sağlayıcının faturalama dönemine göre iptal zamanını planlarsanız bu süreyi kısaltırsınız. Eski tarafta kur için en az iki senaryo (yatay ve artış) yazın, yeni tarafta sözleşmenin TL fiyatı sabitleyip sabitlemediğini ve yenileme koşulunu kontrol edin.

Lokasyon seçerken verinin nerede duracağını netleştirin. Örneğin sunucu.com.tr bulut sunucu hizmeti İstanbul ve Strasbourg (Fransa) lokasyonlarında sunuluyor; KVKK gerekçesiyle taşınıyorsanız İstanbul'u seçmeniz gerekir.

DNS TTL düşürme ve paralel çalışma dönemi

Kesintisiz geçişin anahtarı, DNS değişikliğinin hızlı yayılmasıdır. Bunun için kesme tarihinden en az 48 saat önce ilgili A ve AAAA kayıtlarının TTL değerini 300 saniyeye düşürün. Neden 48 saat? TTL'yi düşürdüğünüz anda dünyadaki önbellekler eski, yüksek TTL değerini hâlâ tutuyordur; yeni değer ancak eski TTL süresi dolunca devreye girer. Eski TTL 86.400 saniyeyse bu en az bir gün demektir.

Değişikliği hem yetkili sunucudan hem de genel çözümleyicilerden doğrulayın:

# Alan adınızın yetkili DNS sunucusunu bulun
dig +short NS example.com
# Yetkili sunucudan ve genel bir çözümleyiciden TTL'yi okuyun
dig +noall +answer example.com A @ns1.example.com
dig +noall +answer example.com A @1.1.1.1

Beklenen çıktı şuna benzer; ikinci sütun TTL'dir ve 300 veya altında olmalıdır:

example.com.   300   IN   A   192.0.2.10

Bu dönemde yeni sunucuyu hazırlayın: aynı işletim sistemi ailesi, aynı PHP, Node.js ya da Python ana sürümü, aynı veritabanı motoru ve mümkünse aynı ana sürüm. Yeni sunucuda güvenlik duvarı kuralı yazacaksanız, kuralları etkinleştirmeden önce SSH portuna izin verdiğinizden emin olun. Aksi halde kendinizi sunucunun dışında bırakırsınız; böyle bir durumda sağlayıcının konsol erişiminin nereden açıldığını önceden öğrenin.

rsync ve veritabanı replikasyonu ile veriyi senkronize etme

Dosyaları yeni sunucudan eski sunucuya bağlanarak çekmek en temiz yöntemdir. Yeni sunucuda bir SSH anahtarı oluşturun ve açık anahtarı eski sunucunun authorized_keys dosyasına ekleyin. Taşıma bitince bu anahtarı eski sunucudan kaldırın.

Aşağıdaki komutlar yeni sunucuda çalıştırılmak için, Ubuntu 24.04 ve Debian 12 için hazırlandı. İlk satırdaki adresi ve dizinleri kendinize göre değiştirin. Komut tekrar çalıştırılabilir; ikinci çalıştırmada yalnızca değişen dosyalar aktarılır. Hedef dizin henüz boş olduğu için geri almak gerekmez; yanlış dizine kopyaladıysanız yalnızca o hedef dizini kontrol ederek temizleyin.

# Yeni sunucuda çalıştırın. ESKI değerini kendi eski sunucunuzla değiştirin.
ESKI="root@192.0.2.10"
KAYNAK="/var/www/"     # sondaki eğik çizgi: dizinin İÇERİĞİNİ kopyalar
HEDEF="/var/www/"

# 1) Önce deneme: hiçbir şey yazmaz, ne aktarılacağını listeler
rsync -aHAX --numeric-ids --dry-run --itemize-changes -e "ssh" "$ESKI:$KAYNAK" "$HEDEF"

# 2) Asıl ilk senkron (büyük veride saatler sürebilir, site çalışmaya devam eder)
rsync -aHAX --numeric-ids --info=progress2 -e "ssh" "$ESKI:$KAYNAK" "$HEDEF"

Kaynak yoldaki sondaki eğik çizgiye dikkat edin; unutursanız /var/www/www gibi iç içe bir dizin oluşur. Seçeneklerin ayrıntısı için sunucuda man rsync komutuyla yerel kılavuza bakabilirsiniz. İlk senkronu kesmeden birkaç gün önce yapın, ardından her gün bir kez daha çalıştırın. Kesme gecesindeki son senkron böylece dakikalar sürer.

Veritabanı için karar ölçütü boyuttur:

• Birkaç GB'a kadar: Kesme gecesinde yazmaları durdurup mysqldump ya da pg_dump ile almak yeterlidir. Önce bir deneme dökümü alıp süresini ölçün; bu süre kesinti pencerenizin büyük kısmını oluşturur.
• Daha büyük ya da kesinti penceresi çok dar: Eski sunucuyu kaynak, yeni sunucuyu kopya olarak replikasyon kurun ve trafiği SSH tüneli üzerinden taşıyın, veritabanı portunu internete açmayın. MySQL için resmi replikasyon belgesi, PostgreSQL için mantıksal ya da akış replikasyonu kullanılabilir. Kesme anında yalnızca kopyanın yetişmesini bekler ve onu ana sunucu yaparsınız.

Kesme gecesi: son senkron, DNS değişikliği ve doğrulama

Trafiğin en düşük olduğu saati seçin ve adımları sırayla izleyin.

1. Uygulamayı bakım moduna alın ya da yazma işlemlerini durdurun (form, sipariş, üye kaydı). Okuma devam edebilir.
2. Son dosya senkronunu ve veritabanı aktarımını yapın.
3. Yeni sunucuyu DNS değişmeden test edin.
4. DNS kayıtlarını yeni IP'ye çevirin.
5. Eski sunucuda cron işlerini durdurun ki aynı görev iki yerde birden çalışmasın.

Son senkron betiği yeni sunucuda çalışır. Ubuntu 24.04 ve Debian 12, MySQL 8 ya da MariaDB için hazırlandı. ORNEK_VERITABANI yerine kendi veritabanı adınızı yazın; root için şifresiz soket girişi yoksa her iki sunucuda /root/.my.cnf dosyasında kimlik bilgisi tanımlayın. Geri alma yolu: eski sunucuya hiçbir yazma işlemi yapılmaz, bu yüzden sorun çıkarsa DNS'i eski IP'ye döndürmeniz yeterlidir.

#!/usr/bin/env bash
# son-senkron.sh: kesme gecesi yeni sunucuda çalıştırılır.
set -euo pipefail
ESKI="root@192.0.2.10"
VT="ORNEK_VERITABANI"

# Son dosya senkronu. --delete, eski tarafta silinen dosyaları yeni tarafta da siler.
# Yalnızca /var/www/ hedefini etkiler; önce aynı komutu --dry-run ile çalıştırıp listeyi okuyun.
rsync -aHAX --numeric-ids --delete -e "ssh" "$ESKI:/var/www/" /var/www/

# Veritabanı yoksa oluştur (varsa dokunmaz)
mysql -e "CREATE DATABASE IF NOT EXISTS \`$VT\` CHARACTER SET utf8mb4;"

# Tutarlı döküm alıp doğrudan yeni veritabanına aktar
ssh "$ESKI" "mysqldump --single-transaction --routines --triggers --events $VT" | mysql "$VT"

echo "Son senkron tamamlandı: $(date '+%F %T')"

DNS'e dokunmadan önce yeni sunucuyu alan adıyla test edin. curl --resolve, isteği DNS'e sormadan doğrudan verdiğiniz IP'ye gönderir:

# 198.51.100.20 yeni sunucunun adresi (örnek)
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" \
  --resolve example.com:443:198.51.100.20 https://example.com/

Beklenen çıktı 200 ile başlayan bir satırdır. 301 ya da 302 görürseniz yönlendirme hedefini, 500 görürseniz uygulama günlüğünü kontrol edin. Ana sayfa dışında giriş sayfası, sepet, arama ve bir yönetim paneli sayfasını da aynı yolla deneyin. Sertifika henüz yeni sunucuda değilse, eski sunucudaki sertifika dosyalarını kopyalayabilir ya da DNS değiştikten sonra yeni sertifika alabilirsiniz.

Testler geçtiyse DNS kayıtlarını değiştirin, ardından eski sunucuda systemctl stop cron ile zamanlanmış görevleri durdurun (gerekirse systemctl start cron ile geri açılır). Sonraki bir saat boyunca eski sunucunun web günlüğünü izleyin: gelen istekler giderek azalmalı. Yeni sunucuda hata günlüğü ve e-posta gönderimi (SPF kaydına yeni IP eklendi mi, PTR ayarlandı mı) kontrol edilmeli.

Eski sağlayıcıyı kapatmadan önce kontrol listesi

Eski sunucuyu hemen silmeyin. En az bir hafta, ideali bir faturalama dönemi açık tutun ve şu maddeleri işaretleyin:

• Eski sunucunun web ve uygulama günlüklerinde birkaç gündür gerçek kullanıcı trafiği yok.
• Yeni sunucuda yedekleme çalışıyor ve en az bir kez geri yükleme denendi.
• Eski sunucunun son tam yedeği alındı ve Türkiye'deki bir depoya kopyalandı. KVKK gerekçesiyle taşındıysanız bu yedeği yurt dışında bırakmayın.
• DNS'teki TTL değerleri normal seviyesine (ör. 3.600) geri alındı.
• Dış servislerdeki IP izin listeleri yeni adresle güncellendi.
• Eski sağlayıcıda kayıtlı snapshot, ek disk, object storage ve yedek alanları tek tek silindi; aksi halde fatura kesilmeye devam eder.
• Abonelik iptali faturalama dönemine göre yapıldı, son fatura indirildi ve muhasebeye iletildi.
• Kişisel veri içeren disklerin silindiği tarih kayda geçirildi.
• Yeni sunucudan eski sunucuya erişen SSH anahtarı kaldırıldı.

Sık yapılan hatalar

TTL'yi kesme gecesi düşürmek. Etki eski TTL kadar gecikir; bazı kullanıcılar bir gün boyunca eski sunucuya gider ve orada yazılan veri kaybolur.

Bakım modu açmadan son senkronu yapmak. Döküm sırasında gelen sipariş ya da kayıt yeni sunucuya hiç ulaşmaz. Yazmaları durdurmadan alınan son senkron, son değildir.

Cron işlerini iki tarafta birden çalıştırmak. Faturalama, e-posta bülteni ya da stok aktarımı gibi görevler çift çalışırsa müşteriye iki e-posta gider ya da kayıtlar çiftlenir.

Sürüm farkını göz ardı etmek. Eski sunucuda PHP 8.1 varken yenisinde daha yeni bir sürümle başlamak, taşımayla yükseltmeyi aynı geceye sıkıştırır. Önce aynı sürümle taşıyın, yükseltmeyi ayrı bir iş olarak planlayın.

E-postayı unutmak. Sunucu kendi e-postasını gönderiyorsa SPF, DKIM ve PTR güncellenmeden giden postalar spam klasörüne düşebilir.

Eski sunucuyu erken kapatmak. Bir sorun çıktığında geri dönecek yeriniz kalmaz. Birkaç günlük ek ücret, geri dönüş imkânının sigortasıdır.

Sık sorulan sorular

Taşıma sırasında site gerçekten hiç kapanmaz mı?

Okuma tarafında kesinti çoğu zaman fark edilmez. Yazma tarafında ise son senkron süresince kısa bir bakım penceresi gerekir; bu süreyi deneme dökümüyle önceden ölçebilirsiniz. Gerçek sıfır kesinti isteniyorsa veritabanı replikasyonu kurmanız gerekir.

Hetzner, DigitalOcean ya da Contabo'nun snapshot'ını doğrudan taşıyabilir miyim?

Sağlayıcılar arasında imaj formatı ve sanal donanım farklı olduğundan snapshot'ı başka bir altyapıda açmak her zaman mümkün değildir ve ağ ayarları bozulabilir. Yeni sunucuyu temiz kurup veriyi rsync ve veritabanı dökümüyle taşımak hem daha öngörülebilir hem de eski sistemde biriken gereksiz yükü bırakmanızı sağlar.

DNS değişikliği ne kadar sürede yayılır?

TTL'yi önceden 300 saniyeye düşürdüyseniz kullanıcıların büyük kısmı birkaç dakika içinde yeni sunucuya gelir. TTL'ye uymayan bazı çözümleyiciler nedeniyle eski sunucuya az sayıda istek bir süre daha gelebilir; bu yüzden eski sunucu birkaç gün açık kalmalıdır.

Alan adımı da Türkiye'ye taşımam gerekir mi?

Hayır. Sunucu taşıması için yalnızca DNS kayıtlarının yeni IP'yi göstermesi yeterlidir. Alan adı kaydını ya da DNS hizmetini taşımak ayrı bir iştir ve aynı geceye sıkıştırılmamalıdır.

Geçiş sonrası sorun çıkarsa nasıl geri dönerim?

Eski sunucuda yazma yapılmadığı sürece DNS kaydını eski IP'ye çevirmek yeterlidir. Ancak yeni sunucuda yeni sipariş ya da kayıt oluştuysa, geri dönmeden önce bu veriyi eski sunucuya aktarmanız gerekir. Bu yüzden ilk saatlerde karar vermek en kolayıdır.

Bu işi hazır yapmak isterseniz

Envanter, senkron ve kesme gecesi adımlarını kendiniz yürütmek yerine bir ekibe bırakmak isterseniz, yurt dışı VPS'ten taşınma sayfasından geçişin nasıl planlandığını ve hangi bilgilerin istendiğini görebilir, talebinizi oradan iletebilirsiniz.

Sonuç

Yurt dışı VPS'ten yerli bulut sunucuya geçiş, sıralı yapıldığında riskli bir iş değildir. Önce envanter çıkarın, maliyeti 12 ay ve çift ödeme dönemiyle birlikte hesaplayın, TTL'yi iki gün önceden düşürün, veriyi rsync ile önceden eşitleyin ve kesme gecesinde yeni sunucuyu curl --resolve ile test etmeden DNS'e dokunmayın. Eski sunucuyu ise yalnızca kontrol listesindeki her madde işaretlendikten sonra kapatın.