Linux Yedekleme: rsync ve tar ile 3-2-1 Kuralı Uygulaması

Bir disk arızalandığında ilk akla gelen soru "yedeğim var mı" değil, "bu yedek gerçekten geri yükleniyor mu" sorusudur. Aylardır sessizce hata veren bir cron işi, tam ihtiyaç anında boş bir dosya bırakabilir. Bu yazıda Linux'ta rsync ve tar komutlarıyla gerçek bir yedekleme akışı kurmayı, bunu 3-2-1 kuralına bağlamayı ve düzenli test etmeyi ele alıyorum.

rsync ile artımlı yedekleme nasıl kurulur?

rsync ilk çalıştırmadan sonra yalnızca değişen bloğu kopyalar, bu yüzden sonraki her yedekleme çok daha kısa sürer. Temel kullanım şu komuttur:

rsync -avh --delete /home/celil/ /mnt/yedek/home/

-a (archive) bayrağı izinleri, sembolik bağları ve zaman damgalarını olduğu gibi korur. -v her kopyalanan dosyayı ekrana yazar, -h ise boyutları okunabilir birimlerde gösterir. --delete bayrağı kaynakta silinen dosyaları hedeften de kaldırır ve yedeği kaynakla birebir eşitler. Bu bayrağı dikkatli kullanın. Yanlış bir kaynak dizin verirseniz hedefteki dosyaları da silebilirsiniz.

Yedeği uzak bir sunucuya almak istediğinizde SSH üzerinden çalıştırın:

rsync -avz -e ssh /var/www/ kullanici@yedek-sunucu:/backup/www/

-z bayrağı veriyi sıkıştırarak aktarır ve yavaş bağlantılarda işe yarar; hızlı bir yerel ağda ise CPU tüketiminden başka bir katkısı olmaz. Gerçek işlemden önce --dry-run bayrağını deneyin. Bu bayrak hangi dosyaların kopyalanacağını ve silineceğini, hiçbir değişiklik yapmadan önceden gösterir.

rsync -avh --delete --dry-run /home/celil/ /mnt/yedek/home/

Kaynak dizinin sonundaki eğik çizgiye dikkat edin. /home/celil/ ile /home/celil arasındaki fark, rsyncin dizinin içeriğini mi yoksa dizinin kendisini mi kopyalayacağını belirler: sondaki / içeriği kopyalar, çizgisiz hâl ise dizinin kendisini hedefin altına ayrı bir klasör olarak taşır. Bu ayrımı atlamak en sık karşılaşılan rsync hatasıdır. Önbellek veya geçici dosyaları yedeğe hiç almak istemediğinizde --exclude bayrağı işinizi görür:

rsync -avh --delete --exclude='*.cache' --exclude='node_modules/' /home/celil/ /mnt/yedek/home/

rsync ile gerçek artımlı geçmiş nasıl saklanır?

Yukarıdaki komutlar hedefi kaynakla eşitler ama geçmiş sürümleri saklamaz. Dün yanlışlıkla sildiğiniz bir dosyayı bu yöntemle geri alamazsınız. --link-dest bayrağı bu sorunu çözer: her yedek klasörü disk üzerinde yalnızca gerçekten değişen dosyalar kadar yer kaplar, değişmeyen dosyalar ise önceki yedeğe sabit bağ (hard link) ile bağlanır.

rsync -avh --delete \\
  --link-dest=/mnt/yedek/2026-07-01 \\
  /home/celil/ /mnt/yedek/2026-07-02/

Bu yöntem her gün ayrı tarihli bir klasör oluşturur ama disk alanı yalnızca gerçek değişiklikler kadar büyür. Apple'ın Time Machine'i de aynı prensiple çalışır; rsync --link-dest bu fikrin komut satırı karşılığıdır. Bu script'i cron ile otomatikleştirmek işi kolaylaştırır:

#!/bin/bash
TARIH=$(date +%F)
DUN=$(date -d yesterday +%F)
rsync -avh --delete \\
  --link-dest=/mnt/yedek/$DUN \\
  /home/celil/ /mnt/yedek/$TARIH/

Bu script'i /etc/cron.daily/ dizinine koyup chmod +x ile çalıştırılabilir yaptığınızda, sistem her gün otomatik olarak yedek alır.

tar ile arşiv ve sıkıştırma ne zaman tercih edilmeli?

rsync canlı bir dizini senkronize etmek için idealdir. Tek dosyalık, taşınabilir bir arşiv istediğinizde ise tar daha uygun bir seçimdir. Standart sıkıştırılmış arşiv komutu şöyledir:

tar -czvf yedek-2026-07-02.tar.gz /home/celil/belgeler/

-c yeni bir arşiv oluşturur, -z gzip ile sıkıştırır, -v işlenen dosya adlarını ekrana listeler, -f ise hedef dosya adını belirtir. Geri yüklemek için şu komutu kullanın:

tar -xzvf yedek-2026-07-02.tar.gz -C /home/celil/geri-yukleme/

-x çıkarma modunu, -C ise hedef dizini belirtir. Bu bayrağı atlarsanız arşiv çalıştığınız dizine açılır, genelde istemediğiniz bir sonuçla karşılaşırsınız. Daha hızlı bir sıkıştırma isterseniz gzip yerine zstd kullanabilirsiniz; modern dağıtımların çoğunda zaten kurulu gelir:

tar -I zstd -cvf yedek-2026-07-02.tar.zst /home/celil/belgeler/

zstd, gzip'e göre hem daha hızlı sıkıştırır hem de benzer ya da daha iyi bir sıkıştırma oranı verir. Büyük veri kümelerinde bu fark saatler mertebesinde zaman kazandırabilir.

Arşivi oluştururken bütünlüğünü de doğrulamak faydalı bir alışkanlıktır. sha256sum ile bir özet (checksum) dosyası oluşturun, yedeği taşıdıktan sonra bu özeti tekrar karşılaştırın:

sha256sum yedek-2026-07-02.tar.gz > yedek-2026-07-02.sha256
sha256sum -c yedek-2026-07-02.sha256

İkinci komut dosyanın taşıma sırasında bozulmadığını doğrular. Ağ üzerinden taşınan büyük arşivlerde bit hataları nadir görülmez, bu kontrol olmadan böyle bir bozulmayı fark etmeniz zordur.

Veritabanlarını dosya kopyalarken yedeklemek neden riskli?

Çalışan bir MySQL veya PostgreSQL veritabanının veri dizinini doğrudan rsync veya tar ile kopyalamak tutarsız bir yedek üretebilir. Veritabanı tam bir yazma işleminin ortasındayken dosya kopyalanırsa bozuk bir yedekle karşılaşırsınız. Doğru yöntem, veritabanının kendi dışa aktarma aracını kullanmaktır.

mysqldump -u root -p veritabani_adi > veritabani-2026-07-02.sql
pg_dump veritabani_adi > veritabani-2026-07-02.sql

Bu komutlar tutarlı bir anlık görüntü (snapshot) üretir; çıktı dosyasını da rsync ya da tar akışınıza dahil edin. Büyük veritabanlarında mysqldump sunucuyu kilitleyebilir. Üretim ortamında --single-transaction bayrağı InnoDB tabloları için bu riski azaltır:

mysqldump -u root -p --single-transaction veritabani_adi > veritabani-2026-07-02.sql

Bu dökümü sıkıştırıp tarihli olarak saklamak isterseniz tek satırda birleştirebilirsiniz:

mysqldump -u root -p --single-transaction veritabani_adi | gzip > /mnt/yedek/db/veritabani-$(date +%F).sql.gz

Bu komutu crontab -e ile her gece çalıştırmak, veritabanı yedeğini dosya sistemi yedeğinizden bağımsız, kendi başına tutarlı bir akışa bağlar. PostgreSQL tarafında pg_dumpall tüm veritabanlarını tek dosyada dışa aktarır; çoklu veritabanı barındıran sunucularda tek tek pg_dump çağırmaktan daha pratiktir.

3-2-1 kuralını pratikte nasıl uygularsınız?

3-2-1 kuralı basittir: verinin en az 3 kopyası, 2 farklı ortamda, bunlardan 1'i de fiziksel olarak başka bir yerde bulunmalıdır. Tek bir harici diske alınan yedek bu kuralı karşılamaz. Disk çalınır, yanar ya da bozulursa hem orijinal veri hem yedek aynı anda kaybolur.

Pratikte bu, yerel rsync yedeğinin yanına uzak bir sunucuya ya da bulut depolamaya (örneğin rclone ile S3 uyumlu bir depoya) düzenli senkronizasyon eklemek anlamına gelir:

rclone sync /mnt/yedek/ uzak-depo:yedekler/ --progress

rclone, Google Drive, S3, Backblaze B2 gibi onlarca sağlayıcıyı destekler ve rsynce benzer bir sözdizimi kullanır. Kurulumu bitirdikten sonra bulut tarafını da tek satırlık bir cron işiyle otomatikleştirebilirsiniz.

rclone config komutu sağlayıcı hesabınızı ilk kurulumda adım adım bağlar. Bir kez yapılandırdıktan sonra sync komutu her çalıştığında, tıpkı rsync gibi, yalnızca değişen dosyaları yükler. NAS cihazı olmayan küçük bir ev ofisi için bu yöntem ikinci fiziksel konumu neredeyse sıfır donanım maliyetiyle sağlar.

Yedeği test etmeden güvenmek neden hataya açık?

Bir yedekleme script'i hatasız çalışıyor görünse de, gerçekten geri yüklenebilir olduğunu ancak deneyerek anlarsınız. Disk dolduğu için sessizce yarım kalan bir tar arşivi ya da izin hatası yüzünden atlanan dosyalar, genelde ancak ihtiyaç anında fark edilir; o noktada düzeltmek için çok geçtir.

Ayda bir gerçek bir geri yükleme testi yapın; yedekten rastgele birkaç dosyayı ayrı bir dizine açıp içeriğini kontrol edin.

tar -tzvf yedek-2026-07-02.tar.gz | head -20
tar -xzvf yedek-2026-07-02.tar.gz -C /tmp/test-geri-yukleme/ belgeler/onemli-dosya.pdf

İlk komut arşivin içeriğini listeler; arşiv bozuksa hatayı burada alırsınız. İkinci komut ise tek bir dosyayı seçip geri yükler. Bu küçük alışkanlık, "yedeğim var" cümlesini gerçek bir güvenceye dönüştürür.

Tam bir felaket senaryosunu yılda bir kez simüle etmek de faydalıdır. Boş bir sanal makineye ya da ayrı bir diske, sıfırdan yalnızca yedeklerinizi kullanarak sistemi ayağa kaldırmayı deneyin. Bu tatbikat, script çalışıyor görünse de gerçekte eksik kalan bir adımı (örneğin unutulan bir yapılandırma dosyasını) ortaya çıkarır. Yedekleme script'inin çıktısını bir log dosyasına yönlendirip çıkış (exit) kodunu kontrol etmek de işe yarar:

rsync -avh --delete /home/celil/ /mnt/yedek/home/ >> /var/log/yedek.log 2>&1
echo "Yedek durumu: $?" >> /var/log/yedek.log

$? değeri sıfırdan farklıysa bir hata oluşmuş demektir. Bu satırı bir e-posta uyarısına bağlamak, yedeğin sessizce bozulduğunu fark etmeden aylarca beklemenizi engeller.

Yedekleme sıklığını veriye göre nasıl belirlersiniz?

Her veri aynı sıklıkta yedeklenmeyi gerektirmez. Aktif geliştirdiğiniz bir kod deposu için günlük, hatta commit başına bir yedek mantıklıdır; zaten Git'in kendisi bunu bir ölçüde sağlar. Nadiren değişen arşiv fotoğrafları için ise haftalık bir sıklık yeterlidir.

Sıklığı belirlerken asıl soru şudur: ne kadar veri kaybetmeyi göze alabilirsiniz? Bu süreye RPO (Recovery Point Objective, kurtarma noktası hedefi) denir. Bir e-ticaret veritabanında birkaç dakikalık bir kayıp bile ciddi sonuç doğurabilirken, kişisel bir belge klasöründe bir günlük kayıp genelde tolere edilebilir.

• Kritik üretim veritabanları: günde birkaç kez, --single-transaction ile
• Ev dizini / belgeler: günlük, --link-dest ile artımlı
• Statik arşiv (eski projeler, fotoğraflar): haftalık veya aylık
• Sistem yapılandırması (/etc): her değişiklikten sonra, ayrıca haftalık

Saklama süresini de belirlemeniz gerekir; her günün yedeğini sonsuza kadar tutmak diski doldurur. Basit bir rotasyon mantığı, son 7 günlük, son 4 haftalık ve son 6 aylık yedeği saklayıp gerisini silmektir. Buna genelde GFS (Grandfather-Father-Son) rotasyonu denir; ticari yedekleme yazılımlarının çoğu bu mantığı temel alır. Eski yedekleri otomatik temizlemek için find komutu kullanışlıdır:

find /mnt/yedek/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \\;

Bu komut 30 günden eski yedek klasörlerini siler. -mtime değerini kendi ihtiyacınıza göre ayarlayın; komutu ilk çalıştırmada -exec rm yerine -print ile yalnızca listeleyerek test edin.

Şifreleme de göz ardı edilmemeli, özellikle bulut depoya giden yedeklerde. tar çıktısını gpg ile şifrelemek basit ve etkili bir yöntemdir:

tar -czf - /home/celil/belgeler/ | gpg -c -o yedek-2026-07-02.tar.gz.gpg

Bu komut arşivi oluşturur, standart çıktıya yazar ve gpg ile simetrik olarak şifreler. Ortaya çıkan .gpg dosyası, doğru şifre girilmeden açılamaz; bulut sağlayıcınızın verileri ihlal edilse bile içerik okunamaz kalır. Karmaşık bir senaryoda takıldığınızda man rsync ve man tar çıktısı tüm bayrakları ayrıntılı örneklerle listeler, doğru referans için önce oraya bakmak zaman kazandırır.

Yazan Celil Uyanikoglu

Bilgisayar mühendisiyim; 25 yılı aşkın süredir bilgi işlem sektörünün içindeyim. Bu blogu 2020'de, işimde her gün karşılaştığım sorunların çözümlerini bir yere yazmak için açtım: Linux, güvenlik, tarayıcılar, yapay zeka araçları. Yazdığım her rehberi önce kendi bilgisayarımda ya da sunucumda deniyorum; çalıştığını görmediğim adımı yayınlamam. Hatalı ya da eskimiş bir şey görürsen iletişim sayfasından yaz — düzeltirim.