ZFS Nedir, Avantajları Neler

Bir sunucuda diskin sessizce veri bozması, yıllarca fark edilmeyen ama bir gün yedekten geri dönerken ortaya çıkan en sinir bozucu problemdir. Klasik bir ext4 kurulumunda dosya sisteminiz, diskten okuduğu baytların doğru olup olmadığını bilmez; disk ne verirse onu uygulamaya teslim eder. ZFS nedir sorusunun en kısa cevabı tam olarak burada saklı: ZFS, her veri bloğunun doğruluğunu kriptografik bir sağlama toplamıyla denetleyen, bozuk bloğu yedeğinden kendi kendine onaran ve bunu yaparken anlık görüntü, sıkıştırma, havuz yönetimi gibi işleri de üstlenen birleşik bir depolama katmanıdır.

Bu rehberde ZFS'in klasik dosya sistemlerinden neden yapısal olarak farklı olduğunu, pool ve vdev kavramlarını, copy-on-write mantığının snapshot'ları neden neredeyse bedava hale getirdiğini, scrub ile sessiz veri bozulmasının nasıl yakalandığını ve gerçek bir sunucuda hangi komutlarla yönetildiğini anlatacağım. Ayrıca RAM gereksinimi, sanal sunucularda ZFS kullanımı ve en sık düşülen tuzaklar gibi, dökümanlarda geçmeyip pratikte insanın başını ağrıtan konulara ayrı bölümler ayırdım.

ZFS'i Klasik Dosya Sistemlerinden Ayıran Şey#

Geleneksel Linux depolama yığını üç ayrı katmandan oluşur: en altta ham diskler, ortada RAID ya da LVM gibi bir birim yöneticisi, en üstte ext4 veya XFS gibi bir dosya sistemi. Bu katmanlar birbirinden habersizdir. RAID katmanı iki diskteki bloğun farklı olduğunu görse bile hangisinin doğru olduğunu bilemez, çünkü içeriğin ne anlama geldiğine dair bir bilgisi yoktur. Dosya sistemi ise altındaki diskin kaç kopya tuttuğunu bilmez; bozuk veri geldiğinde onu olduğu gibi uygulamaya aktarır.

ZFS bu üç katmanı tek bir yazılımda birleştirir. Hem birim yöneticisidir hem dosya sistemidir. Bir bloğu okurken sağlama toplamını doğrular, tutmazsa aynı bloğun aynadaki ya da pariteden hesaplanan kopyasını okur, onu doğrular ve bozuk kopyayı sessizce düzeltir. Bu tek özellik bile ZFS'i tercih etmek için yeterli sebeptir. Bunun üzerine copy-on-write yazma modeli, sınırsıza yakın anlık görüntü, blok seviyesinde sıkıştırma, dataset başına ayrı ayar ve zfs send ile blok seviyesinde artımlı çoğaltma gelir. Disk sağlığını takip etme alışkanlığınız yoksa önce disk arızası tespiti ve SMART yazısına göz atmanızı öneririm; ZFS bozulmayı yakalar ama diskin ne zaman öleceğini SMART verisi söyler.

Pool, vdev ve Dataset: ZFS'in Üç Katmanı#

ZFS ile çalışırken kafa karışıklığının çoğu bu üç terimin karıştırılmasından doğar. En alttaki yapı vdev'dir (virtual device). Bir vdev; tek bir disk, iki diskten oluşan bir ayna (mirror) ya da üç veya daha fazla diskten oluşan bir raidz grubu olabilir. Dayanıklılık vdev seviyesinde tanımlanır, pool seviyesinde değil.

Pool (zpool), bir veya birden fazla vdev'in bir araya gelmesiyle oluşan depolama havuzudur. Yazılan veri vdev'ler arasında dağıtılır. Kritik nokta şudur: bir pool içindeki herhangi bir vdev tamamen kaybolursa pool'un tamamı kaybolur. Yani üç aynalı vdev'den oluşan bir havuzda bir vdev'in her iki diski birden ölürse, diğer vdev'lerdeki veriler de erişilemez hale gelir. En üstte ise dataset bulunur; pool içinde oluşturduğunuz, ayrı ayrı ayarlanabilen mantıksal dosya sistemleridir.

Basit bir aynalı havuz kurmak tek komuttur:

# İki diskten aynalı (mirror) bir havuz oluştur
zpool create -o ashift=12 tank mirror /dev/sdb /dev/sdc

# Havuzun durumunu gör
zpool status tank

# Kullanılabilir alanı gör
zpool list

Buradaki ashift=12 parametresi 4K sektörlü diskler için doğru hizalamayı zorlar ve havuz oluşturulduktan sonra değiştirilemez. Yanlış ashift ile kurulmuş bir havuzun tek çaresi yeniden kurmaktır, bu yüzden ilk komutta atlamayın.

Copy-on-Write ve Anlık Görüntüler#

ZFS hiçbir zaman bir bloğun üzerine yazmaz. Bir dosyayı değiştirdiğinizde değişen blok diskte yeni bir yere yazılır, sonra üst seviyedeki işaretçi atomik olarak yeni bloğu gösterecek şekilde güncellenir. Buna copy-on-write denir ve iki büyük sonucu vardır. Birincisi, elektrik kesintisi sırasında dosya sistemi asla yarım bir duruma düşmez; ya eski hâli ya yeni hâli geçerlidir, fsck kavramı ZFS'te yoktur. İkincisi, anlık görüntü almak neredeyse bedava hale gelir.

Bir snapshot almak, o andaki blok işaretçilerini dondurmaktan ibarettir; hiçbir veri kopyalanmaz. Snapshot ilk alındığında sıfır bayt yer kaplar, sonrasında yalnızca değişen bloklar kadar büyür. Bu yüzden saatlik snapshot almak bile makul bir alışkanlıktır:

# Anlık görüntü al
zfs snapshot tank/web@2026-08-25-1200

# Tüm snapshot'ları listele
zfs list -t snapshot

# Tek bir dosyayı snapshot'tan geri al (gizli .zfs dizini)
cp /tank/web/.zfs/snapshot/2026-08-25-1200/index.php /tank/web/index.php

# Dataset'i tamamen o ana geri döndür
zfs rollback tank/web@2026-08-25-1200

Dikkat: zfs rollback o snapshot'tan sonra alınmış tüm snapshot'ları ve verileri siler. Bir güncelleme öncesi snapshot alıp güncelleme patlarsa saniyeler içinde geri dönebilirsiniz, ama bunu yaparken aradaki değişiklikleri kaybedeceğinizi bilerek yapın.

Checksum, Scrub ve Sessiz Veri Bozulması#

Sessiz veri bozulması (silent data corruption), diskin hata bildirmeden yanlış veri döndürmesidir. Kablo teması, RAM hatası, kontrolcü arızası ya da diskin kendi firmware hatası bunu tetikleyebilir. Klasik yığında hiçbir katman bunu fark etmez; dosya bozulur ve bozuk hâli yedeklere de kopyalanır.

ZFS her bloğun sağlama toplamını üst seviyedeki blokta saklar, yani veriyle sağlama toplamı aynı yerde durmaz. Okuma sırasında hesaplanan değer eşleşmezse ZFS yedek kopyaya döner. Bu denetimi tüm havuza periyodik olarak uygulamak için scrub çalıştırılır:

# Tüm havuzu baştan sona doğrula
zpool scrub tank

# İlerlemeyi izle
zpool status -v tank

# Aylık scrub için cron girdisi (her ayın ilk pazarı 03:00)
# 0 3 1-7 * 0 /sbin/zpool scrub tank

zpool status çıktısındaki CKSUM sütunu sıfırdan farklıysa o diskte doğrulanamayan bloklar bulunmuş demektir. Tek bir hata kabloyu kontrol etmeniz için yeterli bir uyarıdır; sayı artıyorsa disk değişimi planlayın. Scrub'ı ayda bir çalıştırmak yaygın bir alışkanlıktır; disk yükünü artırdığı için yoğun saat dışında planlayın.

Sıkıştırma, ARC ve Gerçek Performans#

ZFS'in en çok küçümsenen özelliği blok seviyesinde sıkıştırmadır. Modern varsayılan olan lz4 algoritması o kadar hızlıdır ki sıkışan veri için diskten daha az bayt okunur ve toplam performans genellikle artar. Sıkışmayan veriyi (zaten sıkıştırılmış görüntü, video, arşiv) algoritma erken tespit edip olduğu gibi yazar, yani ceza ödemezsiniz.

# Sıkıştırmayı aç (yeni yazılan bloklara uygulanır)
zfs set compression=lz4 tank/web

# Sıkıştırma oranını gör
zfs get compressratio tank/web

# Erişim zamanı yazımını kapat (gereksiz yazma yükünü düşürür)
zfs set atime=off tank/web

Okuma önbelleği olan ARC, boştaki RAM'i kullanarak sık okunan blokları bellekte tutar. Varsayılan olarak sistem RAM'inin yarısına kadar büyüyebilir ve uygulama bellek istediğinde küçülür. Yine de veritabanı gibi kendi tamponunu yöneten uygulamalarla aynı makinede çalışıyorsanız ARC'ye tavan koymak mantıklıdır:

# /etc/modprobe.d/zfs.conf — ARC'yi 4 GB ile sınırla
options zfs zfs_arc_max=4294967296

Veritabanları için bir uyarı: ZFS'in varsayılan 128K kayıt boyutu, 8K veya 16K sayfalarla çalışan veritabanlarında okuma büyütmesine yol açar. PostgreSQL için recordsize=8K, MySQL InnoDB için recordsize=16K ayarlamak ölçülebilir fark yaratır. Bu ayar yalnızca sonradan yazılan verilere uygulanır, önce ayarlayıp sonra veriyi taşımanız gerekir.

RAM, Donanım ve Sanal Sunucularda ZFS#

ZFS hakkındaki en yaygın efsane "her terabayt için 1 GB RAM şarttır" cümlesidir. Bu kural, veri tekilleştirme (dedup) açıkken doğrudur; dedup tablosu gerçekten RAM canavarıdır. Dedup kapalıyken ZFS 2 GB RAM'li bir makinede de çalışır, sadece ARC küçük olduğu için okuma önbelleğinden az fayda görürsünüz. Pratik tavsiyem nettir: dedup'ı açmayın, onun yerine sıkıştırmayı açın; kazancın büyük kısmını maliyetin çok küçük bir kısmıyla alırsınız.

Donanım tarafında altın kural, ZFS'e ham disk vermektir. Donanımsal RAID kartının arkasına ZFS koymak, ZFS'in bozuk bloğu onarmak için ihtiyaç duyduğu ikinci kopyaya erişimini engeller; RAID kartı diskleri gizler ve ZFS bir hata bulduğunda düzeltemez, sadece raporlar. RAID kartınız varsa HBA / IT moduna alın.

Sanal sunucularda ZFS elbette çalışır ama beklentiyi doğru kurun: VDS üzerindeki tek sanal diskte ZFS kullanmak size checksum, snapshot ve sıkıştırma kazandırır, fakat ikinci kopya olmadığı için otomatik onarım yapamaz. Gerçek dayanıklılık istiyorsanız birden fazla fiziksel diske doğrudan erişebildiğiniz dedicated sunucu tarafına geçmeniz gerekir.

Kurulum ve Günlük Yönetimde Temel Komutlar#

Debian ve Ubuntu üzerinde ZFS kurulumu paket yöneticisiyle yapılır; çekirdek modülü DKMS ile derlenir, bu yüzden çekirdek başlıklarının kurulu olması gerekir:

# Ubuntu / Debian
apt update
apt install -y zfsutils-linux

# Modülün yüklendiğini doğrula
modprobe zfs && zfs version

Günlük hayatta en çok kullanacağınız komutlar aslında bir avuçtur:

1. zpool status -v — havuzun sağlığı, hatalı diskler, devam eden scrub veya resilver.
2. zpool list ve zfs list — havuz ve dataset seviyesinde alan kullanımı.
3. zfs get all tank/web — bir dataset'in tüm ayarlarını görme.
4. zpool replace tank /dev/sdb /dev/sdd — ölen diski yenisiyle değiştirme.
5. zfs send -i ile artımlı çoğaltma — başka bir sunucuya blok seviyesinde yedek.

İkinci bir makineye çoğaltma, ZFS'in en güçlü ama en az kullanılan özelliğidir:

# İlk tam gönderim
zfs send tank/web@gunluk-1 | ssh [email protected] zfs recv yedek/web

# Sonraki günlerde sadece farkı gönder
zfs send -i tank/web@gunluk-1 tank/web@gunluk-2 | ssh [email protected] zfs recv yedek/web

Bu, dosya bazlı araçlardan çok daha hızlıdır çünkü ZFS hangi blokların değiştiğini zaten bilir; dizin taraması yapılmaz. Yine de bunun tek yedekleme stratejiniz olmaması gerekir; farklı bir teknolojiyle ikinci bir kopya için Borg ile sunucu yedekleme yazısındaki yaklaşımı paralel çalıştırmak akıllıcadır.

Sık Yapılan Hatalar ve Tuzaklar#

Havuzu yüzde 100'e kadar doldurmak. Copy-on-write yazma için boş blok gerektirir; havuz yüzde 90'ı geçtiğinde ZFS uygun blok aramaya başlar ve performans belirgin biçimde düşer. Yüzde 80'i uyarı, yüzde 90'ı kırmızı çizgi kabul edin. Alan kullanımını izleme alışkanlığı için disk kullanımı df, du ve ncdu yazısındaki yöntemler ZFS'te de geçerlidir, ama df yerine zfs list -o space çok daha doğru bilgi verir.

Snapshot'ı yedek sanmak. Snapshot aynı havuzda durur. Havuz ölürse, sunucu yanarsa ya da fidye yazılımı root erişimi kazanırsa snapshot'lar da gider. Snapshot hızlı geri dönüş aracıdır, yedek değildir; en az bir kopya başka bir makinede olmalıdır.

Disk aygıt adlarını kullanmak. /dev/sdb isimleri yeniden başlatmada değişebilir. Havuzu /dev/disk/by-id/ altındaki kalıcı isimlerle kurun; aksi halde disk sırası değiştiğinde havuz "DEGRADED" görünür ve gereksiz panik yaşarsınız.

RAM'in ECC olmamasını dert etmek. ECC bellek her sunucuda iyidir ama ZFS için zorunlu değildir. "ECC yoksa ZFS veriyi bozar" iddiası abartılıdır; ECC olmayan bir makinede ext4 de aynı riski taşır, üstelik hiç fark etmeden.

fstab'a elle satır eklemek. ZFS dataset'leri kendi mountpoint özelliğiyle bağlanır; /etc/fstab içine satır eklemek çakışmaya yol açar. Klasik dosya sistemleri için bağlama mantığını disk bağlama, mount ve fstab yazısında bulabilirsiniz, ancak ZFS'te doğru komut zfs set mountpoint=/srv/web tank/web biçimindedir.

Sıkça Sorulan Sorular#

ZFS ücretsiz mi, lisansı sorun çıkarır mı#

OpenZFS açık kaynaklıdır ve ücretsiz kullanılır. Lisansı CDDL olduğu için Linux çekirdeğinin GPL lisansıyla aynı ikili dosyada dağıtılamaz; bu yüzden Debian ve Ubuntu ZFS'i ayrı bir modül olarak sunar ve DKMS ile derler. Kullanıcı açısından pratik sonucu, çekirdek güncellemelerinden sonra modülün yeniden derlenmesi gerektiğidir; paket yöneticisi bunu genellikle otomatik yapar.

ZFS için gerçekten çok RAM gerekir mi#

Veri tekilleştirme kapalıysa hayır. ZFS boştaki RAM'i okuma önbelleği olarak kullanır ama uygulama bellek istediğinde bu önbelleği bırakır. 4 GB belleğe sahip küçük bir sunucuda ZFS sorunsuz çalışır, sadece önbellekten daha az fayda görürsünüz. RAM ihtiyacını gerçekten patlatan tek özellik dedup'tır; onu açmadığınız sürece bu efsaneyi dert etmeyin.

Snapshot ne kadar yer kaplar#

Alındığı anda sıfır bayt kaplar. Copy-on-write sayesinde snapshot yalnızca o andan sonra değişen veya silinen blokları tutar; dolayısıyla veri ne kadar çok değişirse snapshot o kadar büyür. Günde birkaç dosyanın değiştiği bir web dizininde haftalık snapshot'lar megabaytlar seviyesinde kalır. Gerçek boyutu zfs list -t snapshot -o name,used komutuyla görebilirsiniz.

ZFS havuzunu sonradan büyütebilir miyim#

Evet, ancak yöntemi doğru seçmeniz gerekir. Havuza yeni bir vdev ekleyerek alanı büyütebilirsiniz; bu en yaygın yoldur. Mevcut bir mirror vdev'deki diskleri teker teker daha büyükleriyle değiştirip autoexpand=on ayarıyla da genişletebilirsiniz. Buna karşılık eklenen bir vdev'i havuzdan çıkarmak çoğu yapılandırmada mümkün değildir, o yüzden ekleme komutunu iki kez kontrol edin.

ZFS ext4 veya XFS'ten yavaş mı#

Tek bir metrikle cevaplanamaz. Sıralı büyük okuma-yazmalarda ZFS rekabetçidir, hatta sıkıştırma sayesinde öne geçebilir. Çok küçük ve senkron yazmalarda (veritabanı transaction log'u gibi) copy-on-write ve checksum ek yükü hissedilir; bu senaryoda recordsize ayarını uygulamanın sayfa boyutuna göre ayarlamak ve gerekiyorsa ayrı bir SLOG aygıtı kullanmak farkı kapatır. Pratikte kaybettiğiniz performans, kazandığınız veri bütünlüğü ve snapshot esnekliğinin yanında çoğu iş yükü için makul kalır.

Tek diskli bir sunucuda ZFS kullanmanın anlamı var mı#

Kısmen var. Tek diskte ZFS bozulmayı tespit eder ama onaracak ikinci kopyası olmadığı için düzeltemez; yine de bozuk veriyi sessizce uygulamaya vermek yerine hata döndürür, bu bile değerlidir. Ayrıca snapshot, sıkıştırma ve zfs send ile artımlı çoğaltma özelliklerinden tek diskte de tam olarak faydalanırsınız. Kritik dataset'lerde copies=2 ayarıyla aynı disk üzerinde ikinci bir kopya tutup sınırlı bir onarım kabiliyeti de kazanabilirsiniz.

Kapanış#

ZFS'i tek cümleyle özetlemek gerekirse: verinin doğru olduğunu kanıtlayan bir depolama katmanıdır. Günlük hayatta bunun karşılığı birkaç sağlam alışkanlıktır. Havuzu by-id isimleriyle ve doğru ashift ile kurun. Sıkıştırmayı açın, dedup'a dokunmayın. Ayda bir scrub çalıştırın ve zpool status çıktısındaki CKSUM sütununu takip edin. Snapshot'ları sık alın ama onları yedek yerine koymayın; en az bir kopyayı zfs send ile başka bir makineye taşıyın. Havuzu yüzde 80'in üzerine çıkarmamaya çalışın.

Bu yapıyı kendi elinizle kurmak isterseniz tam root erişimi ve birden fazla diske doğrudan erişim gerekir; dedicated sunucu paketlerimiz ZFS için en uygun zemini sunar, daha küçük ölçekte deneme yapmak isterseniz VDS sunucularımız üzerinde tek diskli bir havuzla başlayabilirsiniz. Kurulumu ve scrub takibini kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmetimiz bu işi devralır; havuz dışında bağımsız bir yedek katmanı için de yedekleme çözümlerimize bakabilirsiniz.