rsync komutunu çalıştırdınız, ilerleme çubuğu %40'ta kaldı ve on dakika sonra SSH bağlantısı kesildi. Şimdi yarım aktarılmış dosyaları silip silmeyeceğinizi yoksa kaldığı yerden devam mı edeceğinizi bilmiyorsunuz. İşte tam da bu noktada yanlış kararlar başlar. Sunucular arası transfer, komutu vermeden önce veri hacmini, bant genişliğini ve doğrulama yöntemini belirlediğinizde doğru yapılır.
Önce hacmi ve veri türünü ölçün, sonra aracı seçin
Her şeyden önce kaynakta şunu çalıştırın:
du -sh /var/www /home /var/lib/mysql
df -h
df -idf -i çıktısını hafife almayın. Kaynakta inode doluysa, çok sayıda küçük dosyanın transferi hedefte No space left on device hatasıyla durabilir, oysa df -h hâlâ boş alan gösteriyordur. Bu çıktıların nasıl okunacağına dair daha fazla ayrıntı Linux'ta disk komutları: alan, inode ve disk sağlığı bölümünde yer alıyor.
Araç seçimi için şu tabloyu göz önünde bulundurun:
| Veri hacmi | Önerilen araç | Neden |
|---|---|---|
| 1 gigabayttan az | scp veya rsync | Kurulum hızı optimizasyondan daha önemlidir |
| 1 ila 500 gigabayt | SSH üzerinden rsync | Sürdürülebilir, tekrarlanabilir, fazla dosyalar silinebilir |
| 500 gigabayttan fazla | rsync veya tar + netcat | İç ağda şifreleme yükünü azaltır |
| Aktif veritabanı | dump + dump dosyası transferi | Ham MySQL dosyası kopyalamak genellikle bozulmaya yol açar |
Bir veri merkezinin iç ağında 1 gigabit/saniye bant genişliğiyle sunucular arası transfer, gerçekte yaklaşık 100 ila 110 megabayt/saniye hızla veri taşır. Aynı bağlantıda SSH şifrelemesi de etkinse bu sayı 60 ila 80 megabayt/saniyeye düşer. 200 gigabayt veri için bu fark yaklaşık 40 dakikalık bir zaman farkı demektir.
Sunucular arası transfer için doğru rsync komutu
Bu komutu kaynaktan değil, hedef sunucudan çalıştırın:
rsync -avzP --partial --append-verify \
-e "ssh -p 22 -o ServerAliveInterval=30" \
root@192.0.2.10:/var/www/ /var/www/Pratikte fark yaratan birkaç nokta:
-P,--partialve--progressseçeneklerinin birleşimidir; yarım kalan dosyayı saklar, böylece sonraki çalıştırma kaldığı yerden devam eder.--append-verifyyalnızca kaynak dosyaya sadece ekleme yapıldığında anlamlıdır. Ortası değişen dosyalar için yanlış sonuç verir.ServerAliveInterval=30, uzun transferlerde bağlantının kesilmesini önler.- Kaynak yolun sonundaki eğik çizgi önemlidir.
/var/www/klasörün içeriğini kopyalar,/var/wwwise klasörün kendisini.
Transfer kesilirse aynı komutu yeniden çalıştırın. rsync aktarılmış dosyaları checksum ile karşılaştırır ve yalnızca farkları gönderir. Bu özellik, sunucular arası transfer için rsync'in seçilmesinin ana nedenidir.
İşte burada hata yapıyorlar
Yaygın hata, kullanıcının ilk çalıştırmada --delete eklemesidir. Hedef yol yanlış yazılmışsa rsync o klasörün içeriğini rahatça siler. Belirtisi de açıktır: transfer hatasız tamamlanır, ancak aktarılan veri hacmi beklenenden azdır ve hedef dosyalar kaybolmuştur. --delete seçeneğini yalnızca ikinci veya üçüncü çalıştırmada, o da --dry-run sonrasında ekleyin.
MySQL veritabanını bozulma olmadan transfer etme
Çalışan bir sunucuda /var/lib/mysql dizinini doğrudan kopyalamak neredeyse her zaman bozuk bir veritabanıyla sonuçlanır. Doğru yöntem:
mysqldump --single-transaction --routines --triggers \
--databases shop_db > /tmp/shop_db.sql
gzip /tmp/shop_db.sql
rsync -avzP /tmp/shop_db.sql.gz root@192.0.2.20:/tmp/Ardından hedefte:
gunzip < /tmp/shop_db.sql.gz | mysql
mysql -e "SELECT COUNT(*) FROM shop_db.orders;"--single-transaction seçeneği yalnızca InnoDB üzerinde anlamlıdır. MyISAM tablolarınız varsa veritabanını kilitlemeli veya başka bir yöntem kullanmalısınız. 50 gigabayttan büyük veritabanları için dump alıp tek seferde transfer etmek saatler sürebilir ve hedef disk alanını doldurabilir; bu durumda dump'ı parça parça veya mydumper gibi araçlarla almak daha iyidir.
Doğrulama: çoğu kişinin atladığı iş
Transfer bitti, ama veri sağlam mı? Bunu her iki sunucuda çalıştırın ve çıktıları karşılaştırın:
find /var/www -type f -exec md5sum {} \; | sort -k2 | md5sumHash aynıysa transfer tamamdır. Değilse, rsync -avzP --checksum ile yeniden çalıştırın, böylece yalnızca farklı dosyalar aktarılır. Veritabanı için kayıt sayılarını ve tablo boyutlarını SHOW TABLE STATUS ile karşılaştırın.
Az söylenen bir nokta: Hedef sunucuda Nginx veya PHP-FPM gibi servisler çalışıyorsa, geçici dosyalar veya loglar oluşturabilir ve hash karşılaştırmasını bozabilirler. Doğrulamadan önce hedef servisleri durdurun. Logların nereye yazıldığını Linux log konumları: hangi servis nereye yazıyor? bölümünde görebilirsiniz.
Bulut ve özel sunucular arası transfer
Hedef bir bulut sunucusu ise, genellikle iç ağdan bağlantı mümkündür ve genel IP yerine iç IP kullanabilirsiniz. Bu hem hızı artırır hem de çıkış trafiğini azaltır. Özel sunucu için, her iki sunucu da aynı rafa yerleştirilmişse aynı kural geçerlidir.
Farklı veri merkezleri arasındaki transferde gerçek bant genişliği genellikle nominal bant genişliğinden çok daha düşüktür. Büyük bir transfere başlamadan önce iperf3 ile iki nokta arasındaki gerçek hızı ölçün:
iperf3 -c 192.0.2.20 -t 30Elde edilen sayı saniyede 20 megabayttan düşükse, 100 gigabaytlık transfer bir buçuk saatten fazla sürer. Bu durumda transferden önce sıkıştırma (örneğin metin verileri üzerinde tar czf) süreyi belirgin şekilde kısaltabilir, yeter ki CPU darboğaz olmasın.
Güvenlik duvarını ve portları unutmayın
Transfer Connection refused veya No route to host hatasıyla durursa, muhtemelen hedefte SSH portu kapalıdır veya kaynak güvenlik duvarı çıkışa izin vermiyordur. Komutların hızlı referansı Linux güvenlik duvarı komutları: iptables, nftables ve ufw hızlı referansı bölümünde mevcuttur. Servislerin varsayılan portlarını da Yaygın servis portları referansı bölümünde görebilirsiniz.
Sık sorulan sorular
rsync neden aynı dosyaları yeniden transfer ediyor?
Dosyanın değişiklik zamanı (mtime) veya boyutu değiştiyse rsync onu yeniden gönderir. Bunu önlemek için --checksum seçeneğini kullanın, böylece karşılaştırma zamana göre değil içerik hash'ine göre yapılır. Bu daha fazla CPU tüketir ama sık tekrarlanan transferlerde daha kesindir.
Sunucular arası transfer arka planda çalıştırılabilir mi?
Evet. screen veya tmux ile bir oturum açın ve komutu içinde çalıştırın. SSH kesilirse transfer devam eder. Diğer bir yöntem nohup kullanmaktır, ancak bu durumda ilerleme çıktısını göremezsiniz ve hata ayıklama zorlaşır.
Düşük bant genişliğiyle sunucular arası transfer ne kadar sürer?
Transfer süresi, veri hacminin bağlantının gerçek hızına bölünmesiyle bulunur. 100 megabit/saniyelik bir bağlantıda 100 gigabayt için ideal durumda yaklaşık iki buçuk saat, pratikte ise daha fazla. Her zaman nominal hızı değil, iperf3 ile gerçek hızı ölçün.
Transferden sonra DNS'i ne zaman değiştirmeliyim?
Önce doğrulamayı tamamlayın, sonra DNS kaydını değiştirin. Kaydın TTL değerini değişiklikten en az 24 saat önce 300 saniyeye düşürün, böylece sorun çıkarsa hızlı geri dönüş mümkün olur. Hedef sunucuda systemd'ye bağlı servisleriniz varsa, başlatma sırasını systemd'de unit dosyası: bölümler, yeniden başlatma ve bağımlılık bölümünden inceleyin, böylece DNS değişikliğinden sonra servisler düzgün şekilde ayağa kalksın.
Transferi yeni ve kontrollü bir ortamda yapmak istiyorsanız, uygun bir hedef Linux hosting iyi bir başlangıç noktası olabilir. Ancak bugün yapmanız gereken en önemli şey şudur: Her büyük transferden önce bir kez --dry-run ile çalıştırın ve çıktıyı okuyun. Bu beş saniye, saatlerce süren sıkıntının önüne geçer.