Linux Sunucular Arasında Büyük Veriler rsync ile Nasıl Taşınır?

Büyük ölçekli veri taşıma rehberi: “Flag”lerin anlamı, gözden kaçan kritik “flag”ler ve kopyalamanın eksiksiz tamamlandığını doğrulama yöntemleri. 

İİki Linux sunucusu arasında klasör kopyalamak basit bir iş gibi görünür. Ancak veri boyutu yüzlerce gigabayta ve dosya sayısı milyonlara ulaştığında, bu "basitlik" illüzyonu ortadan kalkar.

Artık kopyalama işlemi standart bir SSH oturumunun süresine sığmaz. Baglantının kesilmesi ihtimali anlık bir aksaklık değil, baştan hesaba katılması gereken bir risk haline gelir. cp -r gibi temel komutlar ise işlemin başarısı hakkında güvenilir bir bilgi vermez. Hatta içerik tabanlı depolama (content-addressable storage) sistemlerinde yarım kalmış bir dosya, hata vermek yerine geçerli bir dosya gibi algılanabilir.

Bu rehber; veri ölçeği büyüdüğünde nelerin değiştiğini, ezbere komut çalıştırmak yerine ihtiyaca uygun bir transfer stratejisinin nasıl kurulacağını ve sonucun hatasız şekilde nasıl doğrulanacağını anlatıyor.

Herhangi bir komut çalıştırmadan önce okunması tavsiye edilir.

Bölüm 1 — Ölçek büyüdüğünde aslında ne değişiyor?

Veri boyutu büyüdükçe dört temel unsur kontrolden çıkar. Bu rehber boyunca alacağımız her karar, aslında bu dört sorundan birini çözmeye dayanır. 

Süre, kendi başına bir başarısızlık sebebine (failure mode) dönüşür.  Saatler süren bir transfer işlemi; SSH oturumunuzdan, VPN bağlantınızdan veya bilgisayarınızın kapağını açık tutma sürenizden daha uzun sürer. Bu noktada soru "İşlem bitecek mi?" olmaktan çıkar; "Bağlantı koptuğunda ne olacak ve sıfırdan başlamadan işleme kaldığım yerden devam edebilecek miyim?" haline gelir. 

Dosya sayısı, dosya boyutundan daha büyük bir maliyet yaratır.  Aynı donanım üzerinde 500 GB veriyi 10 büyük dosya olarak taşımak ile 2 milyon küçük dosya olarak taşımak tamamen farklı iki problemdir. Her küçük dosya sabit bir ek yük (overhead) getirir: Bir stat, bir open, metadata işlemleri ve bir close. Belirli bir dosya sayısından sonra darboğazı bant genişliğiniz (bandwidth-bound) değil, sistem çağrılarınız (syscall-bound) oluşturmaya başlar. Ortalama dosya boyutunuz önemsiz bir detay değil, mimariyi şekillendiren ana girdidir. 

"Düzgün görünüyor" söylemi bir kanıt olmaktan çıkar.  Hedefte 20 dosya olduğunda klasöre göz atıp kontrol edebilirsiniz. Ancak 2 milyon dosya söz konusu olduğunda, sadece dosya sayılarını değil çok daha fazlasını karşılaştıran sistematik bir doğrulama prosedürüne ihtiyacınız vardır. 

Yarım kalan yazma işlemleri (partial writes) görünmez hale gelir. İnsanların en çok hafife aldığı konu bu ve Bölüm3 bunun için ayrıldı.

Bölüm 2 — Neden rsync, neden bariz alternatifler değil?

Önce bunu netleştirmekte fayda var çünkü alternatifler belirli durumlarda gerçekten daha iyi.

Bu son madde, büyük ölçekli veri taşımalarında (migration) rsync’in açık ara öne çıkmasının temel sebebidir. Transferi gerçekleştiren aracın kendisi, işlem bittikten sonra kaynak (source) ve hedef (destination) arasında ne gibi farklar kaldığını da size raporlayabilir. Listedeki başka hiçbir araç bu imkânı sunmaz.

tar | ssh yöntemi ise dürüst bir değerlendirmeyi hak ediyor: Eğer kontrolünüz altındaki bir bakım penceresinde (maintenance window), tek seferde ve devasa miktarda küçük dosyayı taşıyorsanız —ve elinizde bağımsız bir doğrulama yöntemi varsa— bu yaklaşım belirgin şekilde daha hızlı sonuç verebilir.

Ancak kesintisiz devam edebilirlik (resumability) ve güvenilir bir doğrulama süreci (verification) arıyorsanız adresiniz rsync olmalıdır —ki canlı sistem taşımalarında (production migration) tam olarak ihtiyacınız olan şey budur.

Bölüm 3 — Önce verinizin yapısını anlayın

Sadece verinin ne kadar büyük olduğu değil, ne tür bir veri olduğu önemlidir.

Kolay Senaryo: Büyük Dosyalar ve Standart Yapı

Sanal makine imajları, veri tabanı dökümleri (database dump) ve medya arşivleri bu gruba girer. Buradaki temel risk bağlantı kesintileridir; ancak yarım kalmış bir dosyayı fark etmek kolaydır. Dosya boyutu yanlıştır, dosya açılmaz veya ilk kullanımda kontrol toplamı (checksum) hatası verir. Bir sorun olduğunu hemen anlarsınız.

Tehlikeli Senaryo: İçerik Tabanlı Depolama (Content-Addressable Storage)

Birçok doküman yönetim sistemi (Nuxeo ve Alfresco dahil), yedekleme araçları, konteyner kayıt defterleri (container registry) ve nesne depolama (object store) sistemleri içerik tabanlı adresleme kullanır: Sistem, dosyanın baytlarını hash'ler ve elde edilen bu özet (digest), dosyanın adı ve yolu (path) haline gelir.

binaries/data/

├── 00/

│   └── 00a3f9c1e4...  ← dosya adı içeriğin HASH değeridir

├── 01/

├── ...

└── ff/                ← 256 adet hash ön-ekli dizin

Veri tabanı karma değerleri (digest), dosya sistemi ise doğrudan baytları saklar. Bu ikisini birbirine bağlayan başka hiçbir mekanizma yoktur.

Bu durum, standart dosya hiyerarşilerinde dengi olmayan ciddi bir başarısızlık senaryosu (failure mode) yaratır: Kesintiye uğramış veya yarım kalmış bir dosya bozuk görünmez; tamamen geçerli bir dosya gibi durur. Doğru hash dizininde yer alır, find | wc -l komutu onu sayar, ls komutu listeler ve veri tabanı bir doküman aradığında onu bulup eşleştirir. Sonucunda kullanıcı bozuk bir PDF indirir; fakat sistemde ne bir hata oluşur, ne bir log satırı düşer, ne de bir uyarı (alert) tetiklenir.

İçerik tabanlı adreslemenin (content addressing) temel vaadı veri bütünlüğünü (integrity) garanti etmektir; ancak bu garanti, yalnızca bir mekanizma hash değerini aktif olarak doğruluyorsa geçerlidir. Standart okuma süreçleri (read path) ise bu doğrulamayı hiçbir zaman yapmaz, doğrudan dosya yoluna güvenir.

Özetle: Eğer depolama yapınız içerik tabanlı adresleme kullanıyorsa, transfer sürecini yarım kalmış bir dosyanın (partial file) asla nihai dosya adıyla var olamayacağı şekilde kurgulayın. Bunu sağlayan çok kritik bir parametre (flag) mevcut ve 5. Bölüm tamamen bu konuya ayrılmıştır. Bu rehberden tek bir çıkarım yapacak olsanız, o da bu kural olsun.

Diğer yapısal soru: veriye nasıl erişiliyor?

Aynı baytlar, üzerlerinde çalışan sistem veya servise bağlı olarak farklı davranışlar sergiler:

• Herhangi bir servise bağlı olmayan standart dizinler (plain directory): En basit senaryodur, doğrudan ve özgürce kopyalayabilirsiniz.

• Aktif olarak veri yazan canlı servisler (live service): Transfer esnasında servisi durdurun ya da belirli bir anı temsil etmeyen (point-in-time consistent olmayan) tutarsız bir kopyayı kabul etmek zorunda kalırsınız.

• Bağlama alanına (bind mount) sahip konteynerler: Sayısal kullanıcı kimlikleri (numeric UID), her iki sunucuda da birebir eşleşmelidir.

• Veri tabanı veri dizinleri (database data directory): Canlı sistemde (hot) rsync çalıştırmayın; veri tabanının kendi aktarım ve çoğaltma (dump/replication) araçlarını kullanın.

Bölüm 4 — Flag'leri seçmeden önce profil çıkarın

Sizi ne yaptığını bildiğiniz bir komut ile rastgele kopyaladığınız bir komut arasındaki farkı ortaya koyacak adım budur. Altı kontrol, toplam iki dakika. Alacağınız her yanıt, komutunuza ekleyeceğiniz bir seçeneği güvenli hale getirecek ya da gereksiz bir seçeneği çıkarmanızı sağlayacaktır. 

1. Hard link var mı?

find /data/myapp -type f -links +1 | head

Çıktıda bir değer görmeniz, -H seçeneğine (flag) ihtiyacınız olduğu anlamına gelir. Bu parametre olmadan her hard link hedefte bağımsız ve tam bir dosya olarak kopyalanır. Bu durum, hedeflenen veri boyutunun kaynağın çok üzerine çıkmasına yol açar. Birçok sistem yöneticisi bu durumu ancak hedef disk beklediklerinin %140'ı dolup taştığında fark eder. 

2. Erişim kontrol listeleri (ACL) veya extended attribute var mı?

getfacl -R /data/myapp 2>/dev/null | grep -c '^user:'

getfattr -R -d /data/myapp 2>/dev/null | head

Çıktıda bir değer görmeniz, sırasıyla -A ve -X seçeneklerine (flag) ihtiyacınız olduğu anlamına gelir. SELinux etiketleri genişletilmiş öznitelikler (xattr) içinde saklanır; bu nedenle Red Hat/RHEL ailesi sistemlerde bu sorunun yanıtı neredeyse her zaman evettir. 

3. Kaç farklı sahiplik (ownership) kombinasyonu var?

find /data/myapp -printf '%u:%g\n' | sort -u

Tek satırlık bir çıktı ideal senaryodur; bu durumda doğrulama (verification) işlemi tek bir stat karşılaştırmasından ibaret hale gelir. Çok sayıda satır çıkması ise dosya sahipliklerini (ownership) titizlikle korumanız ve bu kontrolü dizin ağacının alt alt bölümleri (subtree) bazında tek tek gerçekleştirmeniz gerektiği anlamına gelir. 

4. Ortalama dosya boyutu nedir?

echo "$(du -sb /data/myapp | cut -f1) bytes / $(find /data/myapp -type f | wc -l) files"

Bu tek sayı, mimari kararlarınızı diğer tüm etkenlerden daha fazla yönlendirir: 

5. CPU AES-NI destekliyor mu?

grep -m1 -o aes /proc/cpuinfo

openssl speed -evp aes-128-gcm 2>/dev/null | tail -3

Bu durum, kullanacağınız SSH şifreleme algoritmasını belirler ve yanlış bir seçim transfer hızını ciddi şekilde düşürür. Kontrolü her iki sunucuda da yapmanız gerekir; çünkü veri kaynağında şifrelenir (encrypt), hedefte ise çözülür (decrypt). Dolayısıyla nihai performans sınırını her zaman daha yavaş olan CPU belirler. 

6. Hedefte yeterli alan var mı ve hedef boş mu?

ssh user@target 'df -h /data; ls -la /data/myapp'

Hedef dizinin tamamen boş olması, rsync'in fark bulma algoritmasının (delta algorithm) karşılaştırabileceği hiçbir verinin olmadığı anlamına gelir; bu da -W (--whole-file) parametresini kullanmanın önünü açar. Dolu bir hedef dizine aktarım yapmak ise farklı seçenekler (flag) gerektiren tamamen başka bir transfer senaryosudur. 

Altın Kural: Bu rehberdeki de dahil olmak üzere, sunulan hiçbir rsync komutunu yukarıdaki altı kontrolü çalıştırmadan asla doğrudan kopyalayıp çalıştırmayın. Komutu belirli bir veri kümesi (dataset) için doğru kılan şey bu kontrollerdir ve bu makalenin isteğe bağlı olmayan tek kısmı da burasıdır. 

Bölüm 5 — Transfer Komutunu oluşturmak

Size hazır bir sihirli komut sunmak yerine, bu komutun parça parça nasıl inşa edildiğini adım adım inceleyelim.

İşe doğru olan en temel ve minimum komut yapısıyla başlayın:

rsync -a /data/myapp/ user@target:/data/myapp/

Yalnızca -a parametresi bile geçerli bir transfer komutudur. Bu noktadan sonra eklenecek her seçenek, mantıklı bir gerekçeye dayanan bilinçli bir ilavedir.

Sondaki bölü çizgileri (/) süs olsun diye konulmaz.

/data/myapp/ ifadesi bu dizinin içeriği anlamına gelir. Bölü çizgisi olmadan kullanılan /data/myapp ise dizinin kendisi demektir ve hedef sunucuda /data/myapp/myapp şeklinde mükerrer bir dizin yapısının oluşmasına yol açar. Bu durum, yapılan en yaygın rsync hatasıdır. Rehberdeki örneklerde her iki tarafta da bu kullanıma özen gösterilmiştir.

Şu ana kadar profili çıkarılan senaryo için oluşturulmuş nihai komut (küçük dosyalar, boş hedef dizin, eşleşen sayısal UID'ler, gigabit yerel ağ ve aktif AES-NI desteği):

rsync -aW --numeric-ids \

      --partial-dir=.rsync-partial \

      --info=progress2 \

      --exclude '/logs/' \

      -e "ssh -c [email protected]" \

      /data/myapp/ user@target:/data/myapp/

Şimdi her bir seçeneği (flag) inceleyelim: Ne işe yarar ve size nasıl zarar verebilir? İkinci kısım, öğretici rehberlerin (tutorial) genellikle atladığı kısımdır ve bu parametrenin sizin komutunuza gerçekten ait olup olmadığını belirleyen şey tam olarak burasıdır. 

-a — archive (Arşivleme Modu) 

Ne işe yarar:
-rlptgoD parametrelerinin kısaltmasıdır: Alt dizinlere inme (recurse), sembolik bağlantıları (symlink) koruma, izinleri (permissions), zaman damgalarını (timestamps), grup (group) ve sahip (owner) bilgilerini ve özel aygıt dosyalarını (device/special files) koruma işlevlerini içerir. Transfer sonucunu yüzeysel bir benzerlik değil, birebir bir kopya haline getiren ana parametredir.

Size nasıl zarar verebilir:
Doğrudan bir zararı yoktur; ancak neleri dışarıda bıraktığı nedeniyle sorun yaratabilir. -a parametresi şunları kapsamaz:

İşte metnin anlamını ve teknik derinliğini koruyarak daha akıcı, doğal ve profesyonel bir Türkçe ile yeniden yazılmış hali:

Buradan çıkarılacak ders "Her zaman -HAX parametrelerini ekleyin" demek değildir. Asıl ders şudur: -a parametresi "her şeyi koru" anlamına gelmez ve bu üç seçeneği de körü körüne komuta eklemek, bir milyon dosyalık bir transferde ciddi bir bellek (RAM) ve CPU maliyeti yaratır —özellikle -H seçeneği arka planda bir sert bağlantı tablosu (hard-link table) oluşturup bunu hafızada tutmak zorundadır. Sadece yaptığınız profil analizinin gerekli kıldığı parametreleri ekleyin, fazlasını değil.

-W — Whole File (Tüm Dosya Modu)

• Ne işe yarar:
  Rsync'in fark transfer algoritmasını (delta-transfer algorithm) devre dışı bırakır. Normal şartlarda rsync, hedefteki dosyayı bloklara ayırır, bunların kontrol toplamlarını (checksum) çıkarır ve sadece değişen blokları ağ üzerinden gönderir. Bu mekanizma yavaş bir geniş alan ağında (WAN) mükemmel çalışır. Ancak hedef dizin tamamen boşsa bu işlem anlamsızlaşır; çünkü karşılaştırılacak hiçbir veri yoktur ve sistem her bloğun eksik olduğunu tespit etmek için boşuna CPU harcar. Hızlı bir yerel ağda (LAN) bu hesaplama adımını atlamak, çaba sarf etmeden hız kazanmak demektir.

• Size nasıl zarar verebilir:
  Transfer işlemi kesintiye uğrarsa, yarıda kalmış bir dosya kaldığı yerden (dosya ortasından) devam edemez; sıfırıncı bayttan itibaren tekrar gönderilir. Küçük dosyalarda bu durumun getirdiği ek maliyet önemsizdir. Ancak çok gigabaytlık büyük dosyalarda durum ciddileşir: 50 GB'lık bir dosyanın %90'ı tamamlanmışken yaşanan bir kesinti, 45 GB'lık emeğin çöpe gitmesi anlamına gelir.

Hangi durumlarda -W kullanılmalı?

Hedef dizin boşsa, dosyalar küçükse ve bağlantı hızlıysa kullanın.

Hangi durumlarda -W kullanılmamalı?

Dosyalar büyükse, hedef dizinde zaten veri varsa veya ağ bağlantısı yavaş/güvenilmezse bu parametreyi kullanmayın.

Not: -W kullanımı, aşağıda açıklanan --partial-dir parametresinin hız avantajını ortadan kaldırır. Ancak sağladığı veri güvenliği avantajı devam eder —ki asıl kritik olan da budur.

İşte metnin anlamını, teknik derinliğini ve vurgusunu koruyarak daha akıcı, doğal ve profesyonel bir Türkçe ile yeniden yazılmış hali:

--numeric-ids

• Ne işe yarar:
  Kullanıcı ve grup kimliklerini (UID ve GID) isimlere dönüştürmeden (resolve etmeden) doğrudan sayısal değerleriyle aktarır. İki temel gerekçesi vardır: Bir milyon dosyada isim sorgulaması yapmak (name lookup) kayda değer bir performans maliyeti yaratır; ayrıca konteyner yapıları isimlerle değil, yalnızca sayısal kimliklerle ilgilenir.

• Size nasıl zarar verebilir:
  Hedef sunucuda aynı UID başka bir kullanıcıya aitse, kopyalanan dosyaların mülkiyeti istemeden o kullanıcıya geçer ve servisiniz bu dosyaları okuyamaz. Bu parametreyi güvenli kılan şey; 4. Bölüm'deki 3. Kontrolü uygulamak ve her iki sunucudaki id komutu çıktılarını birebir karşılaştırmaktır.

Önemli İkaz: İnsan içgüdüsü aksini düşünmeye yatkın olsa da açıkça belirtmekte fayda var: İsim tabanlı eşleme (name-based mapping) —yani bu parametre kullanılmadığında devreye giren varsayılan davranış— çok daha tehlikeli bir seçenektir. Bir kullanıcı adı iki farklı sunucuda farklı UID değerlerine karşılık geliyorsa, rsync kaynak sunucudaki sayıdan tamamen farklı bir UID değerini hedefe sessizce yazar. Sayısal mod (numeric mode) öngörülebilir bir şekilde hata verirken; isim modu (name mode) hatayı sessizce gizler.

--partial-dir=.rsync-partial

• Ne işe yarar:
  3. Bölüm'de bahsettiğimiz kritik parametredir. Transfer işlemi kesintiye uğradığında, tamamlanmamış veriler hedef dizinin içindeki gizli bir .rsync-partial alt dizininde bekletilir. Dosya, ancak aktarımı tamamen bittiğinde nihai ismiyle asıl dizine taşınır. Böylece yarım kalmış hiçbir dosya ana dizin ağacında veya başka bir servisin arayacağı herhangi bir ad altında asla görünmez.
  İçerik tabanlı depolama (content-addressable storage) sistemleri için komut içerisindeki en hayati parametre budur. Standart dosya hiyerarşileri için de oldukça sağlıklı bir uygulamadır: Sonraki hiçbir süreç (downstream process) yarım kalmış bir dosyayı yanlışlıkla okuyamaz.

• Neden sadece --partial değil?
  Çünkü düz --partial parametresi, tamamlanmamış veriyi nihai dosya adı (final filename) altında saklamaya devam eder. Bu durum, 3. Bölüm'de bahsettiğimiz sessiz veri bozulması (silent corruption) senaryosunun bizzat elceğizinizle uygulanmış halidir. --partial parametresi, yalnızca baştan sona tek başınıza kontrol ettiğiniz devasa bir indirme işlemini sürdürmek için tasarlanmıştır; o dizini başka herhangi bir servis okuduğu anda doğrudan bir tehdide dönüşür. Bu iki parametre aynı fikrin farklı varyasyonları gibi görünse de aslında birbirlerinin tamamen zıttıdır.

• Size nasıl zarar verebilir:
  -W (--whole-file) seçeneği ile birlikte kullanıldığında herhangi bir hız avantajı sağlamaz —yarım kalmış dosya her senaryoda sıfırdan tekrar gönderilir— yalnızca veri güvenliği garantisi sunar. Ayrıca kesintiye uğrayan bir transfer geride yetim kalmış (orphaned) .rsync-partial dizinleri bırakabilir. İlerleyen bölümlerde anlatılacak doğrulama (verification) sürecinin özellikle bu dizinleri avlamasının sebebi de budur.

--info=progress2

• Ne işe yarar:
  Dosya bazında ayrı ayrı çıktı vermek yerine, toplam aktarılan bayt, anlık transfer hızı ve tahmini kalan süre (ETA) gibi toplu ilerleme raporu (aggregate progress) sunar. Birkaç bin dosyayı geçtikten sonra dosya bazlı çıktı almak bir ilerleme göstergesi olmaktan çıkar; doğrudan terminalinize yapılan bir hizmet dışı bırakma (Denial-of-Service / DoS) saldırısına dönüşür.

• Size nasıl zarar verebilir:
  Pratik olarak hiçbir zararı yoktur. Ancak zihninize kazımanız gereken tek bir detay var: rsync dosya listesini tek seferde değil, kademeli olarak oluşturur. Bu nedenle işleme başladığı anda nihai toplam boyutu henüz bilmez. Büyük bir transferin ilk aşamalarında yüzde değerini ve kalan süre tahminini göz önünde bulundurmayın; bu veriler henüz büyümeye devam eden eksik bir dosya listesine göre hesaplanır ve çoğunlukla aşırı iyimser (yanlış) sonuçlar verir.

• --exclude — Ve Desenlerin (Pattern) Gerçek Çalışma Mantığı

  Bazı veriler asla taşınmamalıdır. Log dosyaları bunun en tipik örneğidir ve bunun sebebi disk alanından tasarruf etmek değildir.

  
  

  Eski sunucunuzun log dosyalarını yeni sunucuya kopyalarsanız, yeni çalışan servis aynı dosyayı açar ve mevcut verilerin sonuna yazmaya (append) devam eder. Elinizde, hangi satırın hangi makineden geldiğini ayırt etmenin hiçbir yolu olmayan ve iki sunucunun çıktılarının birbirine karıştığı tek bir log dosyası kalır. Bu felaketi ise ancak yeni sunucuda yaşanan ilk sistem kesintisi (incident) anında fark edersiniz —yani mümkün olan en kötü zamanda.

  Benzer şekilde taşınmaması gereken diğer adaylar: Önbellekler (cache), geçici dizinler (temp), .Trash, uygulamanın zaten baştan inşa edebildiği arama dizini (search index) klasörleri ve *_transient isimlendirme kuralına uyan tüm yapılar.

  İnsanların en çok hata yaptığı yer ise desen sözdizimidir (pattern syntax). rsync komutunda en başta kullanılan bölü işareti (/), işletim sisteminin kök dizinini (filesystem root) değil; transferin başladığı kök dizini (root of the transfer) temsil eder:

  
  

  Desen (Pattern)	Neyi Eşleştirir?
  'logs/'	Herhangi bir derinlikte adı logs olan tüm dizinleri — data/xx/logs dahil (genellikle istenen bu değildir).
  '/'logs/'	Yalnızca transfer kök dizininin (transfer root) altındaki üst seviye logs dizinini ✅
  '/data/myapp/logs/'	Hiçbir şeyi — sessizce hiçbir dosya ile eşleşmez ❌

  
  

  O üçüncü satır tam bir tuzaktır. Gereğinden fazla detaylandırılmış (over-qualified) bir desen hata vermez. Hiçbir dosyayı hariç tutmadan sessizce çalışmaya devam eder ve siz bunu ancak istenmeyen dosyalar hedef sunucuda göründüğünde fark edersiniz.

  Size nasıl zarar verebilir:

  Yazdığınız desen, bu dizin ağacına dokunan her komutta —hem asıl transfer hem de doğrulama simülasyonu (verification dry-run) esnasında— birebir aynı şekilde tekrarlanmalıdır. Doğrulama sırasında bu deseni unutursanız rsync size "hedefte log dosyaları eksik" uyarısı verir; siz de bunun gerçek bir tutarsızlık mı yoksa kendi yazdığınız desendeki bir kayma mı (pattern drift) olduğunu çözmekle uğraşırsınız.

  En sağlıklı çözüm, bu deseni her iki komutun da ortaklaşa kullandığı tek bir değişkene atamaktır:

  EXCL="--exclude=/logs/ --exclude=/tmp/"

  rsync -aW --numeric-ids $EXCL /data/myapp/ user@target:/data/myapp/

  
  

  -e "ssh -c [email protected]" — Şifreleme Algoritmasının (Cipher) Seçimi 

  
  

  Ne işe yarar:

  SSH aktarım şifreleme algoritmasını (transport cipher) belirler. AES-128-GCM, işlemci üzerindeki donanımsal AES-NI komut setlerini doğrudan kullanır. Modern varsayılan algoritma olan ChaCha20-Poly1305 ise donanımsal AES hızlandırıcısı bulunmayan CPU'lar için özel olarak tasarlanmış bir yazılımsal şifreleme algoritmasıdır.

  
  

  Şifreleme Algoritması (Cipher)	Yaklaşık Tek Çekirdek İşleme Kapasitesi (Throughput)
  chacha20-poly1305 (varsayılan)	Yüzlerce MB/sn seviyelerinde
  AES-NI destekli aes128-gcm	Birden fazla GB/sn seviyelerinde
  AES-NI desteksiz aes128-gcm	Yaklaşık 100 MB/sn seviyelerinde

  
  

  Bu değerler kesin spesifikasyonlar değil, büyüklük sırasını (orders of magnitude) gösteren değerlerdir. Kendi sisteminizdeki hızı openssl speed -evp aes-128-gcm komutuyla ölçebilirsiniz.

  Size nasıl zarar verebilir:

  AES-NI desteği olmayan bir CPU üzerinde performans ciddi şekilde düşer — tablonun en alt satırındaki hız, doyurmaya (saturate) çalıştığınız gigabit ağ hattından bile daha yavaş kalır. Bu parametre, komutunuza körü körüne eklenilecek değil, kullanılmadan önce mutlaka doğrulanması gereken bir seçenektir.

  Resmin Tamamı (Dürüst Değerlendirme):

  1 Gbps'lik bir ağ hattında pratikteki fark oldukça küçüktür; çünkü ChaCha20 algoritması zaten ~125 MB/sn olan kablo limitini tek başına doldurabilir. Buradaki asıl kazanç, CPU üzerindeki yükün hafiflemesidir; böylece işlemci çekirdekleri rsync'in kendi iç işlerine (dizin tarama, sistem çağrıları, dosya listesi yönetimi) daha fazla kaynak ayırabilir. Ancak 10 Gbps hatlarda veya CPU kaynakları için birbiriyle yarışan paralel aktarım akışlarında (parallel streams) performans farkı belirginleşir. Tek bir akışla çalışan 1 Gbps'lik dolu bir hatta bu parametre neredeyse hiçbir etki yaratmaz — komutunuza eklerken bu durumu bilerek ekleyin.

  Güvenlik Boyutu:

  AES-128-GCM seçimi kesinlikle bir güvenlik tavizi (downgrade) değildir. Bir AEAD (şifreleme + veri bütünlüğü doğrulama) algoritmasıdır ve OpenSSH'in önerilen varsayılanları arasında yer alır. Burada yaptığınız şey hız uğruna güvenlikten ödün vermek değil, donanım desteğinize göre iki güçlü şifreleme algoritması arasında doğru seçimi yapmaktır.

  
  

  Bölüm 6 — Kullanmamanız Gereken Parametreler (Flags)

  
  

  Bu bölüm en az öncekiler kadar öğreticidir; çünkü aşağıda anlatılacak parametrelerin çoğu rehberlerde koşulsuz bir tavsiye gibi sunulmaktadır.

  Seçenek (Flag)	Neden Haric Tutulmalı / Kullanılmamalı?
  -z (sıkıştırma)	Yalnızca veri sıkıştırılabilir nitelikteyse ve darboğazı ağ bağlantısı oluşturuyorsa fayda sağlar. Medya dosyaları, PDF'ler, JPEG'ler, ofis belgeleri ve şifrelenmiş veri blokları (blobs) zaten sıkıştırılmıştır; dolayısıyla boyuttan bir kazanç elde edemediğiniz gibi transferi tek çekirdeğe bağımlı bir gzip işlemine hapsedersiniz (genellikle ~40 MB/sn civarında sınırlandırır). Yerel ağda (LAN), -z kullanımı genellikle süreci yavaşlatır. Bu seçeneği yalnızca metin ağırlıklı verilerle ve kısıtlı bir geniş alanda (WAN) kullanın, başka hiçbir yerde değil.
  --delete	Hedef dizinde bulunan ancak kaynak dizinde yer almayan dosyaları siler. Boş bir hedefte silinecek bir şey olmadığı için tamamen risk teşkil eder. Doğru kullanım yeri, onları silmek yerine fazlalıkları raporlamak amacıyla -n ile birlikte kullanıldığı doğrulama simülasyonudur (verification dry-run). Yanlış yazılmış bir kaynak yoluyla kullanılmış bir --delete parametresi, bir dizini yok etmenin en klasik yollarından biridir.
  -H -A -X	Yalnızca yapılan profil analizinde sert bağlantılar (hard links), erişim kontrol listeleri (ACLs) veya genişletilmiş öznitelikler (xattrs) bulunduysa kullanılmalıdır. "Ne olur ne olmaz" mantığıyla eklemek, milyonlarca dosya boyunca bellek ve CPU'yu boş yere harcar.
  -S (seyrek dosya / sparse)	Yalnızca gerçekten seyrek yapıda olan dosyalar (sanal makine disk imajları, bazı veri tabanı dosyaları) için geçerlidir. Ayrıca -W parametresi ile olumsuz etkileşime girer.
  --bwlimit	Diğerlerinin aksine: Mesai saatleri içinde aktarım yapıyorsanız komuta ekleyin. Bakım penceresinde bağlantı hattını tam kapasite kullanmak sorun yaratmaz ancak öğleden sonra saat 2'de bunu yapmak yıkıcı olur. --bwlimit=80M kullanımı, diğer kullanıcılar için bant genişliği bırakır.
  -c (kontrol toplamı / checksum)	rsync'i, neyin gönderileceğine karar vermeden önce her iki taraftaki tüm dosyaları okumaya ve hash'lemeye zorlar. Büyük bir veri kümesinde, hedef boşken hiçbir fayda sağlamadan iş yükünü iki katına çıkarabilir. Transfer komutunda değil, doğrulama adımında bir örneklem üzerinde kullanılmalıdır.
  StrictHostKeyChecking=no	Genellikle onay istemlerini geçmek için eklenir. Sunucu anahtarının (host key) değiştiğini bildiren güvenlik kontrolünü devre dışı bırakır. Bunun yerine anahtarı bir kez known_hosts dosyasına ekleyin; durdurup uyarı veren varsayılan davranış, tam olarak ihtiyaç duyduğunuz şeydir.

  
  

  Bölüm 7 — Transferi Kesintilere Karşı Dayanıklı Şekilde Çalıştırmak

   

  Saatler sürecek bir aktarım işlemini asla yalın bir SSH oturumu içinde başlatmayın. VPN'inizin bir anlık kopması durumunda çalışan tüm süreç onunla birlikte ölür. 

  screen -S sync        # or: tmux new -s sync

  Transfer komutunu bu oturumun içinde çalıştırın. Oturumdan ayrılmak için Ctrl+A ardından D tuşlarına basın (tmux için: Ctrl+B ardından D). Tekrar bağlanmak için ise screen -r sync (tmux için: tmux attach -t sync) komutunu kullanın.

  İşlem yarıda kesilirse, birebir aynı komutu tekrar çalıştırın. rsync'i vazgeçilmez kılan temel özellik budur: Tamamlanmış dosyalar otomatik olarak atlanır, böylece süreç sıfırdan başlamak yerine kaldığı yerden devam eder. Denemeler arasında komut üzerindeki parametreleri değiştirmeyin — değişen flag'ler karşılaştırma mantığının değişmesi anlamına gelir ve bu da garantinizi kaybettirir.

  İkinci bir terminal üzerinden süreci izleyin:

  watch -n 60 'ssh user@target "du -sh /data/myapp; df -h /data | tail -1"'

  Hedef diski sürekli gözlemleyin. Eğer veriler başka servislerle paylaşılan bir dosya sistemine yazılıyorsa, transferin ortasında diskin dolması çözümü yavaş ve can sıkıcı bir sürece dönüşür. Kullanım oranı %90'ı geçtiğinde müdahale edin.

  Transfer Süresini Tahmin Etmek

  İşlem süresini sınırlayan iki tavan vardır; bunlardan düşük olanı nihai süreyi belirler:

  1. Bant Genişliği Tavanı: Toplam boyut $\div$ gerçekçi veri transfer hızı. 1 Gbps'lik bir hat teorik olarak ~125 MB/sn sunar; ancak protokol ek yüklerinden (overhead) sonra gerçekçi hız ~100–110 MB/sn civarındadır.

  2. Dosya Sayısı Tavanı: Küçük dosyalarda, dosya başına düşen işlem yükü baskın hale gelir ve hattın izin verdiğinden çok daha düşük hızlar görebilirsiniz.

  Ölçülen veri transfer hızı bant genişliği tavanının çok altındaysa, darboğazı dosya sayısı oluşturuyordur (file-count-bound) ve çözümünüz 8. Bölüm'dedir. Hangi problemle karşı karşıya olduğunuzu anlamak için önce hattı test edin:

  dd if=/dev/zero bs=1M count=4000 | ssh user@target 'cat > /dev/null'

  
  

  Bölüm 8 — Paralel Aktarıma Geçiş 

  
  

  Tek bir rsync süreci tek bir iş yapar: stat, oku, şifrele, yaz ve tekrar et. CPU'da boşta çekirdekler varsa ve ağ hattı henüz dolmadıysa, iş yükünü bölmek ciddi bir kazanç sağlar — genellikle %30 ile %50 arasında bir hız artışı elde edilir.

  Paralelleştirme, doğal bir bölümlendirmeye (partition) ihtiyaç duyar. Tek bir rsync sürecini doğrudan bölemezsiniz; bunun yerine birbiriyle kesişmeyen alt dizinler (disjoint subtrees) üzerinde çalışan birkaç farklı rsync süreci başlatırsınız.

  İyi bir bölümlendirme şu özelliklere sahip olmalıdır:

  • Yaklaşık olarak eşit boyutlarda olması: Aksi takdirde tek bir ağır akışın bitmesini beklemek zorunda kalırsınız.

  • Kesişmeyen yapıda olması: Aynı dizin ağacına yazmaya çalışan iki ayrı rsync birbiriyle çakışır.

  • Önceden listelenebilir olması:

  Hash ön-ekli dizinler (hash-prefix directories) mükemmel bir adaydır; çünkü içerik tabanlı adresleme yapısı gereği dosyaları bu dizinlere eşit olarak dağıtır. Tarihe göre bölümlenmiş dizin ağaçları da (2024/01/, 2024/02/) aynı şekilde iyi çalışır. Ancak bir adet devasa dizin ve kırk adet minik dizinden oluşan bir yapıyı paralelleştiremezsiniz — böyle durumlarda tek akışta kalmalısınız.

  Önce hafif dizinleri taşıyın, ardından ağır bölümlere dağılın:

  # 1. everything except the big partition

  rsync -aW --numeric-ids --info=progress2 --exclude 'binaries/' \

        -e "ssh -c [email protected]" \

        /data/myapp/data/ user@target:/data/myapp/data/

  # 2. the big partition, N streams at a time

  ssh user@target "mkdir -p /data/myapp/data/binaries/data"

  ls /data/myapp/data/binaries/data | xargs -P 8 -I{} \

    rsync -aW --numeric-ids --partial-dir=.rsync-partial \

          -e "ssh -c [email protected]" \

          /data/myapp/data/binaries/data/{}/ \

          user@target:/data/myapp/data/binaries/data/{}/

  -P değerini seçmek. 4–8 paralel akış ile başlayın. Sayıyı sürekli artırmak performansı artırmaz: Ağ bağlantısı, diskler veya CPU doyuma ulaştıktan sonra eklenen her yeni akış; disk okuma kafasında yarışa (seek contention) ve bağlam değişimine (context switching) yol açarak süreci yavaşlatır. Mekanik sabit disklerde (HDD) bu kırılma noktası çok erken yaşanır —eşzamanlı rastgele okumalar mekanik bir disk için olabilecek en kötü senaryodur. NVMe SSD'lerde ise bu sayıyı daha yukarı çekebilirsiniz. Akış sayısını artırırken toplam hızı (throughput) izleyin ve hız artışı durduğunda sayı artırmayı bırakın. 

  Bu yöntemle ilgili bilmeniz gereken iki önemli detay:

  1. --info=progress2 parametresi kaldırılmıştır; çünkü tek bir terminal ekranına 8 farklı ilerleme çubuğu yazdırılması okunamaz bir görüntü oluşturur — bunun yerine watch döngüsünü kullanın.

  2. Eski transfer kök dizinine (transfer root) göre yazılmış haric tutma (exclude) kuralları artık geçerli değildir; çünkü artık her akışın kendi kök dizini vardır. Hariç tutmak istediğiniz her şeyin halen kapsam dışında kaldığını tekrar kontrol edin.

  Doğrulama süreci her iki yöntemde de (tekli veya paralel aktarım) birebir aynıdır ve her iki senaryoda da aynı komut kullanılır. 

  
  

  Bölüm 9 — Katmanlı Doğrulama Prosedürü 

  
  

  Transfer "düzgün göründüğü" için geliştiricilerin genelde atladığı adım burasıdır. Her doğrulama katmanı, bir önceki katmanın yakalayamadığı farklı bir hatayı tespit eder. 

  Katman 1 — dry run

  En değerli tek kontrol adımıdır. rsync'e hedef tarafta hâlâ neleri değiştirmesi gerekeceğini sorun: 

  rsync -an --delete --numeric-ids --itemize-changes \

        --exclude '/logs/' \

        /data/myapp/ user@target:/data/myapp/

  -n parametresi simülasyon (dry run) anlamına gelir: hiçbir dosya üzerinde değişiklik yapılmaz. Buradaki --delete kullanımı, hedefteki dosyaları silmek yerine kaynakta bulunmayan dosyaları raporlama işlevi görür. Çıktıda herhangi bir dosya satırının görünmemesi, kopyalama işleminin tamamen eksiksiz bittiğini gösterir. 

  Bölüm 5'te bahsettiğimiz desen kayması (pattern drift) tuzağına düşmemek için --exclude '/logs/' deseni karakteri karakterine aynı şekilde tekrar eklenmiştir. 

  --itemize-changes çıktısını okumak

  İlk bakışta karmaşık görünse de pratikte karşılaşacağınız yalnızca birkaç kod vardır. Her satır 11 karakterlik bir alanla başlar (YXcstpoguax): 

  Kod	Anlamı
  >f++++++++++	Dosya hedefte hiç yok — her şey tamamen yeni.
  .f....og...	Dosya mevcut ve içeriği birebir aynı; yalnızca kullanıcı (owner) ve grup (group) mülkiyeti farklı.
  >f..t......	İçerik farklı —yeniden gönderilecek— ve zaman damgası (timestamp) değişiyor.
  cd++++++++++	Yeni bir dizin oluşturulacak.
  *deleting	Dosya hedefte var ancak kaynakta bulunmuyor (silinecek).

  .f....og... çıktısı sevimli olandır: hiçbir baytın ağ üzerinden taşınması gerekmez, süreci tamamlamaktan yalnızca tek bir chown komutu uzaktasınızdır. (Eski rsync 2.x sürümleri 11 karakter yerine 9 karakter bastırır; anlamı tamamen aynıdır, sadece karakter dizisi daha kısadır.) 

  Katman 2 —Dosya Sayıları ve Boyutların Doğrulanması 

  echo "SOURCE: $(du -sb /data/myapp | cut -f1) bytes, $(find /data/myapp -type f | wc -l) files"

  ssh user@target 'echo "TARGET: $(du -sb /data/myapp | cut -f1) bytes, $(find /data/myapp -type f | wc -l) files"'

  İnsan tarafından okunabilir biçimlendirme (human-readable) değerleri yuvarladığı ve bu yuvarlama tam da aradığınız uyuşmazlıkları gizlediği için du -sh yerine du -sb (bayt cinsinden) komutunu kullanın. Eğer transfer esnasında bazı dizinleri hariç tuttuysanız (exclude), bu karşılaştırmadan da onları çıkarın; aksi takdirde sayılar tasarım gereği farklı çıkacaktır. 

  Ayrıca yalnızca toplam boyutu değil, dağılımı da kontrol edin; böylece bir alt dizindeki eksiklik, bir diğerindeki fazlalık ile gizlenemez: 

  du -sh /data/myapp/data/* | sort -rh

  ssh user@target "du -sh /data/myapp/data/* | sort -rh"

  Katman 3 — Mülkiyet Kontrolü (Ownership) 

  stat -c '%u:%g (%U:%G)' /data/myapp/data

  ssh user@target "stat -c '%u:%g (%U:%G)' /data/myapp/data"

  Çıktıdaki sayısal çiftler (UID:GID) birebir eşleşmeli ve bu değerler uygulamanızın/servisinizin çalıştığı kullanıcı kimliğiyle örtüşmelidir. 

  Katman 4 — İçerik Doğrulama (Örneklem Yöntemiyle) 

  Yukarıdaki tüm adımlar yalnızca üst verileri (metadata) karşılaştırır. Dosya sayıları, boyutlar, mülkiyet hakları, zaman damgaları... Ancak henüz dosya içeriğinin tek bir baytı bile okunmamıştır. İçerik tabanlı depolama sistemlerinde (content-addressable storage) bu doğrulama yeterli değildir; çünkü olası bir hata senaryosunda doğru yolda, mantıklı boyutta ama içeriği bozuk bir dosya kalabilir. 

  rsync -an --checksum --numeric-ids --itemize-changes \

        /data/myapp/data/binaries/data/00/ \

        user@target:/data/myapp/data/binaries/data/00/

  --checksum parametresi her iki taraftaki verileri okur ve hash'lerini çıkarır. Çıktının boş olması, baytların gerçekten birebir eşleştiği anlamına gelir. 

  Neden örneklem yöntemi?

  Tüm veri kümesini checksum kontrolünden geçirmek, bütün verinin ağ üzerinden iki kez okunması demektir. Bu durum, --partial-dir parametresinin zaten büyük oranda ortadan kaldırdığı bir risk için saatlerce beklemek anlamına gelir. Bütün veri kümesi içinden birkaç parçayı/dizini örneklem olarak seçin. Verileriniz çok kritikse örneklem sayısını artırın. Eğer veri yeri doldurulamaz nitelikteyse, tüm veri kümesi için bu işlemi çalıştırın ve harcanacak süreyi göze alın.

  
  

  Katman 5 — Kalıntı Yarım Dizinlerin Tespiti 

  
  

  ssh user@target "find /data/myapp -name '.rsync-partial' -type d"

  Burada listelenen herhangi bir klasör, bir aktarım akışının dosya ortasında öldüğü anlamına gelir. Birebir aynı rsync komutunu tekrar çalıştırın. 

  
  

  Katman 6 —Fonksiyonel Test 

  
  

  Hedef sunucuda servisi başlatın ve gerçek erişim yolunu uçtan uca test edin — örneğin bir doküman yönetim sistemi için kullanıcı arayüzünden bir belge açın ve ekini indirin.

  Şu ana kadarki her katman yalnızca iki dosya sistemini birbiriyle karşılaştırdı. Uygulamanın veriye gerçekten ulaşıp ulaşamadığını kanıtlayan ilk katman burasıdır. Yanlış bir bind-mount yolu, eksik bir ortam değişkeni (environment variable) veya konteyner içindeki bir izin uyumsuzluğu... Bunların hiçbiri bayt karşılaştırmasında görünmez; ancak hepsi bu adımda su yüzüne çıkar.

  docker compose up -d

  docker exec myapp curl -fsS "http://localhost:8080/healthcheck"

  
  

  Bölüm 10 — rsync'in Taşımadığı Şeyler 

  
  

  Veritabanları: Uygulamanız bir veritabanı kullanıyorsa, dosya sistemini kopyalamak taşıma işleminin yalnızca yarısıdır. pg_dump, mysqldump veya veritabanı motorunun kendi replikasyon çözümlerini kullanın — çalışan canlı bir veritabanının veri dizinini asla rsync ile kopyalamayın.
  Zamanlama, yöntemden daha önemlidir. Veritabanı dökümünü (dump), servisi durdurduğunuz aynı zaman penceresi içinde alın; böylece veritabanı ile dosya deposu aynı anı temsil eder. Bunların dökümünü farklı zamanlarda alırsanız, veritabanında kaydı olan ancak dosya sisteminde karşılığı bulunmayan bozuk verilerle karşılaşırsınız. Bu tür bozuklukları hiçbir dosya sistemi kontrolü tespit edemez; çünkü rsync açısından kopyalama işlemi kusursuz görünür.

  Yapılandırmalar ve Gizli Bilgiler (Secrets): Ortam değişkeni dosyaları (.env), TLS sertifikaları, cron görevleri, systemd servis tanımları ve güvenlik duvarı kuralları. Bunlar veri dizininin dışında yaşarlar ve "başarılı" görünen bir taşıma işleminin ardından uygulamanın ayağa kalkamamasının en yaygın sebebidirler.

  Kaynak Verileri Silmeyin: Doğrulama adımları tamamen geçene ve yeni sistem gerçek kullanım şartlarında birkaç gün boyunca sorunsuz çalışana kadar kaynak verileri silmeyin. Depolama alanı maliyeti, geri yükleyemeyeceğiniz bir felaketin maliyetinden her zaman daha ucuzdur.

  
  

  Bölüm 11 — Troubleshooting

  
  

  Belirti (Symptom)	Neden ve Çözüm (Cause and Fix)
  Beklenen hızın çok altında veri aktarımı	Önce ağı test edin: dd if=/dev/zero bs=1M count=4000 | ssh user@target 'cat > /dev/null'. Bağlantı hızlı ama rsync yavaşsa $$\rightarro$ sorun dosya sayısı baskısıdır (file-count-bound), paralel aktarıma geçin. Bağlantı yavaşsa $$\rightarro$ duplex/MTU ayarlarını kontrol edin veya eklediyseniz -z parametresini kaldırın.
  Transfer, SSH oturumuyla birlikte kapandı	Süreç screen veya tmux içinde başlatılmamış. Yeni bir oturum açıp komutu tekrar çalıştırın; tamamlanan dosyalar otomatik atlanacaktır.
  Hedef disk doldu	df -h ile kontrol edin; mantıksal birimi genişletin (lvextend -l +100%FREE ... && resize2fs ...) veya daha fazla dizini hariç tutarak komutu yeniden çalıştırın.
  Hariç tutulan dosyalar hedefte görünüyor	Desen gereğinden fazla detaylandırılmış (over-qualified) — Bölüm 5'teki tabloya bakın. Deseni sistem kök dizinine değil, transfer kök dizinine göre sabitleyin.
  Simülasyon (dry-run) hariç tuttuğunuz dosyaları raporluyor	Hariç tutma deseni doğrulama komutunda unutulmuş. Ortak bir değişken kullanın.
  Simülasyonda her yerde .f....og... görünüyor	Yalnızca mülkiyet uyuşmazlığı var; dosya içerikleri tam. Hedefte mülkiyeti düzeltin: ssh user@target "chown -R 1000:1000 /data/myapp", ardından simülasyonu tekrar çalıştırın.
  .rsync-partial dizinleri kalıntı olarak duruyor	Bir aktarım akışı dosya ortasında kesintiye uğramış. Birebir aynı komutu yeniden çalıştırın.
  Yeniden çalıştırmada her dosya tekrar transfer ediliyor	Zaman damgaları (timestamps) korunmuyor — genellikle eksik bir -a parametresi veya farklı zaman damgası hassasiyetine sahip bir hedef dosya sistemi (FAT/SMB hedefleri için --modify-window=1 yardımcı olur).
  Servis başlıyor fakat verilerini okuyamıyor	UID uyumsuzluğu var. Konteyner içindeki id çıktısı ile hedefteki stat -c '%u:%g' değerlerini karşılaştırın.
  Hedefte "Permission denied" hatası	O dizin yoluna yazma yetkisi olmayan bir kullanıcıyla işlem yapıyorsunuz veya hedef dizin mevcut değil.

  
  

  Kısa versiyon

  
  

  Yalnızca tek bir bölümü okuyacak olsanız bile, bu bölümü okuyun:

  • Önce profili çıkarın: Sert bağlantılar (hard links), ACL/xattr varlığı, mülkiyet dağılımı, ortalama dosya boyutu, AES-NI desteği ve boş disk alanı. İki dakika süren altı kontrol komutu, sonraki tüm süreci belirler. Profilini çıkarmadığınız hiçbir rsync komutunu asla kopyalayıp çalıştırmayın.

  • Ortalama dosya boyutu mimari bir girdidir: -W parametresini kullanıp kullanmayacağınızı, dosyanın baştan aktarılmasının kabul edilebilir olup olmadığını ve paralelleştirmenin fayda sağlayıp sağlamayacağını belirleyen temel faktör budur.

  • Depolama modelinizde yarım kalmış bir yazmanın ne anlama geldiğini bilin: İçerik tabanlı depolamada (content-addressable storage) yarım kalmış bir dosya tıpkı sağlıklı bir dosya gibi görünür. Tek başına bu gerçek bile --partial-dir parametresini zorunlu kılan, düz --partial kullanımını ise tehlikeli hale getiren nedendir.

  • Süreci screen veya tmux içinde çalıştırın: Birebir aynı komutu yeniden çalıştırmanın transferi baştan başlatmayıp kaldığı yerden sürdürdüğünü unutmayın.

  • Servisi durdurun ve veritabanı dökümünü (dump) aynı zaman penceresi içinde alın: Veritabanı ile dosya deposu arasındaki tutarlılık otomatik olarak sağlanmaz.

  • Doğrulamayı katmanlar halinde yapın: Üst veri (metadata) kontrolleri maliyetsizdir ve çalıştırmaya değerdir; ancak dosya içeriğinin tek bir baytını bile okumazlar. Örneklem yöntemiyle checksum doğrulama yapın, ardından uygulamayı açıp gerçek senaryoda test edin.

  • Yerel ağ (LAN) ve geniş alan ağı (WAN) varsayılanları değiştirir: -z parametresi hızlı bir yerel ağda darboğaza dönüşür; donanım hızlandırmalı bir şifreleme algoritması (cipher), güvenli yazılımsal varsayılanı geride bırakır. Hangi ağ tipinde çalıştığınızı bilin.

  • Komut işin kolay kısmıdır: Onu sizin veriniz için doğru kılan şey, arkasındaki teknik gerekçelendirmedir.

    
    

  Kaynak: https://medium.com/@ysnhasturk/how-to-move-large-data-between-linux-servers-with-rsync-3fb5d150c5f4