Sunucu kurtarma modu: Sistem açılmadığında

Sunucu yeniden başlatıldı ve geri dönmedi. Ping yanıt veriyor ama SSH 22 numaralı portta zaman aşımına uğruyor ya da konsol emergency mode durumunda takılıp root parolasını bekliyor. Bu görüntü tanıdık geliyorsa, sorun büyük olasılıkla ağ değil önyüklemedir ve çözüm çalışan işletim sisteminin içinden geçmez. Sunucuyu kurtarma modunda başlatmanız, ana diski elle bağlamanız, arızayı gidermeniz ve ardından normal önyüklemeye dönmeniz gerekir. Bu metin tam da bu yoldur, gerçekten çalıştırılan komutlarla birlikte.

Sunucu kurtarma modu tam olarak neyi başlatır

Kurtarma modunda sunucu, sizin diskinizden değil, ağdan veya ayrı bir imajdan küçük ve bağımsız bir işletim sistemi önyükler. Ana disk dokunulmadan kalır ve yalnızca bir blok aygıtı olarak kullanılabilir hale gelir. Yani dosya sisteminiz bağlı değildir, ondan hiçbir hizmet çalışmaz ve hiçbir süreç dosyaları kilitlememiştir. Kurtarma modunu onarım için kullanışlı kılan tam da bu özelliktir: /etc/fstab dosyasını düzenleyebilir, çekirdeği yeniden kurabilir veya root parolasını değiştirebilirsiniz; bozuk işletim sistemi size engel olmaz.

Çoğu kişinin geç fark ettiği nokta: kurtarma modunda sunucunun IP'si genellikle önceki IP değildir veya ağ arayüzü farklı bir adla açılır. Otomatik bir betikle eski IP'ye bağlanıp zaman aşımı alıyorsanız, önce panelde bildirilen adresi ve portu kontrol edin.

Her şeyden önce: doğru disk adını bulmak

Kurtarma modunda çalıştıracağınız ilk komut şudur:

lsblk -f

Çıktı şuna benzer bir şey verir:

NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
vda
└─vda1 ext4         4f9c1e2a-...                          /mnt
vdb    swap         8a3b7d10-...

Sanal sunucularda genellikle vda veya sda ana disktir ve kök bölüm vda1'dir. LVM'niz varsa, lsblk yalnızca vda2'yi gösterir ve bir adım daha ileri gitmeniz gerekir:

vgscan
vgchange -ay
lvs

vgchange -ay sonrasında ubuntu-vg/ubuntu-lv gibi bir adla mantıksal birim ortaya çıkar ve bağlamanız gereken şey tam da budur. Bu adımı atlayıp doğrudan bağlamaya geçerseniz special device /dev/mapper/... does not exist hatası alırsınız ve diskin kaybolduğunu düşünürsünüz. Kaybolmadı.

Ana diski bağlamak ve içine girmek

Bir bağlama noktası oluşturun ve kök bölümü bağlayın:

mkdir -p /mnt/root
mount /dev/vda1 /mnt/root

unknown filesystem type 'LVM2_member' mesajını aldıysanız, LVM bölümüne bağlama yapmışsınız demektir; vgchange adımına geri dönün. Structure needs cleaning veya bad superblock hatası gördüyseniz, dosya sistemi hasar görmüştür ve bağlamadan önce onarmanız gerekir:

fsck -y /dev/vda1

XFS dosya sistemlerinde fsck yerine xfs_repair /dev/vda1 kullanın; fsck XFS üzerinde çalışmaz ve yalnızca hata verir. Bu, dosya sistemi seçiminin krizin ortasında fark yarattığı yerlerden biridir.

Başarılı bağlamadan sonra, kök ortam içinde komut çalıştırabilmek için iki kritik yolu bind edin:

mount --bind /dev  /mnt/root/dev
mount --bind /proc /mnt/root/proc
mount --bind /sys  /mnt/root/sys
chroot /mnt/root /bin/bash

Bu andan itibaren isteminiz bozuk işletim sisteminin içindedir. Çalıştırdığınız her komut aynı disk üzerinde etki eder.

Sunucuyu önyüklemeden düşüren üç yaygın arıza

1. fstab hatası ve emergency mode'a düşme

Yeni bir disk ekledikten veya UUID'yi değiştirdikten sonra sistem emergency mode durumunda açılıyorsa, suçlu neredeyse her zaman /etc/fstab dosyasıdır. Tek bir yanlış satır, systemd'nin kökü tam olarak bağlamasını engellemeye yeter. chroot içinde dosyayı açın ve şüpheli satırı # ile yorum satırı haline getirin. Gerçek UUID'yi görmek için:

blkid

ve ardından satırı doğru değerle yazın:

UUID=4f9c1e2a-... / ext4 errors=remount-ro 0 1

Veri diskleri için nofail seçeneğini unutmayın; o olmadan, bir yan diskin olmaması tüm önyüklemeyi durdurur.

2. Güncelleme sonrası eksik çekirdek veya initramfs

Önyükleme Kernel panic - not syncing: VFS: Unable to mount root fs üzerinde duruyorsa, initramfs büyük olasılıkla doğru modüllerle oluşturulmamıştır. chroot içinde:

ls /boot
update-initramfs -u -k all
update-grub

RHEL ailesi dağıtımlarda eşdeğer komut dracut -f ve grub2-mkconfig -o /boot/grub2/grub.cfg'dir. /boot doluysa, initramfs oluşturma yarıda kalır ve aynı hata geri döner; df -h /boot ile kontrol edin.

3. Önyüklemeyi kilitleyen bir hizmet

Bazen işletim sistemi sağlıklıdır ama bozuk bir unit önyüklemeyi dakikalarca bekletir ve siz sunucunun öldüğünü düşünürsünüz. chroot içinde hangi unit'in beklediğine bakın:

systemctl list-jobs
systemctl status networking

Bir hizmet, başka bir hizmetin aldığı bir portta takılıyorsa veya döngüsel bir bağımlılığı varsa, systemctl disable ile geçici olarak önyükleme yolundan çıkarın. Doğru unit yapısını ve bağımlılıkları systemd'de unit dosyası: bölümler, yeniden başlatma ve bağımlılık sayfasında görebilirsiniz; tam orada After='ın Requires= olmadan önyüklemeyi neden kilitlemediği ama Requires='ın kilitlediği açıklanmıştır.

Burada hata yapıyorlar

En yaygın hata, kişinin kurtarma modunda diski bağlaması, dosyayı düzeltmesi ve ardından umount yapmadan sunucuyu yeniden başlatmasıdır. Sonuç: dosya sistemi dirty kalır ya da daha kötüsü, değişiklikler önbelleğe yazılmaz ve normal önyüklemeden sonra dosyanın hâlâ bozuk olduğunu görürsünüz. Belirtisi de şudur: her şey doğru görünüyordu ama sorun geri döndü. Doğru çıkış sırası şudur:

exit
umount -R /mnt/root
sync
reboot

İkinci hata: birinin fsck'yi bağlı bir dosya sistemi üzerinde çalıştırması. fsck, mount edilmiş bir dosya sistemi üzerinde veriyi gerçekten bozabilir, sadece uyarı vermez. filesystem is mounted mesajını görürseniz, önce unmount edin.

Normal önyüklemeye dönüş ve sonrasındaki kontroller

Yeniden başlatmadan sonra sistem açıldıysa iş bitmemiştir. Üç şeyi kontrol edin:

• Önyükleme anında disk veya I/O hatalarını görmek için dmesg -T | tail -50
• Açılmayan unit'leri görmek için systemctl --failed
• Bölümlerin doğru bağlandığından emin olmak için df -h ve free -m

Sunucu normal önyüklemeden sonra anormal yük gösteriyorsa, sorun önyükleme değildi ve başka bir yere bakmanız gerekir; Sunucu yüksek yükünün nedenini teşhis etme; pratik ve adım adım kılavuz doğru yoldur.

Bir sınırlamayı da açıkça söyleyeyim: kurtarma modu yazılım arızaları içindir, donanım arızaları için değil. smartctl -a /dev/vda yüksek Reallocated_Sector_Ct hatası gösteriyorsa veya disk lsblk'de hiç görünmüyorsa, dosya sistemi onarımı yalnızca zaman kaybettirir. Orada öncelik onarım değil veri kopyalamaktır. Sunucuya erişimi tamamen kaybettiyseniz, Sunucuyu yeniden kurma ve rescue modu ile çalışma; erişimi kaybettiğinizde verileri kurtarma yolunu okuyun.

Bulut altyapısı üzerinde çalışan sunucular için kurtarma modu genellikle yönetim panelinden etkinleştirilir ve fiziksel erişim gerekmez; henüz sunucunuzu seçmediyseniz, bulut sunucu bu imkânı aynı panelde size sunar. WordPress siteleri gibi daha hafif yükler için, Linux hosting genellikle tam bir sunucudan daha mantıklı bir seçenektir, çünkü önyükleme katmanı ve işletim sistemi onarımı sizin sorumluluğunuzda değildir.

Sık sorulan sorular

Sunucu kurtarma modunun normal önyüklemeden farkı nedir?

Kurtarma modunda işletim sistemi ayrı bir imajdan açılır ve ana diskiniz bağlanmaz. Yani diskinizden hiçbir hizmet çalışmaz ve sistem dosyalarını serbestçe düzenleyebilir veya onarabilirsiniz. Normal önyüklemede ise bu dosyalar kullanımdadır ve değiştirilmelerine izin vermez.

Kurtarma modunu etkinleştirdikten sonra SSH neden eski IP'ye bağlanmıyor?

Çünkü kurtarma modunda konuk işletim sistemi kendi ağ ayarlarıyla açılır ve farklı bir IP veya porta sahip olabilir. Bağlantı adresini ve portunu eski hafızanızdan veya betikten değil, sunucu yönetim panelinden alın.

Kurtarma modu ile verilerim silinir mi?

Kurtarma modunun kendisi verilere dokunmaz. Gerçek tehlike, chroot içinde çalıştırdığınız yanlış komutlardan gelir; örneğin yanlış bölüm üzerinde mkfs veya bağlı dosya sistemi üzerinde fsck. Her yıkıcı komuttan önce lsblk -f ile hangi aygıt üzerinde çalıştığınızdan emin olun.

Onarımdan sonra sorunun geri dönmeyeceğinden nasıl emin olurum?

Bir test yeniden başlatması yapın ve açıldıktan sonra systemctl --failed ve dmesg -T | tail -50 komutlarını kontrol edin. Disk hatası veya başarısız unit görürseniz, sorunun kökü hâlâ oradadır ve yalnızca belirtisi gizlenmiştir.