Linux'ta Sunucuya Ek Disk Bağlama ve Mount Etme

Sunucuyu yeniden başlattınız ve açılmıyor. Konsol emergency mode üzerinde takılı kalmış ya da Failed to mount /mnt/data mesajı veriyor ve siz sadece yeni bir diskle değil, fstab hatasıyla karşı karşıyasınız. İşte tam da bu anda insan "mount etme"nin tek satırlık bir komut değil, operasyonel bir karar olduğunu anlar. Şu anda sunucuya ek diski bağladıysanız ve nereden başlayacağınızı bilmiyorsanız, iş sırası şöyledir: tanımlama, bölümleme, dosya sistemi oluşturma, geçici mount, test, sonra kalıcı hale getirme.

Önce kernel'in sunucuya ek diski görüp görmediğine bakın

Her şeyden önce diskin işletim sistemi düzeyinde görüldüğünden emin olmalısınız. Sunucu fizikselse ve diski yeni bir slot'a eklediyseniz, rescan gerekebilir:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
sudo partprobe
cat /proc/partitions

lsblk çıktısı mountpoint'siz bir cihaz göstermelidir, örneğin 500G boyutunda sdb. Eğer hiçbir şey görmüyorsanız, sorun bölümleme değil; sorun daha alt katmandadır. Sanal makinelerde diski panelden makineye attach etmiş olmalısınız ve sonrasında bir kez yeniden başlatma veya rescan gerekir. Bulut sunucularda genellikle disk attach işleminden hemen sonra görünür, ancak bazı platformlarda kapatıp açmadan cihaz /dev içinde oluşturulmaz.

Sunucuya ek diskte bölümleme ve dosya sistemi oluşturma

Veri diski için MBR değil GPT seçin. Nedeni basit: MBR'nin 2 terabayt sınırı vardır ve sonradan daha büyük bir disk bağlarsanız taşınmak zorunda kalırsınız. parted ile iş daha hızlı ilerler:

sudo parted /dev/sdb mklabel gpt
sudo parted -a optimal /dev/sdb mkpart primary ext4 0% 100%
sudo mkfs.ext4 -L data /dev/sdb1

-L data etiketini hafife almayın. Birden fazla diski olan sunucularda, donanım ekleme veya çıkarma sonrası cihaz adı yer değiştirir ve sdb bir gün sdc olabilir. LABEL veya UUID ile bu sorun çözülür.

Dosya sistemi seçimi gerçek bir karardır, zevk meselesi değil. Genel amaçlı bir sunucuda veri diski için ext4 benim varsayılan tercihimdir: kararlı, onarım araçları olgun ve yük altında davranışı öngörülebilir. XFS'i büyük dosyalar ve yoğun eşzamanlı yazma olduğunda seçerim; örneğin yedek deposu veya birkaç gigabaytlık dosyalarla çalışan veritabanı diski. XFS küçültülemez, yalnızca büyütülebilir. Bir gün boyutu küçültmeniz gerekebileceğini düşünüyorsanız, baştan ext4 seçin.

Geçici mount, test ve sonra kalıcı hale getirme

Asla doğrudan fstab'a gitmeyin. Önce geçici olarak mount edin ve yazıp okuyun:

sudo mkdir -p /mnt/data
sudo mount /dev/sdb1 /mnt/data
sudo chown deploy:deploy /mnt/data
echo test | sudo tee /mnt/data/probe.txt
df -h /mnt/data

Eğer df doğru boyutu gösterdiyse ve dosya yazıldıysa, şimdi kalıcı hale getirme zamanı. UUID'yi alın:

sudo blkid /dev/sdb1

Ve fstab satırını cihaz adıyla değil, UUID ile yazın:

UUID=8f3c1a2e-... /mnt/data ext4 defaults,nofail 0 2

Bu satırdaki iki nokta, sağlıklı bir yeniden başlatma ile emergency mode'daki bir sunucu arasındaki farktır. Birincisi, nofail: disk herhangi bir nedenle hazır değilse, boot durmaz. İkincisi, son sütun 1 değil 2'dir. 1 sayısı kök (/) için ayrılmıştır ve veri diskine verirseniz fsck yanlış sırada çalışabilir. Kök olmayan dosya sistemleri için 2 veya 0 koyun.

Yeniden başlatmadan önce her zaman şunu çalıştırın:

sudo mount -a
sudo findmnt --verify

Eğer mount -a hatasız döndüyse, sağlıklı bir boot olasılığı yüksektir. Hata verdiyse, orada düzeltin; yeniden başlatmadan sonra değil, çünkü o zaman elinizde sadece konsol olur.

İşte burada hata yapıyorlar

Gerçekten gördüğüm en yaygın hata: fstab satırını UUID yerine cihaz adıyla (/dev/sdb1) yazmak ve ardından başka bir disk eklemek. Belirtisi de şudur: sunucu yeniden başlatmadan sonra emergency mode üzerinde durur ve journalctl -xb Dependency failed for /mnt/data mesajını verir, oysa diskin kendisi sağlamdır. İkinci hata, kritik olmayan disklerde nofail'i unutmaktır. Daha az görülen ama pahalıya mal olan üçüncü hata: veri diskini önceden dosya bulunan bir yola mount etmek. Eğer /mnt/data dosyalarla doluysa ve diski üzerine mount ederseniz, o dosyalar mount noktasının altında gizlenir. Disk boyutu doludur, ama du tuhaf bir şey göstermez. Onları görmek için başka bir mount noktası veya bind mount kullanmanız gerekir.

Sunucuya ek diski fstab'a yanlış yazdığınızda ve sunucu açılmadığında

Çözüm, rescue modunda boot etmektir. Sunucu panelinden rescue mode'u etkinleştirin ve boot sonrası kök diski mount edip fstab dosyasını düzeltin. Rescue ile aşina değilseniz, Sunucu yeniden kurulumu ve rescue moduyla çalışma; erişimi kaybettiğinizde verileri kurtarma tam yolu adım adım açıklamıştır. Önemli nokta: rescue'da hatalı satırı yorum satırı haline getirin, tüm dosyayı silmeyin. Başarılı boot sonrası doğru UUID ile yeniden yazın.

Konsolda işe yarayan başka bir geçici çözüm daha var: GRUB'da e tuşuna basın ve kernel satırına systemd.unit=emergency.target ekleyin. Boot sonrası kök read-only olarak mount edilmiştir, bu yüzden önce mount -o remount,rw / çalıştırın ve sonra fstab'ı düzenleyin.

Servisler için kalıcı mount: systemd mount mu yoksa fstab mı?

Normal bir veri diski için fstab yeterlidir ve daha basittir. Ancak MySQL veya Docker gibi bir servis o yola bağımlıysa, boot sırası önem kazanır. Bu durumda systemd'nin bağımlılığı tam olarak yönetebilmesi için mount türünde bir unit yazın:

[Unit]
Description=Data disk
Before=mysql.service

[Mount]
What=/dev/disk/by-uuid/8f3c1a2e-...
Where=/mnt/data
Type=ext4
Options=defaults,nofail

[Install]
WantedBy=multi-user.target

Dosya adı mount yoluyla tam olarak uyumlu olmalıdır: mnt-data.mount. Adı yanlış koyarsanız, unit oluşturulur ama asla etkinleşmez ve siz çalıştığını sanırsınız. Bu yöntemin maliyeti daha fazla karmaşıklık ve daha zor hata ayıklamadır; bu nedenle yalnızca servis bağımlılığının gerçekten önemli olduğu yerlerde başvururum.

Performans hakkında bir not

Sunucuya ek disk NVMe türündeyse ve üzerinde veritabanı çalıştırıyorsanız, fstab satırına noatime seçeneğini ekleyin. Her dosya okuması erişim timestamp'ini güncellemez ve yoğun yazma yükü altında gözle görülür bir fark yaratır. Yalnızca yazma yapılan yedek diski için bu seçenek neredeyse etkisizdir ve kaldırabilirsiniz.

Mount ettikten sonra okuma ve yazma hızı beklenenden düşükse, ayarlarda herhangi bir değişiklik yapmadan önce Sunucu yüksek load nedeninin teşhisi; pratik ve adım adım rehber sayfasına bakın; çünkü çoğu durumda darboğaz disk değil, I/O kuyruğu veya başka bir servistir. Mevcut verileri yeni diske taşımak için de scp ve rsync ile dosya transferi; sunucu için pratik rehber güvenli seçenekleri kapsar.

Sunucunuz sanalsa ve diski panelden ekliyorsanız, attach davranışı Bulut sunucu ve Özel sunucu arasında biraz farklıdır; ilkinde genellikle yeniden başlatma olmadan görünür, ikincisinde denetleyici rescan'i gerekebilir. Daha hafif Linux ortamları için Linux hosting, aynı bölümleme ve mount döngüsünü fiziksel donanımla uğraşmadan geçirebileceğiniz bir seçenektir.

Sıkça sorulan sorular

fstab satırını ekledikten sonra sunucu neden emergency mode'da açılıyor?

Çünkü systemd, fstab'da tanımlanan diski mount edemez ve boot'u durdurur. Nedeni genellikle yanlış UUID, yer değiştirmiş cihaz adı veya nofail seçeneğinin olmamasıdır. Aynı konsolda journalctl -xb ile tam satır belirlenir.

fstab'da UUID ile LABEL arasındaki fark nedir ve hangisi daha iyidir?

UUID, dosya sistemi oluşturulurken üretilen benzersiz bir tanımlayıcıdır ve dosya sistemini yeniden oluşturmadığınız sürece değişmez. LABEL ise kendi verdiğiniz bir addır ve yanlışlıkla tekrarlanabilir. UUID daha güvenlidir; LABEL yalnızca fstab satırının okunabilir olmasını istediğinizde ve adların kontrolü sizde olduğunda faydalıdır.

Sunucuya ek diski mount etmeden önce biçimlendirmeli miyim?

Disk yeniyse evet; bölümleyip dosya sistemi oluşturmalısınız. Disk zaten veri içeriyorsa, biçimlendirme her şeyi siler. Önce blkid ve lsblk -f ile dosya sistemi olup olmadığına bakın, varsa yalnızca mount edin.

Diskin gerçekten kalıcı olarak mount edildiğini nasıl anlarım?

Yeniden başlatmadan sonra findmnt /mnt/data yolu ve UUID'yi göstermeli ve systemctl status mnt-data.mount active olmalıdır. Yeniden başlatmadan sonra mount edilmiyorsa ama elle çalışıyorsa, fstab satırınız hiç okunmamış ya da sözdizimi hatası var demektir.

Her yeniden başlatmadan önce mount -a ve findmnt --verify komutlarını çalıştırın. Bu iki komut, emergency mode'da takılan sunucuların en büyük kısmını kurtarır.