Rsync ile Sunucular Arası Veri Senkronizasyonu Rehberi

Rsync ile sunucular arası veri senkronizasyonu, özellikle web uygulamaları, yedek (backup) süreçleri ve dosya tabanlı veri taşımada net bir avantaj sağlar. Ama doğru komutu ve doğru ayarları seçmezseniz bant genişliği, disk kullanımı ve beklenmeyen izin (permission) sorunları maliyete dönüşür. Bu rehberde rsync ile senkronizasyonu; SSH üzerinden güvenli aktarım, performans parametreleri, dizin/izin stratejileri ve senaryo bazlı komutlarla adım adım kuracaksınız.

Rsync neyi çözer? (Senaryo bazlı net faydalar)

Rsync, iki konum (kaynak/hedef) arasındaki farkları belirleyip sadece değişen kısımları aktarır. Bu sayede “her seferinde tüm dosyaları kopyala” yaklaşımına kıyasla aktarım süresi ve efor ciddi düşer.

Aşağıdaki senaryolarda rsync özellikle güçlüdür:

• Web dosyalarını (ör. public_html, wp-content, statik varlıklar) staging’den production’a taşımak
• Uygulama veri dizinlerinde (ör. yüklenen dosyalar) düzenli güncel yedek almak
• Birden fazla VDS/VPS üzerinde aynı içerik ağacını korumak (mirror)
• Veri migrasyonu: “dosyaları kopyala” yerine “farkları senkronize et”

Not: Rsync, veriyi karşıya taşırken fark hesabı yaptığı için ilk çalıştırma daha uzun olabilir; sonraki çalıştırmalar fark az oldukça hızlanır.

Rsync güvenlik modeli

Rsync tek başına bir dosya kopyalama aracıdır; güvenlik için genelde şu kombinasyon tercih edilir: - Aktarım katmanı: SSH (Secure Shell) - Kimlik doğrulama: SSH anahtarı (key) veya kullanıcı/şifre - Yetki: hedef dizinde doğru kullanıcı sahipliği

Temel rsync mantığı: kaynak/hedef ve davranış farkı

Rsync komutlarında kritik noktalar şunlardır:

• Kaynak ve hedef dizinleri doğru biçimde yazılmalı
• Dizinin sonuna / eklemek veya eklememek davranışı değiştirir
• İzin (permission) ve sahiplik (owner/group) senkronizasyonu ayrıca ayarlanır

/ konusu (en çok hata burada olur)

Aşağıdaki iki kullanım farklı sonuç üretir:

• rsync -a kaynak/ hedef/ → kaynak dizininin içeriğini hedefe kopyalar
• rsync -a kaynak hedef/ → kaynak dizinini hedefin altında ayrı bir klasör olarak kopyalayabilir

Bu fark, özellikle WordPress gibi klasör yapılarında “dosya var ama uygulama çalışmıyor” tipinde sorunlara yol açabilir.

Üretimde işe yarayan temel komut seti

Aşağıdaki komutlar, çoğu hosting/VDS senaryosunda sağlam başlangıç noktasıdır. Senaryonuza göre küçük ayarlar yapın.

1) SSH üzerinden tek yönlü senkronizasyon

rsync -avz --delete -e ssh /var/www/app/ kullanici@hedef-sunucu:/var/www/app/

Parametre anlamları: - -a (archive): izin, zaman damgası ve dizin yapısını korur (pratikte çok kullanışlı) - -v (verbose): detay görürsünüz - -z (compress): ağ üzerinden sıkıştırma - --delete: hedefte olup kaynakta olmayanları siler (ayna/senaryoda aynalama amaçlı) - -e ssh: aktarımı SSH ile yapar

--delete güçlü bir parametredir. Yanlış kullanılırsa hedefte beklenmedik silmeler olur. İlk denemelerde bunu kapatıp test edin.

2) İlk deneme için “güvenli test modu”

Gerçek kopyalama yapmadan ne değişeceğini görürsünüz:

rsync -avzn --delete -e ssh --dry-run /var/www/app/ kullanici@hedef:/var/www/app/

• -n veya --dry-run: sadece simülasyon
• -z eklemek performansı etkiler; testte fark etmez ama tutarlılık için bırakılabilir

3) Hedefte klasör yapısını koruma ve hata yakalama

Özellikle cron ile otomatikleştirirken hata takibi önemlidir:

rsync -avz --partial --stats -e ssh /var/www/app/ kullanici@hedef:/var/www/app/

• --partial: aktarım yarıda kaldığında kısmi dosyaları saklar (tekrar denemede faydalı)
• --stats: özet istatistik

Performans ayarları: hız nerede kazanılır?

Rsync performansı üç yerde belirginleşir:

1. Değişen dosya sayısı (fark az ise çok hızlı olur)
2. Ağ ve sıkıştırma stratejisi
3. Dosya küçükse meta/data okuma maliyeti

Aşağıdaki parametreler performans/tutarlılık dengesini sağlar.

Compress ( -z ) ne zaman avantajlı?

• Bant genişliği düşük veya gecikme yüksek bağlantılarda -z çoğu zaman fayda verir
• Sunucular aynı LAN/çok hızlı hat üzerindeyse -z CPU’yu zorlayıp kazancı azaltabilir

Dosya değişimini doğru algılama: zaman damgası vs boyut

Rsync varsayılan olarak zaman damgası ve boyuta bakarak farkı belirler. Dosyalar sık değişip zaman damgası korunmuyorsa, daha fazla aktarım yapılabilir.

Eğer uyguladığınız süreçte “içerik değişti ama zaman damgası aynı kaldı” gibi durumlar oluyorsa, kontrol etmeniz gerekir. Bu noktada md5/sha gibi içerik tabanlı doğrulama seçenekleri (ör. --checksum) ek maliyet getirebilir; sadece gerçekten gereken senaryolarda kullanın.

İzin (permission), sahiplik ve hatalardan kaçınma

Senkronizasyon sadece dosyayı kopyalamak değildir; doğru izinler yoksa web uygulamanız hata verir.

Web uygulamaları için pratik kural

• Kaynakta çalışan kullanıcı (ör. www-data, nginx, uygulama kullanıcısı) hedefte de aynı olmalı
• Dizine yazılabilirlik gerekir (ör. upload klasörleri)

-a neyi korur?

-a (archive) şunları hedefler: - owner/group/permissions (izinler) ve zaman damgaları

Fakat owner/group eşleşmeyebilir. Bu durumda hedef kullanıcı kimliğine göre uyarlama yapın.

Senaryo: Upload dizini ayrı kalsın

Örneğin statik dosyaları bir kez deploy edip, sık değişen upload’ları ayrıca senkronize edebilirsiniz.

• Statik: public/ (daha seyrek değişir)
• Dinamik: storage/uploads/ (daha sık değişir)

Bu bölme, gereksiz dosya aktarımını azaltır.

Senaryo tabloları: hangi rsync parametreleri?

Aşağıdaki tablolar, doğru parametre seçimi için pratik “reçete” sağlar.

Uygulama örnekleri: 4 tipik kullanım

1) WordPress dosyaları + upload ayrımı

WordPress’te çekirdek dosyaları genelde daha stabil; upload’lar daha sık değişir.

Statik/çekirdek dosyalar (silme dahil aynalama):

rsync -avz --delete -e ssh /var/www/html/ kullanici@hedef:/var/www/html/

Sadece upload klasörü (silme yapmadan):

rsync -avz -e ssh /var/www/html/wp-content/uploads/ kullanici@hedef:/var/www/html/wp-content/uploads/

Bu yaklaşım, upload’lar üzerinden yanlış silme riskini azaltır.

2) Veri klasörü senkronu (ör. uygulama data)

Eğer uygulama data klasöründe dosyalar hem ekleniyor hem düzenleniyorsa:

rsync -avz --delete -e ssh /srv/app-data/ kullanici@hedef:/srv/app-data/

İlk çalıştırmadan önce --dry-run ile farkı doğrulayın.

3) Cron ile düzenli senkron (log al)

Örnek cron mantığı (komut satırı mantığı):

• Günlük çalıştırma
• Log dosyasına istatistik yazdırma

Komut:

rsync -avz --stats --delete -e ssh /var/www/app/ kullanici@hedef:/var/www/app/ >> /var/log/rsync-deploy.log 2>&1

4) Bant kullanımını sınırlamak

Yoğun saatlerde ağ tıkanmasını azaltmak için hız limitleri kullanılır. Örneğin:

rsync -avz --bwlimit=50M -e ssh /var/www/app/ kullanici@hedef:/var/www/app/

• --bwlimit birim olarak K/M/G formatlarını destekler

Doğrulama: “dosyalar gitti mi?” kontrolü

Senkronizasyon sonrası kontrol, beklenmeyen hataları erken yakalar.

1) Dry-run ile farkın sıfır olduğunu doğrula

Senkron sonrası tekrar dry-run yapın:

rsync -avzn --dry-run -e ssh /var/www/app/ kullanici@hedef:/var/www/app/

• Çıktı “fark yok” yönünde olmalı

2) İstatistikle anormallikleri yakala

--stats sonrası: - Beklenenden fazla dosya aktarımı - Beklenenden düşük/büyük bayt aktarımı

Bu sinyalleri not edin.

Güvenlik kontrol listesi (SSH ve yetki)

Rsync ile veri taşırken şu maddeler operasyonel olarak kritik:

• SSH anahtarı kullanın; şifreli oturumdan kaçının
• Kullanıcıya sadece gerekli dizinlerde yetki verin
• Hedef dizinde yanlış --delete kullanımını önlemek için ilk etapta --dry-run yapın
• Dosya izinlerini uygulamanın beklediği şekilde ayarlayın
• Log dosyalarında hataları izleyin

Ek katman: Zamanlı anahtar rotasyonu

Kurumsal ortamda, SSH anahtarı rotasyonu ve erişim süreleri için ayrı süreç yürütülür. Rsync komutlarında güvenli aktarım için zaten SSH kullanılır; anahtar yönetimi de aynı güvenlik seviyesinde olmalıdır.

NetKıyas perspektifiyle seçim: hangi altyapıda rsync daha verimli?

Rsync komutu aynı olsa da altyapı performansı değişir. Burada pratik karar çerçevesi:

• Aynı bölgede (region) düşük gecikme: -z ile değil, daha çok ağ kalitesiyle hızlanır
• Fark azsa: VDS/VPS fark etmeksizin rsync’in avantajı artar
• Dosya küçükse: CPU ve disk I/O (I/O performansı) öne çıkar; sadece ağ hızı yeterli olmaz
• Günlük deploy: staging/production ayrımında rsync, tam görüntü (full image) yerine hızlı fark güncellemesi sağlar

Sonuç: 1 saat içinde güvenli senkron başlatın

İlk adım olarak şu sıralamayı uygulayın: (1) Hedefe gerçek silme içermeyen komutla senkronu başlatın, (2) sonra --dry-run ile farkın doğru göründüğünü teyit edin, (3) en son ihtiyaç varsa --delete ile aynalama moduna geçin, (4) izin ve sahiplik (owner/group) uyumunu kontrol edin.

Aksiyona dönüştürmek için elinizdeki iki sunucu arasında önce kuru bir test senaryosu kurun: --dry-run ile beklediğiniz fark çıktısını görün. Sonraki adımda aynı komutu cron’a alarak düzenli senkronizasyonu loglu şekilde çalıştırın. Bu yaklaşım, rsync’i “hızlı dosya kopyalama” olmaktan çıkarıp kontrollü bir dağıtım ve yedekleme aracı haline getirir.