LVM Snapshot Alma ve Birim Genişletme

Bir sunucuda disk dolduğunda en kötü senaryo, bölümün ham diske doğrudan yazılmış olması ve genişletmek için makineyi kapatıp kurtarma ortamından bölüm tablosuyla uğraşmak zorunda kalmanızdır. LVM tam olarak bu senaryoyu ortadan kaldırmak için var: diskleri fiziksel bölümlerden soyutlayıp mantıksal birimlere çevirir, böylece bir birimi sistem çalışırken büyütebilir, farklı disklere yayabilir ve risk almadan anlık görüntü alabilirsiniz. LVM snapshot ve birim genişletme, bu esnekliğin günlük hayatta en çok kullanılan iki yüzüdür.

Bu rehberde LVM'in üç katmanını netleştirip önce mevcut durumu nasıl okuyacağınızı, sonra bir mantıksal birimi kesinti olmadan nasıl büyüteceğinizi, birim grubuna nasıl yeni disk ekleyeceğinizi, snapshot'ın arka planda nasıl çalıştığını ve neden dolduğunda geçersiz hale geldiğini anlatacağım. Ayrıca thin provisioning ile klasik snapshot arasındaki farkı ve en sık düşülen tuzakları ayrı bölümlerde toplayacağım; çünkü LVM'de yapılan hataların çoğu geri alınamaz sınıftadır.

LVM'in Üç Katmanı: PV, VG ve LV#

LVM'i anlamanın en hızlı yolu üç harfi doğru yerleştirmektir. En altta PV (Physical Volume) bulunur: LVM'e verilmiş ham bir disk ya da disk bölümü. Ortada VG (Volume Group) vardır: bir veya daha fazla PV'nin birleşmesiyle oluşan tek bir alan havuzu. En üstte ise LV (Logical Volume) yer alır: bu havuzdan kestiğiniz, dosya sistemi oluşturup bağladığınız mantıksal birim.

Bu üç katman sayesinde /var dizininiz aslında iki farklı fiziksel diske yayılmış olabilir ve siz bunu hiç fark etmezsiniz. Yeni bir disk taktığınızda onu PV yapıp birim grubuna eklersiniz, birim grubu büyür, oradan istediğiniz LV'ye alan aktarırsınız. Klasik bölüm tablosunda bu esneklik yoktur; bölümler diskte fiziksel olarak yan yanadır ve ortadakini büyütmek için sonrakini taşımanız gerekir. Bölüm tablosu mantığına hiç bakmadıysanız disk bölümleme, fdisk ve parted yazısı LVM'in neyi çözdüğünü daha net gösterir.

Mevcut Durumu Okumak#

Herhangi bir değişiklik yapmadan önce elinizde ne olduğunu görmelisiniz. Üç kısa komut resmin tamamını verir:

# Fiziksel birimler ve hangi VG'ye ait oldukları
pvs

# Birim grupları ve boştaki alan (VFree sütunu kritik)
vgs

# Mantıksal birimler, boyutları ve hangi diskte durdukları
lvs -a -o +devices

Tipik bir vgs çıktısı şöyle görünür:

  VG   #PV #LV #SN Attr   VSize    VFree
  vg0    1   2   0 wz--n- <99.00g  20.00g

Buradaki VFree sütunu, birim grubunda dağıtılmamış olarak duran alanı gösterir. Genişletme yapabilmek için ya bu değerin sıfırdan büyük olması ya da önce gruba yeni bir disk eklemeniz gerekir. Dosya sistemi seviyesindeki doluluk için df -h, hangi dizinin şiştiğini bulmak için ise disk kullanımı df, du ve ncdu yazısındaki yöntemler işinizi görür. Bazen sorun alan değil inode tükenmesidir; o durumda genişletme sorunu çözmez, bu yüzden df -i çıktısına da bakın.

Mantıksal Birimi Genişletme#

Birim grubunda boş alan varsa genişletme iki adımdır: önce LV büyütülür, sonra üzerindeki dosya sistemi bu yeni alanı görecek şekilde uzatılır. Modern lvextend sürümlerinde -r bayrağı ikinci adımı otomatik yapar ve doğru aracı kendisi seçer:

# 20 GB ekle ve dosya sistemini de otomatik büyüt
lvextend -r -L +20G /dev/vg0/data

# Ya da gruptaki tüm boş alanı bu birime ver
lvextend -r -l +100%FREE /dev/vg0/data

-r bayrağını kullanmak istemez ya da eski bir sürümle çalışıyorsanız iki adımı elle yaparsınız. Burada dosya sistemi tipini doğru seçmek şart:

# Önce mantıksal birimi büyüt
lvextend -L +20G /dev/vg0/data

# ext4 ise
resize2fs /dev/vg0/data

# XFS ise (bağlama noktası verilir, aygıt değil)
xfs_growfs /mnt/data

Her iki dosya sistemi de bağlıyken büyütülebilir; sunucuyu kapatmanıza gerek yoktur. Küçültme tarafı ise çok farklıdır: XFS küçültmeyi hiç desteklemez, ext4 destekler ama yalnızca dosya sistemi ayrılmışken ve mutlaka LV'yi küçültmeden önce resize2fs ile küçültmek gerekir. Sıralamayı ters çevirirseniz dosya sisteminin sonundaki veriyi kesip atarsınız ve geri dönüşü olmaz. Pratik tavsiyem: küçültmeye hiç kalkışmayın, yeni bir LV oluşturup veriyi taşıyın.

Birim Grubuna Yeni Disk Ekleme#

Boş alan kalmadıysa önce havuzu büyütmeniz gerekir. Sanal bir sunucuda yeni disk eklediğinizde ya da fiziksel makineye disk taktığınızda izlenecek adımlar şunlardır:

1. Yeni aygıtın göründüğünü doğrulayın: lsblk çıktısında örneğin /dev/sdb belirir.
2. İsterseniz üzerinde bölüm açın, ama LVM için şart değildir; tüm diski doğrudan PV yapabilirsiniz.
3. Diski fiziksel birime dönüştürün.
4. Birim grubuna ekleyin.
5. Alanı istediğiniz mantıksal birime aktarın.

# Yeni diski LVM'e tanıt
pvcreate /dev/sdb

# Mevcut birim grubuna ekle
vgextend vg0 /dev/sdb

# Havuzun büyüdüğünü doğrula
vgs

# Tüm yeni alanı data birimine ver ve dosya sistemini uzat
lvextend -r -l +100%FREE /dev/vg0/data

Bu işlemlerin hiçbiri yeniden başlatma gerektirmez. Sanal disk boyutunu hipervizör tarafında büyüttüyseniz ve yeni boyut işletim sisteminde görünmüyorsa, çekirdeğe diski yeniden taratmanız gerekir; canlı sistemde disk büyütmenin tüm ayrıntıları için canlı sistemde disk genişletme yazısına bakın. Bağlama noktalarının yeniden başlatmadan sonra da doğru kalması için /etc/fstab girdilerini UUID ile yazmayı unutmayın; konuyu disk bağlama, mount ve fstab yazısında ayrıntılı ele aldım.

LVM Snapshot Arka Planda Nasıl Çalışır#

Klasik LVM snapshot'ı, ZFS ya da Btrfs snapshot'ından farklı bir mantıkla çalışır ve bu farkı bilmemek en yaygın LVM kazasının sebebidir. Snapshot aldığınızda LVM, veriyi kopyalamaz; bunun yerine snapshot için ayrı bir alan ayırır ve orijinal birimdeki bir blok değiştirilmek üzereyken o bloğun eski hâlini bu ayrılmış alana kopyalar. Buna copy-on-write tablosu denir.

Bunun iki sonucu var. Birincisi, snapshot yalnızca değişen bloklar kadar yer kaplar; hiçbir şey değişmezse neredeyse hiç yer tutmaz. İkincisi ve kritik olanı, ayrılan alan dolarsa snapshot geçersiz hale gelir ve içeriğine bir daha erişemezsiniz. Orijinal birim etkilenmez ama snapshot çöpe gider. Bu yüzden snapshot boyutunu, snapshot'ın yaşayacağı süre boyunca beklenen değişim miktarına göre seçmelisiniz.

Bir başka önemli nokta performanstır: snapshot açıkken orijinal birime yapılan her yeni yazma, önce eski bloğun kopyalanmasını gerektirir. Yani yazma yükü kabaca ikiye katlanır. Bu yüzden LVM snapshot'ları uzun süre açık tutulmaz; yedek alınır, doğrulanır ve snapshot silinir.

Snapshot Alma, Kullanma ve Geri Dönme#

Tipik kullanım senaryosu şudur: riskli bir güncelleme ya da tutarlı bir yedek almadan önce snapshot alırsınız, işiniz bittiğinde ya silersiniz ya da geri dönersiniz.

# 5 GB copy-on-write alanıyla snapshot al
lvcreate -s -n data_snap -L 5G /dev/vg0/data

# Snapshot'ı salt okunur bağlayıp içeriğine bak
mkdir -p /mnt/snap
mount -o ro /dev/vg0/data_snap /mnt/snap

# Doluluk oranını izle (Data% sütunu %100'e yaklaşmamalı)
lvs -o +snap_percent

# İşin bitince önce ayır, sonra sil
umount /mnt/snap
lvremove -y /dev/vg0/data_snap

Geri dönmek isterseniz lvconvert --merge kullanılır. Bu komut snapshot'taki eski blokları orijinal birime geri yazar ve işlem bittiğinde snapshot otomatik olarak silinir:

# Snapshot'ı orijinal birime geri birleştir
lvconvert --merge /dev/vg0/data_snap

Önemli ayrıntı: birleştirme yalnızca birim kullanımda değilken tamamlanır. Hedef birim bağlıysa komut "birleştirme bir sonraki etkinleştirmede yapılacak" der; kök dosya sistemi için bu pratikte yeniden başlatma anlamına gelir. Bunu bir bakım penceresi gerektiren işlem olarak planlayın.

Snapshot'ın en değerli kullanımı ise tutarlı yedek almaktır. Çalışan bir veritabanının dosyalarını doğrudan kopyalamak tutarsız bir kopya üretir; bunun yerine veritabanını kısa süre için tutarlı bir noktaya getirip snapshot alır, sonra snapshot üzerinden sakin sakin yedeklersiniz. Yedeği başka bir makineye taşımak için de Borg ile sunucu yedekleme yazısındaki artımlı yaklaşım iyi eşleşir.

Thin Provisioning ve Thin Snapshot#

Klasik snapshot'ın "alanı önceden ayır, dolarsa kaybet" davranışı can sıkıcıdır. LVM'in thin provisioning özelliği bunu çözer. Önce bir thin pool oluşturursunuz, sonra bu havuzdan sanal boyutlu birimler açarsınız; birimler yalnızca gerçekten yazılan blok kadar yer kaplar.

# Birim grubunda 100 GB'lık bir thin havuz oluştur
lvcreate --type thin-pool -L 100G -n pool0 vg0

# Havuzdan 200 GB "sanal" boyutlu bir birim aç
lvcreate -T vg0/pool0 -V 200G -n data

# Thin snapshot: boyut belirtmeye gerek yok
lvcreate -s -n data_snap vg0/data

# Havuz doluluğunu izle
lvs -o +data_percent,metadata_percent

Thin snapshot boyut ayırmaz, dolayısıyla "snapshot doldu ve geçersiz oldu" sorunu ortadan kalkar. Karşılığında yeni bir risk gelir: havuzun kendisi dolarsa içindeki tüm birimler yazma hatası almaya başlar. Yani sorumluluk snapshot boyutundan havuz doluluğunu izlemeye kayar. Thin havuz kullanıyorsanız data_percent değerine bir uyarı eşiği koyun; yüzde 80 makul bir sınırdır. Havuz dolduğunda yaşanacak "no space left on device" hatalarının genel çözüm yolları için disk dolu, no space left çözümü yazısına bakabilirsiniz.

Sık Yapılan Hatalar ve Tuzaklar#

Dosya sistemini büyütmeyi unutmak. lvextend çalıştırıp df -h çıktısında değişiklik göremeyince panik yapılır. Mantıksal birim büyümüştür ama dosya sistemi hâlâ eski boyutu bilir. -r bayrağını kullanın ya da resize2fs / xfs_growfs adımını atlamayın.

Küçültmede sırayı ters yapmak. ext4 küçültürken önce resize2fs ile dosya sistemi, sonra lvreduce ile birim küçültülür. Ters sıra veri kaybıdır ve geri dönüşü yoktur. XFS'te ise küçültme diye bir şey yoktur; ısrar etmeyin.

Snapshot'ı yedek sanmak. Snapshot orijinal birimle aynı birim grubunda, çoğu zaman aynı fiziksel diskte durur. Disk ölürse ikisi de gider. Snapshot tutarlı bir kopya almanızı sağlayan geçici bir araçtır; gerçek yedek başka bir makinede durur.

Snapshot'ı silmeyi unutmak. Açık kalan bir snapshot hem yazma performansını düşürür hem de sessizce dolup geçersiz hale gelir. Yedek betiğinizin sonuna lvremove adımını ekleyin ve betiğin hata durumunda da temizlik yapmasını sağlayın.

Tek PV üzerinde yanlış güven. LVM bir RAID değildir. Birim grubundaki bir PV kaybolursa, o PV'de blokları bulunan tüm LV'ler bozulur. Dayanıklılık istiyorsanız altına RAID koyun ya da checksum ve onarım yeteneği olan bir dosya sistemi tercih edin; farkları ZFS nedir ve avantajları yazısında karşılaştırdım.

vgs çıktısına bakmadan komut yazmak. Genişletme komutu boş alan yoksa hata verir ve bu iyi bir şeydir; ama önce vgs çalıştırıp VFree değerini görmek, gereksiz deneme yanılmayı ortadan kaldırır.

Sıkça Sorulan Sorular#

LVM birimini genişletmek kesinti gerektirir mi#

Hayır. Hem lvextend hem de ext4 ve XFS'in büyütme komutları dosya sistemi bağlıyken çalışır; servisleri durdurmanıza veya sunucuyu yeniden başlatmanıza gerek yoktur. Kesinti gerektiren tek senaryo küçültmedir, çünkü ext4'ü küçültmek için dosya sistemini ayırmanız gerekir. Sanal disk boyutunu hipervizör tarafında büyüttüyseniz, çekirdeğin yeni boyutu görmesi için diski yeniden taratmak yeterlidir.

LVM snapshot ne kadar yer ayırmalıyım#

Snapshot'ın açık kalacağı süre boyunca orijinal birimde değişmesi beklenen veri miktarı kadar. Bir saatlik yedek penceresinde birkaç yüz megabayt değişen bir web dizini için 2-5 GB fazlasıyla yeterlidir; yoğun yazma alan bir veritabanı için çok daha büyük düşünmeniz gerekir. Ayrılan alan dolarsa snapshot geçersiz olur, bu yüzden lvs -o +snap_percent ile doluluğu izleyin veya thin snapshot kullanın.

LVM snapshot performansı ne kadar düşürür#

Klasik snapshot açıkken orijinal birime yapılan her yazma, önce eski bloğun copy-on-write alanına kopyalanmasını gerektirir; pratikte yazma yükü kabaca ikiye katlanır ve gecikme artar. Bu yüzden snapshot uzun süre açık bırakılmaz. Thin snapshot'larda bu ek yük belirgin biçimde daha düşüktür, çünkü havuz zaten blok bazlı çalışır ve ayrı bir kopyalama tablosu tutulmaz.

LVM birimi küçültebilir miyim#

XFS ile hayır, XFS küçültmeyi desteklemez. ext4 ile teknik olarak mümkündür ama dosya sistemini ayırmanız, önce resize2fs ile dosya sistemini küçültmeniz, ardından lvreduce ile birimi küçültmeniz gerekir. Sıra hatası veri kaybıdır. Pratikte önerim küçültmeye hiç girişmemek: yeni bir birim oluşturup veriyi kopyalamak hem güvenli hem de geri alınabilir bir yoldur.

LVM RAID yerine geçer mi#

Hayır. LVM varsayılan haliyle alanı yönetir, veriyi çoğaltmaz. Birim grubundaki bir fiziksel birim kaybolursa o diskte blokları bulunan tüm mantıksal birimler bozulur. LVM'in kendi RAID desteği (lvcreate --type raid1) vardır ve kullanılabilir, ama kurulumların çoğunda dayanıklılık ya donanım RAID ile ya mdadm ile ya da ZFS gibi bütünleşik bir dosya sistemiyle sağlanır.

Snapshot'tan geri dönmek ne kadar sürer#

Süre, snapshot alındıktan sonra değişen veri miktarına bağlıdır; birleştirme işlemi yalnızca değişmiş blokları geri yazar. Birkaç yüz megabaytlık değişim saniyeler sürer, onlarca gigabayt değişim dakikalar alabilir. Asıl gecikme kaynağı işlemin kendisi değil, birimin kullanımda olmasıdır: bağlı bir birimde birleştirme bir sonraki etkinleştirmeye ertelenir ve kök dosya sistemi için bu yeniden başlatma anlamına gelir.

Kapanış#

LVM'in değeri, depolamayı diskin fiziksel düzeninden kurtarmasında. Günlük hayatta bu birkaç sağlam alışkanlığa dönüşür: değişiklik yapmadan önce pvs, vgs ve lvs çıktılarını okuyun; genişletmede -r bayrağını kullanıp dosya sistemi adımını atlamayın; küçültmeye hiç kalkışmayın; snapshot'ı yedek değil geçici bir araç olarak görün ve işiniz bitince silin; thin havuz kullanıyorsanız doluluk oranına uyarı eşiği koyun. Bu beş madde, LVM ile yaşanan kazaların neredeyse tamamını önler.

Bu esnekliği kullanabilmek için disk ekleyip çıkarabildiğiniz ve tam root erişiminiz olan bir ortama ihtiyacınız var; VDS ve bulut sunucu paketlerimizde disk büyütmeyi panelden yapıp genişletmeyi işletim sistemi tarafında tamamlayabilirsiniz, birden fazla fiziksel disk üzerinde çalışmak isterseniz dedicated sunucu tarafı daha uygun olur. Birim planlamasını ve snapshot politikasını sizin yerinize kurmamızı isterseniz sunucu yönetimi hizmetimiz bu işi üstlenir; snapshot'tan bağımsız gerçek bir kopya için yedekleme sayfamıza göz atın.