Eski VDS'ten Yeni VDS'e Taşınma: Kesintisiz Geçiş Planı

Yeni VDS'i aldınız, eskisinin süresi on bir gün sonra doluyor. Eski makinede cPanel gibi bir panel yok; nginx elle yapılandırılmış, iki cron görevi var, Let's Encrypt sertifikaları certbot ile yenileniyor ve bir yerlerde iki yıl önce eklenmiş bir systemd servisi çalışıyor. Panelden panele taşıma yapan araçların hiçbiri burada işe yaramaz, çünkü ortada standart bir yapı yok — makinenin tamamı elle kurulmuş bir yapılandırmalar toplamı.

Bu tür geçişlerde kesinti, DNS değişikliğinden değil eksik envanterden doğar. Site yeni sunucuda açılır, herkes rahatlar, üç gün sonra "fatura e-postaları gelmiyor" ya da "haftalık rapor oluşmuyor" diye bir bildirim gelir; çünkü kimse o cron görevini not almamıştır. Bu yüzden aşağıdaki planın en uzun bölümü veri kopyalama değil, taşımadan önce ne olduğunu yazıya dökmek.

Aşağıda panelsiz bir Linux VDS'ten diğerine geçişin saat saat planı var: envanter çıkarma, rsync ile veri, mysqldump ile veritabanı, iki sunucuyu paralel çalıştırıp hosts dosyasıyla test etme, ardından TTL düşürerek kontrollü DNS geçişi ve eskisini kapatma kriteri.

Taşıma Takvimi: Yedi Günlük Plan#

Aceleye getirilen geçişlerde hata yapılır. Şu takvim, gerçek kesintiyi birkaç dakikaya indirir:

Bu planın kritik noktası, T-3 gününde yapılan testtir. O gün site yeni sunucuda tam olarak çalışıyorsa, T-0 anında yapılacak iş yalnızca değişen dosyaları ve son veritabanı hâlini taşımaktan ibaret kalır. Kesintinin kısalığı da buradan gelir.

Envanter Çıkarmadan Hiçbir Şeye Dokunmayın#

Eski sunucuda çalışan her şeyi tek bir dosyaya yazın. Bu adımı atlamak, taşımadan sonraki iki hafta boyunca sürprizlerle uğraşmak demektir.

mkdir -p /root/envanter && cd /root/envanter

# Çalışan servisler ve dinlenen portlar
systemctl list-units --type=service --state=running --no-pager > servisler.txt
ss -tulpn > portlar.txt

# Tüm kullanıcıların cron görevleri
for u in $(cut -d: -f1 /etc/passwd); do
  crontab -u "$u" -l 2>/dev/null | sed "s|^|[$u] |"
done > cronlar.txt
ls -l /etc/cron.d /etc/cron.daily /etc/cron.hourly >> cronlar.txt

# Kurulu paketler
dpkg --get-selections > paketler.txt          # Debian / Ubuntu
# rpm -qa --qf '%{NAME}\n' | sort > paketler.txt   # AlmaLinux / Rocky

# Web sunucusu yapılandırmasının tamamı
nginx -T > nginx-tam.conf 2>/dev/null
apachectl -S > apache-vhostlar.txt 2>/dev/null

# PHP sürümü ve yüklü eklentiler
php -v > php.txt && php -m >> php.txt

# Sertifikalar ve veritabanları
certbot certificates > sertifikalar.txt 2>/dev/null
mysql -e "SHOW DATABASES;" > veritabanlari.txt

# Sistem kullanıcıları (UID 1000 ve üzeri)
awk -F: '$3>=1000 && $3<65534 {print $1, $3, $6}' /etc/passwd > kullanicilar.txt

nginx -T komutu, include ile dahil edilen tüm dosyalar dâhil yapılandırmanın tamamını basar; tek tek dosya aramaktan kurtarır. Bu dizini yeni sunucuya da kopyalayın, taşıma boyunca kontrol listeniz olacak.

Envanterde özellikle şu dördünü aramayı unutmayın: güvenlik duvarı kuralları (ufw status numbered veya iptables-save), fail2ban jail'leri, /etc/hosts içindeki elle eklenmiş satırlar ve sistem saat dilimi (timedatectl). Dördü de kopyalanan dosyaların içinde değildir ve dördü de unutulduğunda garip davranışlara yol açar.

Yeni Sunucuyu Eskisinin Aynası Hâline Getirmek#

Veri kopyalamadan önce yeni makinede aynı yazılım yığınının kurulu olması gerekir. Amaç birebir aynı sürümü yakalamak değil; büyük sürüm (major) farkı olmamasıdır. PHP 8.1'den 8.3'e geçmek genellikle sorunsuzdur ama MySQL 5.7'den MariaDB 11'e geçmek karakter kümesi ve sql_mode farkları yüzünden uygulamanızı bozabilir.

# Eski sunucuda
php -v | head -1
mysql -e "SELECT @@version, @@character_set_server, @@collation_server;"
nginx -v

# Yeni sunucuda aynı komutlarla karşılaştırın

Sürüm atlamak istiyorsanız bunu taşımayla aynı anda yapmayın. İki değişkeni birleştirdiğinizde bir sorun çıktığında sebebini bulmak iki katına çıkar. Önce eşdeğer sürümle taşıyın, iki hafta sonra sürüm yükseltmesini ayrı bir iş olarak yapın.

Yeni sunucuda ayrıca aynı kullanıcı ve grup kimliklerini (UID/GID) oluşturun. rsync sahiplik bilgilerini sayısal kimlik olarak taşıyacağı için, www-data kullanıcısının iki makinede farklı UID'ye sahip olması dosya izinlerinin bozulmasına yol açar.

Dosyaları rsync ile Taşıma#

rsync bu iş için doğru araçtır: kesintiye uğrarsa kaldığı yerden devam eder ve ikinci çalıştırmada yalnızca değişenleri gönderir. Genel yedekleme mantığını rsync ile yedekleme yazısında bulabilirsiniz; burada taşımaya özel bayraklara odaklanalım.

# Yeni sunucuya SSH anahtarınızı önce yükleyin
ssh-copy-id -p 22 root@YENI_IP

# İlk tam kopya (T-3 gün)
rsync -aHAX --numeric-ids --info=progress2 -e "ssh -p 22" \
  /var/www/ root@YENI_IP:/var/www/

rsync -aHAX --numeric-ids -e "ssh -p 22" \
  /etc/nginx/ root@YENI_IP:/etc/nginx/

rsync -aHAX --numeric-ids -e "ssh -p 22" \
  /etc/letsencrypt/ root@YENI_IP:/etc/letsencrypt/

Bayrakların anlamı önemlidir: -a zaman damgası, izin ve sembolik bağlantıları korur; -H sabit bağlantıları (hardlink) bozmaz; -A ACL'leri, -X genişletilmiş öznitelikleri taşır. --numeric-ids ise sahiplik bilgisini isim yerine sayısal kimlikle aktarır — iki makinedeki kullanıcı listeleri farklıysa dosyaların yanlış kullanıcıya geçmesini engeller.

T-0 anındaki delta senkronunda --delete ekleyebilirsiniz; böylece eski sunucuda silinmiş dosyalar yenisinde de silinir:

rsync -aHAX --numeric-ids --delete -e "ssh -p 22" \
  /var/www/ root@YENI_IP:/var/www/

--delete bayrağı hedefteki fazlalıkları siler. Yanlış bir kaynak yolu yazarsanız hedef dizini boşaltabilir. İlk çalıştırmayı mutlaka --dry-run ile deneyin ve çıktıda deleting satırlarının beklediğiniz dosyalar olduğunu görün.

Kök dizinin tamamını (/) kopyalamaya çalışmayın. /proc, /sys, /dev ve /run çekirdek tarafından üretilen sanal dosya sistemleridir; kopyalanmaları anlamsız ve zararlıdır. Uygulama verisi, web kök dizini, yapılandırma dizinleri ve kullanıcı ev dizinleri yeterlidir.

Veritabanını mysqldump ile Taşıma#

Veritabanı, taşımanın en hassas parçasıdır çünkü dosyaların aksine sürekli değişir. Yöntem ve bayraklar için mysqldump ile veritabanı yedekleme yazısı ayrıntılı bir kaynak; taşımada kullanacağınız biçim şudur:

mysqldump --single-transaction --quick --routines --triggers --events \
  --default-character-set=utf8mb4 --databases uygulama_db > /root/uygulama.sql

--single-transaction InnoDB tablolarını kilitlemeden tutarlı bir anlık görüntü alır, yani site açık kalabilir. --routines, --triggers ve --events unutulduğunda saklı yordamlar, tetikleyiciler ve zamanlanmış olaylar yeni sunucuya hiç gitmez — bu, taşıma sonrası "bazı raporlar oluşmuyor" şikâyetinin klasik sebebidir. --databases kullanmak dosyaya CREATE DATABASE ve USE satırlarını da ekler, böylece hedefte veritabanını elle oluşturmanız gerekmez.

Dosya oluşturmadan doğrudan aktarmak da mümkündür:

mysqldump --single-transaction --quick --routines --triggers --events \
  --databases uygulama_db | ssh root@YENI_IP "mysql"

Kullanıcılar ve yetkiler ayrı bir iştir. mysqldump uygulama veritabanını taşır ama mysql.user tablosundaki hesapları taşımaz. Uygulamanız yeni sunucuda "Access denied" ile karşılaşırsa sebebi budur:

mysql -N -B -e "SELECT CONCAT('SHOW GRANTS FOR \`',user,'\`@\`',host,'\`;') \
  FROM mysql.user WHERE user NOT IN \
  ('root','mysql.sys','mysql.session','mysql.infoschema','debian-sys-maint');" \
  | mysql -N -B | sed 's/$/;/' > /root/yetkiler.sql

Çıkan yetkiler.sql dosyasını gözden geçirip (parolalar karma hâlinde taşınır) yeni sunucuda çalıştırın. Ayrıca uygulamanızın yapılandırma dosyasındaki veritabanı sunucusu adresi localhost ise değiştirmeye gerek yoktur; ayrı bir IP yazıyorsa güncellemeyi unutmayın.

SSL Sertifikaları, Cron'lar ve Servisler#

Let's Encrypt sertifikaları için /etc/letsencrypt dizinini kopyalamak yeterlidir; hesap anahtarı, sertifikalar ve yenileme yapılandırması hep birlikte orada durur. Ancak yeni sunucuda yenileme denemesi, DNS henüz oraya bakmadığı için başarısız olacaktır. Bu normaldir; DNS geçişinden sonra doğrulayın:

# DNS geçişinden SONRA yeni sunucuda
certbot certificates
certbot renew --dry-run

Cron görevlerini kopyalarken en sık yapılan hata, dosyaları taşıyıp crontab içeriğini unutmaktır. Envanterde çıkardığınız cronlar.txt dosyasını satır satır gözden geçirin ve ilgili kullanıcı altında yeniden tanımlayın. Aynı görevin iki sunucuda birden çalışmasını istemiyorsanız — özellikle e-posta gönderen veya ödeme işleyen görevlerde — eski sunucunun cron'unu geçiş anında devre dışı bırakın:

systemctl stop cron        # Debian / Ubuntu
# systemctl stop crond     # AlmaLinux / Rocky

Elle yazılmış systemd servisleri için birim dosyalarını kopyalayıp etkinleştirin:

rsync -aHAX /etc/systemd/system/ozel-servis.service root@YENI_IP:/etc/systemd/system/
ssh root@YENI_IP "systemctl daemon-reload && systemctl enable --now ozel-servis"

E-posta da sunucuda çalışıyorsa taşınması ayrı bir konudur: posta kutularının kopyalanması, MX kaydı ve rDNS/PTR kaydının yeni IP'ye tanımlanması gerekir. Ayrıntılar için e-postaları yeni sunucuya taşıma yazısına bakın. PTR kaydını taşımadan MX'i çevirirseniz giden postalarınız spam klasörüne düşmeye başlar.

DNS'i Değiştirmeden hosts Dosyasıyla Test Edin#

Bu adım, taşımayı stresli olmaktan çıkaran şeydir. Kendi bilgisayarınızın hosts dosyasına yeni sunucunun IP'sini yazarak, dünyanın geri kalanı hâlâ eski sunucuyu görürken siz yenisini test edersiniz. Yöntemin tamamı hosts dosyası ile site test etme yazısında anlatılıyor; özet olarak:

# Linux / macOS: /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts (Not Defteri'ni yönetici olarak açın)
203.0.113.50   ornek.com www.ornek.com

Kaydettikten sonra tarayıcı önbelleğini değil sistem DNS önbelleğini temizleyin: Windows'ta ipconfig /flushdns, macOS'ta sudo dscacheutil -flushcache, systemd kullanan Linux dağıtımlarında sudo resolvectl flush-caches.

Sonra şu listeyi baştan sona uygulayın. Hepsi yeşil olmadan DNS'e dokunmayın:

Bu testi T-3 gününde bir kez, T-2 gününde eksikleri kapattıktan sonra bir kez daha yapın.

TTL Düşürme ve DNS Geçişi#

DNS kayıtları, TTL süresi boyunca çözümleyicilerde önbelleğe alınır. Kaydınızın TTL'i 86400 saniye (24 saat) ise, IP'yi değiştirdikten sonra bazı ziyaretçiler bir gün daha eski sunucuya gitmeye devam eder. Çözüm, geçişten önce TTL'i düşürmektir. Kavramın ayrıntısı için TTL nedir yazısına bakabilirsiniz.

Geçişten en az 24 saat önce (eski TTL süresi kadar önce) A kaydının TTL'ini 300 saniyeye çekin. Mevcut değeri iki farklı yerden kontrol edin:

# Çözümleyicideki kalan süre (geri sayar)
dig +noall +answer ornek.com A

# Yetkili sunucudaki gerçek yapılandırılmış TTL
dig +noall +answer @ns1.saglayici.com ornek.com A

İkisi arasındaki fark önemlidir: ilk komut önbellekte kalan süreyi, ikincisi kaydın kendi TTL değerini gösterir. Değişikliğinizin uygulandığını ikinci komutla doğrulayın.

Geçiş anında (T-0) sıralama şudur:

1. Uygulamayı bakım moduna alın veya yazma işlemlerini durdurun.
2. Eski sunucuda cron'u durdurun.
3. Delta rsync çalıştırın (yalnızca değişenler gider, saniyeler sürer).
4. Son mysqldump alıp yeni sunucuya aktarın.
5. Yeni sunucuda uygulamayı açın ve hosts üzerinden son bir kontrol yapın.
6. DNS'te A ve AAAA kayıtlarını yeni IP'ye çevirin.
7. hosts satırınızı silip önbelleği temizleyin; artık gerçek DNS üzerinden test ediyorsunuz.

Geri dönüş planınız da hazır olsun: DNS kaydını eski IP'ye geri almak yeterlidir, çünkü eski sunucu hâlâ ayaktadır. Bu yüzden eski makineyi geçiş gününde kapatmıyoruz.

Taşıma Sonrası İlk Hafta: Neyi İzlemelisiniz?#

Geçiş tamamlandığında iş bitmiş sayılmaz. İlk hafta, envanterde gözden kaçan şeylerin ortaya çıktığı haftadır. Dört başlığı düzenli takip edin.

Hata kayıtları. Yeni sunucuda daha önce görmediğiniz hatalar birikiyorsa, genellikle eksik bir PHP eklentisi ya da yanlış dosya izni söz konusudur:

tail -n 100 /var/log/nginx/error.log
journalctl -u php8.3-fpm --since "1 hour ago" --no-pager
grep -i 'error\|denied\|permission' /var/log/syslog | tail -30

Zamanlanmış görevler. Cron'lar günlük, haftalık ve aylık olabilir; haftalık bir görev, geçişten altı gün sonra ilk kez çalışır. Her görevin gerçekten koştuğunu çıktısından doğrulayın:

grep CRON /var/log/syslog | tail -30

Yedekleme. Taşımadan sonra en sık unutulan şey budur: eski sunucudaki yedekleme betiği yeni makinede kurulmamış ya da hedef dizini yanlış olur. Yeni sunucuda bir yedek alın ve geri yükleyebildiğinizi test edin. Alınamadığı fark edilmemiş bir yedek, hiç yedek almamakla aynı şeydir.

Kaynak kullanımı. Yeni makine eskisinden farklı bir donanım profilinde olabilir. Bir hafta boyunca bellek ve disk kullanımını izleyin; özellikle takas alanı (swap) kullanımı beklenmedik biçimde artıyorsa bellek yetersizdir.

free -h
df -h
uptime

Bu dört kontrolü ilk hafta her gün, ikinci hafta iki günde bir yapın. Sonrasında bir izleme aracı kurup elle takibi bırakabilirsiniz.

Eski Sunucuyu Ne Zaman Kapatabilirsiniz?#

"DNS yayıldı" hissiyle karar vermeyin; ölçün. Eski sunucunun erişim kayıtlarına hâlâ istek düşüyorsa, birileri oraya gitmeye devam ediyor demektir:

# Son 200 isteği kaç farklı IP yaptı
tail -n 200 /var/log/nginx/access.log | awk '{print $1}' | sort -u | wc -l

# Canlı izleme
tail -f /var/log/nginx/access.log

Bot ve tarama trafiğini gerçek ziyaretçiden ayırt etmek için istek yollarına bakın: /wp-login.php ve /.env denemeleri her sunucuya gelir, bunlar sinyal değildir. Anlamlı olan, gerçek sayfalarınıza gelen istekler ve özellikle oturum açmış kullanıcıların POST istekleridir.

Eski sunucuyu kapatma kriteri şudur: 48 saat boyunca eski makineye tek bir anlamlı istek düşmemesi ve yedeklerinizin yeni sunucuda düzenli olarak alındığının doğrulanması. Bu şart sağlandıktan sonra eskisini önce kapatın (silmeyin), bir hafta bekleyin, sonra iptal edin. Kapatmak yerine hemen silmek, üç gün sonra fark edilen küçük bir eksiği geri almanın tek yolunu ortadan kaldırır.

Geçişten sonra bazı ziyaretçilerin hâlâ eski sunucuyu görmesi normaldir ve genellikle önbellek kaynaklıdır; belirtiler ve çözümleri için DNS değişti ama site eski sunucuda açılıyor yazısı doğrudan bu duruma odaklanıyor. Taşıma sırasında kesinti olup olmayacağı sorusunun genel cevabını ise site taşırken kesinti olur mu yazısında bulabilirsiniz.

Sıkça Sorulan Sorular#

Taşıma sırasında sitem ne kadar süre kapalı kalır?#

Planı uyguladığınızda gerçek kesinti, yazmayı durdurduğunuz an ile yeni sunucuyu açtığınız an arasındaki süredir; bu genellikle 5-15 dakikadır. Ziyaretçilerin bir kısmı DNS önbelleği yüzünden bu süre boyunca eski sunucuyu görmeye devam eder, ancak eski sunucu ayakta olduğu için onlar için de sayfa açılır. Sitenin tamamen erişilemez olduğu bir pencere oluşmaz.

İki sunucuyu aynı anda çalıştırmak veri tutarsızlığı yaratmaz mı?#

Yaratır — bu yüzden geçiş anında eski sunucuda yazma işlemlerini durdurmak gerekir. Bakım moduna almak ya da uygulamayı salt okunur çalıştırmak, DNS önbelleği yüzünden eski sunucuya düşen ziyaretçilerin oraya yeni sipariş veya yorum yazmasını engeller. Aksi hâlde o kayıtlar yeni sunucudaki veritabanında bulunmaz.

Kök dizinin tamamını rsync ile kopyalasam olmaz mı?#

Olmaz. /proc, /sys, /dev ve /run dizinleri çekirdek tarafından çalışma anında üretilir; kopyalanmaları hem anlamsızdır hem de hedef sistemi bozabilir. Ayrıca farklı donanım ve çekirdek sürümüne sahip bir makineye tüm sistem dosyalarını kopyalamak, açılış sorunlarına yol açar. Doğru yaklaşım işletim sistemini temiz kurup yalnızca veri ve yapılandırmayı taşımaktır.

Veritabanı çok büyük, mysqldump saatler sürüyor. Ne yapmalıyım?#

Önce üç gün öncesinden tam bir kopya alın ve yeni sunucuya yükleyin. Geçiş anında ise yalnızca değişen veriyi taşımak için ikili günlük (binary log) tabanlı çoğaltma kurun; eski sunucu ana, yenisi kopya olarak çalışsın. Bu kurulum daha karmaşıktır ama yüz gigabaytın üzerindeki veritabanlarında kesintiyi dakikalar seviyesinde tutmanın tek pratik yoludur.

TTL'i düşürmeyi unuttum, geçiş yaptım. Ne olur?#

Bir şey bozulmaz, sadece geçiş yavaşlar. Eski TTL süresi boyunca (çoğunlukla 4-24 saat) ziyaretçilerin bir kısmı eski sunucuya gitmeye devam eder. Bu süre içinde eski sunucuyu kesinlikle kapatmayın ve mümkünse orada yazma işlemlerini durdurun. Süre dolduğunda trafik kendiliğinden yeni sunucuya kayar.

Taşıma sonrası e-postalarım spam klasörüne düşmeye başladı, neden?#

Yeni IP'nin itibar geçmişi yoktur ve büyük ihtimalle ters DNS (PTR) kaydı tanımlı değildir. Sağlayıcınızdan yeni IP için PTR kaydını posta sunucunuzun adına ayarlamasını isteyin, SPF kaydınızdaki IP'yi güncelleyin ve DKIM anahtarını yeni sunucuya taşıdığınızdan emin olun. Üçü tamamlandıktan sonra gönderim hacmini birkaç gün içinde kademeli olarak artırın.