Disk Klonlama ile Sunucu Göçü: Adım Adım Rehber

Sunucu taşıma işlemleri, sysadmin’lerin en çok stres yaşadığı anların başında gelir. “Ya bir şeyler ters giderse?”, “Servisler ne kadar süre aksayacak?”, “Tüm konfigürasyonu elle yeniden kurmak zorunda mı kalacağım?” gibi sorular kafanızı sürekli meşgul eder. İşte bu yüzden disk klonlama yöntemi, production ortamında sunucu göçü için en güvenilir araçlardan biri haline gelmiştir. Fiziksel diskten fiziksel diske, fiziksel diskten sanal makineye ya da bulut ortamına geçişlerde klonlama yaklaşımı hem zaman kazandırır hem de insan hatasını minimuma indirir. Bu yazıda, gerçek dünya senaryolarına dayanan, adım adım bir disk klonlama ile sunucu göçü sürecini ele alacağız.

Disk Klonlama Nedir ve Neden Kullanılır

Disk klonlama, bir diskin tüm içeriğini, boot sektörü, partition tablosu, dosya sistemi ve verilerle birlikte birebir kopyalayan bir işlemdir. Klasik dosya kopyalamanın aksine, klonlama işleminde işletim sistemi de dahil olmak üzere her şey aktarılır. Bu nedenle yeni sunucu çalışmaya başladığında, sanki eski sunucunun aynısıyla karşı karşıyaymış gibi hissedersiniz.

Sunucu göçünde disk klonlamanın öne çıktığı başlıca durumlar şunlardır:

• Donanım yenileme: Eski fiziksel sunucuyu daha güçlü donanıma taşıma
• Veri merkezi değişimi: Bir lokasyondan diğerine sunucu göçü
• Bare-metal’dan sanallaştırmaya geçiş: Fiziksel makineyi VMware, KVM veya Proxmox üzerine alma
• Bulut göçü: On-premise sunucuyu AWS, Azure veya GCP’ye taşıma
• Disk değişimi: Eskiyen veya arızalanan diski yenisiyle değiştirme

Hazırlık Aşaması

Klonlama işlemine geçmeden önce doğru hazırlık yapmak, sonradan karşılaşabileceğiniz onlarca sorunu önler.

Kaynak Sistemin Envanterini Çıkarın

İlk adım olarak kaynak sunucunun tam bir resmini çıkarmanız gerekir. Hangi servislerin çalıştığını, disk yapısını ve ağ konfigürasyonunu not alın.

# Disk ve partition yapısını görüntüle
lsblk -f
fdisk -l
df -hT

# Çalışan servisleri listele
systemctl list-units --type=service --state=running

# Ağ konfigürasyonunu kaydet
ip addr show
ip route show
cat /etc/hosts
cat /etc/resolv.conf

# Kritik paketleri listele
dpkg --get-selections > /tmp/paket-listesi.txt   # Debian/Ubuntu
rpm -qa > /tmp/paket-listesi.txt                  # RHEL/CentOS

Bu bilgiler elinizdeyken, hedef sistemi hazırlamak çok daha kolay olacaktır. Ayrıca bir şeyler ters giderse neyin eksik olduğunu anlamak için bu çıktılara dönersiniz.

Hedef Diskin Kapasitesini Doğrulayın

Klonlama işleminin başarılı olabilmesi için hedef disk, kaynak diskle aynı boyutta ya da daha büyük olmalıdır. Daha küçük bir diske klonlama yapmak istiyorsanız, önce kaynak diskteki kullanılan alanın hedef diske sığıp sığmadığını kontrol etmeniz gerekir; bu senaryo ayrıca özel araçlar gerektirir.

# Kaynak disk boyutunu kontrol et
fdisk -l /dev/sda | grep "Disk /dev/sda"
# ya da
lsblk -d -o NAME,SIZE /dev/sda

Yedek Aldığınızdan Emin Olun

Bu adımı atlamamanızı şiddetle tavsiye ederim. Klonlama işlemi güvenli olsa da production ortamında her zaman ek bir güvenlik ağına ihtiyaç duyarsınız. Rsync ile kritik verilerinizi farklı bir konuma kopyalamak iyi bir pratiktir.

# Kritik dizinleri uzak sunucuya yedekle
rsync -avz --progress /etc/ yedek-sunucu:/yedek/etc/
rsync -avz --progress /var/www/ yedek-sunucu:/yedek/var-www/
rsync -avz --progress /home/ yedek-sunucu:/yedek/home/

dd ile Disk Klonlama

dd, Linux dünyasının en eski ve en güvenilir disk kopyalama aracıdır. Basit ama güçlüdür. Büyük diskler için yavaş kalabilse de kesinlikle işe yarar.

Aynı Boyuttaki Diskler Arası Klonlama

Her iki disk de aynı boyuttaysa işlem oldukça basittir:

# Kaynak /dev/sda, hedef /dev/sdb
# UYARI: Hedef diskteki tüm veriler silinir!
dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync status=progress

Buradaki parametreleri açıklayalım:

• if=/dev/sda: Input file, kaynak disk
• of=/dev/sdb: Output file, hedef disk
• bs=64K: Block size, performans için 64K iyi bir değerdir
• conv=noerror: Okuma hatası olduğunda devam et
• conv=sync: Hatalı bloklara sıfır yaz
• status=progress: İlerlemeyi göster

Ağ Üzerinden dd ile Klonlama

Fiziksel erişim yoksa ya da diskleri aynı anda kullanmak zorundaysanız, ağ üzerinden klonlama yapabilirsiniz.

# Hedef sunucuda netcat ile dinlemeye geç
nc -l -p 9999 | dd of=/dev/sdb bs=64K status=progress

# Kaynak sunucuda veriyi gönder
dd if=/dev/sda bs=64K status=progress | nc hedef-sunucu-ip 9999

Güvenlik açısından bu yöntemi yalnızca güvenilir bir iç ağda kullanın. Prodüksiyonda şifreli transfer için SSH tüneli kullanmak daha akıllıca olur:

# SSH üzerinden disk klonlama
dd if=/dev/sda bs=64K status=progress | ssh root@hedef-sunucu "dd of=/dev/sdb bs=64K status=progress"

Clonezilla ile Klonlama

Gerçek dünya senaryolarında dd yetersiz kalabileceği durumlarda Clonezilla devreye girer. Clonezilla, hem GUI hem de CLI sunuyor, sıkıştırma desteği var ve sadece kullanılan blokları kopyalayarak işlemi hızlandırıyor.

Clonezilla Kurulumu

Clonezilla’yı genellikle live USB olarak kullanırsınız. Ancak sunucu üzerinde doğrudan da çalıştırabilirsiniz:

# Debian/Ubuntu
apt-get install clonezilla

# Arch Linux
pacman -S clonezilla

Disk Image Alma ve Geri Yükleme

# /dev/sda diskinin image'ini /mnt/backup dizinine kaydet
clonezilla -d /dev/sda -r /mnt/backup/sunucu-yedek -c -q2 -j2 -z1p -i 0

# Kaydedilen image'i /dev/sdb diskine geri yükle
clonezilla -d /dev/sdb -r /mnt/backup/sunucu-yedek -e1 auto -e2 -r -j2 -p true

Partclone ile Akıllı Klonlama

Partclone, sadece kullanılan blokları kopyaladığı için dd’ye göre çok daha hızlıdır. Özellikle büyük disklerde ya da doluluk oranı düşük sistemlerde fark devasa olabilir. 2 TB’lık bir diskin yalnızca 200 GB’ı kullanılıyorsa, partclone sadece o 200 GB’ı kopyalar.

# ext4 partition'ını klonla ve sıkıştır
partclone.ext4 -c -s /dev/sda1 | gzip -c > /mnt/backup/sda1.img.gz

# Image'i geri yükle
gzip -dc /mnt/backup/sda1.img.gz | partclone.ext4 -r -o /dev/sdb1

# NTFS partition için (Windows sunucular)
partclone.ntfs -c -s /dev/sda1 | gzip -c > /mnt/backup/sda1-ntfs.img.gz

LVM Ortamında Klonlama

Çoğu modern Linux sunucu LVM (Logical Volume Manager) kullanır. Bu durumda klonlama süreci biraz farklılaşır ama esasen daha esnektir.

# Mevcut LVM yapısını incele
pvdisplay
vgdisplay
lvdisplay

# LVM snapshot al (kaynak disk çalışırken tutarlı kopyalama için)
lvcreate -L 10G -s -n data-snapshot /dev/vg0/data

# Snapshot'tan klonlama yap
dd if=/dev/vg0/data-snapshot of=/dev/sdb1 bs=64K status=progress

# ya da partclone ile
partclone.ext4 -c -s /dev/vg0/data-snapshot | gzip -c > /mnt/backup/data.img.gz

# Snapshot'ı kaldır
lvremove /dev/vg0/data-snapshot

LVM snapshot kullanmanın en büyük avantajı, sistemi durdurmadan tutarlı bir kopya alabilmektir. Snapshot anındaki disk durumunu “dondurur” ve siz kopyalarken sistemin çalışmaya devam etmesine olanak tanır.

Çalışan Sistemden Rsync ile Canlı Göç

Production ortamında downtime’ı minimuma indirmek istiyorsanız, rsync tabanlı canlı göç yöntemi en pratik çözümdür. Bu yöntemde önce büyük veri transferini yüksek hızda yaparsınız, ardından kısa bir downtime ile son senkronizasyonu tamamlarsınız.

# 1. Aşama: İlk büyük senkronizasyon (sistem çalışırken)
rsync -avzP --delete 
  --exclude=/proc 
  --exclude=/sys 
  --exclude=/dev 
  --exclude=/run 
  --exclude=/tmp 
  --exclude=/mnt 
  / root@hedef-sunucu:/

# 2. Aşama: Servisleri durdur ve son senkronizasyonu yap
systemctl stop nginx mysql  # kendi servislerinizi durdurun

rsync -avzP --delete 
  --exclude=/proc 
  --exclude=/sys 
  --exclude=/dev 
  --exclude=/run 
  --exclude=/tmp 
  --exclude=/mnt 
  / root@hedef-sunucu:/

Gerçek bir senaryoyu paylaşayım: Bir müşterimizin e-ticaret sitesini barındıran 1.2 TB’lık bir sunucuyu yeni donanıma taşımamız gerekiyordu. İlk rsync aşaması 6 saatte tamamlandı. Son senkronizasyon (sadece değişen dosyalar) ise 8 dakika sürdü. Toplam downtime 8 dakikaydı. Klonlama yöntemiyle 6 saat downtime yaşayabilirdik.

Hedef Sistemde Boot Ayarları

Klonlama tamamlandıktan sonra hedef sistemin boot edebilmesi için bazı ayarlamaların yapılması gerekir. Bu adım çoğu zaman gözden kaçar ve sonuç olarak “neden açılmıyor?” sorusuyla karşılaşırsınız.

# Hedef diski mount et
mount /dev/sdb1 /mnt
mount /dev/sdb2 /mnt/boot  # eğer ayrı bir /boot partition varsa

# Chroot ortamına gir
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

# GRUB'u yeniden yükle
grub-install /dev/sdb
update-grub

# /etc/fstab'ı kontrol et ve UUID'leri güncelle
blkid /dev/sdb1  # Yeni diskin UUID'sini al
nano /etc/fstab  # UUID'leri güncelle

UUID değiştirme işlemi kritik öneme sahiptir. Klonlanan disk, kaynak diskle aynı UUID’ye sahip olacaktır. İkisi aynı anda sisteme bağlıysa çakışma yaşanır.

# Yeni UUID ata
tune2fs -U random /dev/sdb1
tune2fs -U random /dev/sdb2

# Yeni UUID'leri öğren
blkid

# fstab'ı yeni UUID'lerle güncelle
# Örnek fstab satırı:
# UUID=yeni-uuid-buraya / ext4 defaults 0 1

Ağ Konfigürasyonunu Güncelleme

Yeni sunucuya geçtikten sonra ağ ayarlarını güncellemeniz gerekir. Klonlanan sistemin eski IP adresi ve hostname’i olacaktır.

# Hostname güncelle
hostnamectl set-hostname yeni-sunucu-adi

# /etc/hosts güncelle
nano /etc/hosts

# Networkd veya network-scripts ile IP güncelle
# Ubuntu 20.04+ için netplan
nano /etc/netplan/00-installer-config.yaml

# Değişikliği uygula
netplan apply

# CentOS/RHEL için
nano /etc/sysconfig/network-scripts/ifcfg-eth0
systemctl restart NetworkManager

Klonlama Sonrası Doğrulama

Göçün başarılı olup olmadığını doğrulamak için sistematik bir kontrol listesi kullanın.

# Tüm servislerin çalışıp çalışmadığını kontrol et
systemctl --failed

# Disk montajlarını doğrula
df -hT
mount | grep -v tmpfs

# Log dosyalarını incele (hata var mı?)
journalctl -p err -b

# Kritik portların açık olduğunu kontrol et
ss -tulpn

# Veritabanı tutarlılık kontrolü (MySQL/MariaDB için)
mysqlcheck --all-databases -u root -p

# Web sunucusu konfigürasyon testleri
nginx -t
apache2ctl configtest

Bir senaryo daha: Geçen yıl bir fintech firmasının PostgreSQL sunucusunu klonladık. Tüm adımları doğru yapmıştık ama veritabanı servisine bağlanılamıyordu. Sebebi, pg_hba.conf içindeki eski sunucu IP’leriydi. Bu yüzden uygulama konfigürasyonlarınızı ve erişim kontrol listelerinizi de gözden geçirmenizi tavsiye ederim.

SSL Sertifikalarını ve Lisansları Kontrol Edin

Bazı yazılımlar, donanım bilgisine bağlı lisanslar kullanır. Disk klonladıktan sonra bu lisansların geçerliliğini kontrol etmek gerekir.

# Let's Encrypt sertifikatlarını listele
certbot certificates

# Sertifika yenileme testi
certbot renew --dry-run

# SSH host key'lerini yenile (güvenlik için önemli!)
rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
# ya da
ssh-keygen -A
systemctl restart sshd

SSH host key’lerini yenilemek özellikle önemlidir. İki sunucunun aynı host key’e sahip olması, “man-in-the-middle” saldırılarına kapı aralayabilir.

Performans Testi Yapın

Yeni sunucuyu production’a almadan önce performansını test etmek iyi bir pratiktir.

# Disk I/O testi
fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite 
    --bs=4k --direct=0 --size=512m --numjobs=4 --runtime=30 
    --group_reporting

# Temel ağ bant genişliği testi (iperf3)
# Hedef sunucuda
iperf3 -s

# Kaynak sunucuda
iperf3 -c hedef-sunucu-ip -t 30

# Bellek testi
memtester 1G 1

Rollback Planı Hazırlayın

Her göç planında bir geri dönüş senaryosu olmalıdır. Eski sunucuyu hemen kapatmayın; en az 48-72 saat ayakta tutun.

Yük dengeleyici varsa, trafiği yeniden eski sunucuya yönlendirmek birkaç dakika sürer. DNS tabanlı geçişlerde ise TTL değerini önceden düşürmek (örneğin 300 saniye) hızlı geri dönüş imkânı sağlar.

# DNS TTL'i geçiş öncesi düşür (24 saat önceden)
# Bind9 zone dosyasında
# $TTL 86400 yerine $TTL 300 yap

# Geçiş sonrası eski TTL'e geri dön
# $TTL 86400

Sonuç

Disk klonlama ile sunucu göçü, doğru araçlar ve sistematik bir yaklaşımla son derece güvenilir bir süreçtir. Yazı boyunca ele aldığımız adımları özetleyecek olursak: hazırlık aşamasında sistemi iyi tanımak, doğru klonlama aracını seçmek (dd, Clonezilla, partclone), LVM ortamlarında snapshot kullanarak tutarlılığı sağlamak, klonlama sonrasında UUID ve boot ayarlarını güncellemek, ağ konfigürasyonunu ve SSH anahtarlarını yenilemek ve son olarak kapsamlı bir doğrulama sürecinden geçirmek.

Downtime minimizasyonu kritikse, rsync tabanlı canlı göç yöntemi her zaman ön planda tutulmalıdır. Büyük ve karmaşık ortamlarda ise Clonezilla ya da partclone kullanmak hem zaman tasarrufu hem de veri bütünlüğü açısından daha akıllıca bir seçimdir.

En önemlisi, rollback planınızı her zaman hazır tutun. Prodüksiyonda “geri dönüş yok” diye bir şey yoktur. Her göç senaryosunu, başarı kadar başarısızlık ihtimalini de göz önünde bulundurarak planlayın. Böylece hem kendiniz hem de ekibiniz için daha az stresli, daha öngörülebilir göç süreçleri yaşarsınız.