Sunucu Açılmıyor: Kurtarma (Rescue) Modu ile Adım Adım Kurtarma

Sağlayıcı panelinden sunucuyu yeniden başlattınız, iki dakika beklediniz ve SSH hâlâ cevap vermiyor. Panelin sanal konsolunu (VNC / noVNC) açtığınızda ekranda ya You are in emergency mode satırı ya da Give root password for maintenance istemi duruyor; bazen de imleci yanıp sönen bambaşka bir siyah ekran. Ping bazen geçiyor bazen geçmiyor, site kapalı, telefonunuz çalıyor.

Bu tablonun ortak noktası şudur: makine fiziksel olarak ayakta, sanallaştırma katmanı çalışıyor, ama işletim sistemi kök dosya sistemini normal şekilde devreye alamıyor. SSH bir servistir ve servisler ancak sistem multi-user.target seviyesine ulaştığında başlar. Sistem o seviyeye çıkamadığı için SSH de yok; yani "sunucu kapalı" değil, "sunucu yarı yolda takılı".

Bu rehber, sağlayıcıdan bağımsız genel bir kurtarma akışı anlatır: rescue moda geçmek, doğru diski tespit edip mount etmek, chroot ile kendi sisteminizin içine girmek ve en sık karşılaşılan üç arıza — hatalı fstab satırı, tamamen dolmuş disk ve bozulmuş GRUB — üzerinden gerçek düzeltmeleri uygulamak. Sonunda, rescue moddan çıkmadan önce yapmanız gereken doğrulamaları da tek tek göreceksiniz; çünkü kurtarmanın en pahalı hatası, düzelttiğini sanıp yeniden başlatmak ve aynı ekrana geri dönmektir.

Rescue (Kurtarma) Modu Nedir?#

Rescue modu, sağlayıcının sunucunuzu diskinizdeki sistem yerine ağdan yüklenen küçük ve bağımsız bir Linux imajıyla başlatmasıdır. Bu imaj RAM üzerinde çalışır, sizin diskinize hiç dokunmaz ve size root yetkili bir kabuk verir. Diskiniz o an sadece bağlanmayı bekleyen pasif bir blok cihazdır.

Bu ayrım kritik: rescue modda çalışırken bozuk sistem çalışmıyor. Dolayısıyla kilitli dosya, açık veritabanı, "dosya kullanımda" hatası gibi sorunlar yoktur. Bozuk bir fstab satırını, dolu bir diski veya kaybolmuş bir bootloader'ı ancak sistem kapalıyken güvenle düzeltebilirsiniz.

Sağlayıcılar bu özelliği farklı isimlerle sunar: "Rescue Mode", "Kurtarma Modu", "Recovery ISO", "Netboot Rescue". Bazı panellerde tek tıkla açılır, bazılarında bir kurtarma ISO'su bağlarsınız; mekanizma aynıdır.

Rescue Modu ile Single User / Emergency Mode Farkı#

Bunlar sık karıştırılır ama tamamen farklı iki araçtır:

Pratikte konsol ekranı size hangisine ihtiyacınız olduğunu söyler. GRUB menüsünü görebiliyorsanız disk okunuyor demektir ve çoğu zaman emergency mode yeter. GRUB menüsü bile gelmiyorsa, ya da mount: /sysroot: can't find UUID=... gibi bir satır varsa doğrudan rescue moda geçin.

Rescue Moda Geçmeden Önce Hatayı Okuyun#

Rescue moda acele etmeyin. Sanal konsolu açıp ekrandaki son 15-20 satırı okumak, sonraki yarım saati belirler. Aşağıdaki tablo en çok karşılaşılan çıktıları ve gerçek sebeplerini eşleştirir:

Konsol ekranını ekran görüntüsü olarak kaydedin; rescue moda geçtiğinizde o ekran kaybolur.

Bir de şunu sorun: sunucunun anlık görüntüsü (snapshot) veya güncel bir yedeği var mı? Varsa geri dönmek çoğu zaman kurtarmaktan hızlıdır; ikisi arasındaki farkı snapshot mı yedek mi yazısında ele aldık.

Rescue Moda Nasıl Geçilir?#

Sağlayıcıdan bağımsız genel akış şudur:

1. Panelde sunucuyu seçin, Rescue / Kurtarma Modu bölümünü açın.
2. Bir dağıtım seçmeniz isteniyorsa, mümkünse kurulu sisteminizle aynı aileden birini seçin (Ubuntu sistem için Ubuntu tabanlı rescue, AlmaLinux için RHEL tabanlı). Bu, chroot sonrası grub-install gibi komutların sürüm uyumsuzluğuna takılmamasını sağlar.
3. Modu etkinleştirdikten sonra sunucuyu kapatıp açın (soft reboot değil, panelden power off + power on). Çoğu panelde rescue modu ancak tam kapanma sonrası devreye girer.
4. Panelin gösterdiği geçici root şifresiyle SSH'la bağlanın; SSH gelmiyorsa sanal konsolu kullanın.

Bağlandıktan sonra ilk iş, gerçekten rescue modda olduğunuzu doğrulamaktır. Kendi sisteminize bağlandığınızı sanıp komut çalıştırmak, kurtarma sırasında yapılabilecek en tehlikeli hatadır:

# Kök dosya sistemi RAM'de mi? (rescue imajlarında genelde overlay/tmpfs görürsünüz)
findmnt -no SOURCE,FSTYPE /

# Çalışan çekirdek ve dağıtım rescue imajına mı ait?
uname -a
cat /etc/os-release

# Kendi diskiniz burada MOUNT EDİLMEMİŞ olmalı
lsblk

lsblk çıktısında diskleriniz görünüyor ama MOUNTPOINT sütunları boşsa doğru yerdesiniz.

Doğru Diski ve Bölümü Bulmak#

Kurtarmanın en çok hata yapılan adımı budur. Yanlış bölümü mount edip üzerinde işlem yapmak, çalışır durumdaki tek veriyi bozabilir. Sırayla ilerleyin:

# Blok cihazları, dosya sistemleri, etiketler ve UUID'ler tek ekranda
lsblk -f

# UUID ve tip bilgisini ayrıntılı görmek için
blkid

# Bölüm tablosu ve boyutlar
fdisk -l

Tipik bir sanal sunucuda vda veya sda ana disktir. vda1 çoğu zaman kök (/) bölümüdür; UEFI sistemlerde vda1 küçük bir FAT32 EFI bölümü, vda2 veya vda3 kök olur. Boyuta ve dosya sistemine bakarak karar verin: 100-500 MB'lık vfat bölüm EFI'dir, 1 GB civarı ext4 bölüm genelde /boot, gerisi kök bölümdür.

Disk LVM ise#

lsblk -f çıktısında bölümün tipi LVM2_member görünüyorsa doğrudan mount edemezsiniz; önce mantıksal birimleri etkinleştirmeniz gerekir:

# Volume group'ları tara ve etkinleştir
vgscan
vgchange -ay

# Mantıksal birimleri listele
lvs
lvdisplay | grep 'LV Path'

Bundan sonra mount edeceğiniz yol /dev/vda2 değil, /dev/mapper/vg0-root veya /dev/ubuntu-vg/ubuntu-lv biçiminde olur. Yanlış yolu denerseniz mount "unknown filesystem type LVM2_member" der; bu hata diskin bozuk olduğu anlamına gelmez, sadece birimleri henüz etkinleştirmediğinizi gösterir.

Dosya Sistemi Şüpheliyse Önce Kontrol Edin#

Mount etmeden önce dosya sistemi bütünlüğünü kontrol etmek, "mount oldu ama dosyalar tuhaf" durumunu baştan engeller. Bölüm mount edilmemişken çalıştırın:

# ext4 için
e2fsck -f -y /dev/vda1

# XFS için (RHEL/AlmaLinux/Rocky varsayılanı)
xfs_repair /dev/vda1

xfs_repair "log dirty" uyarısı verirse önce xfs_repair -L denemeden durun: bu komut günlüğü sıfırlar ve veri kaybı riski taşır. Bu noktada yedek/snapshot varsa geri dönmek daha akıllıcadır.

Diski Mount Edip chroot ile Sisteme Girmek#

Kök bölümü belirlediyseniz, sıra onu geçici bir dizine bağlamaya ve chroot ile "sanki o sistem çalışıyormuş gibi" içine girmeye geldi. chroot olmadan yalnızca dosya kopyalayabilirsiniz; chroot ile apt, dnf, grub-install, systemctl gibi komutları kendi sisteminizin kurulumuyla çalıştırabilirsiniz.

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

# Ayrı bölümler varsa onları da bağlayın (fstab'a bakarak doğrulayın)
mount /dev/vda2 /mnt/sistem/boot          # ayrı /boot varsa
mount /dev/vda1 /mnt/sistem/boot/efi      # UEFI sistemlerde EFI bölümü

# Çekirdek arayüzlerini içeri taşıyın
for d in dev dev/pts proc sys run; do mount --rbind /$d /mnt/sistem/$d; done

# DNS çözümlemesi gerekecekse
cp /etc/resolv.conf /mnt/sistem/etc/resolv.conf

chroot /mnt/sistem /bin/bash

chroot sonrası istem değişir. Doğru yerde olduğunuzu şöyle doğrulayın:

cat /etc/hostname     # kendi sunucunuzun adı görünmeli
ls /home              # kendi kullanıcılarınız
df -h                 # kendi bölüm düzeniniz

/proc ve /sys bağlanmazsa systemctl ve grub-install beklenmedik hatalar verir; /dev bağlanmazsa bootloader diski göremez. Bu üç satır atlanabilir görünür ama atlanamaz. Mount mantığının tamamı için disk bağlama, mount ve fstab yazısı iyi bir tamamlayıcıdır.

Senaryo 1: Hatalı fstab Satırı Sunucuyu Emergency Mode'a Düşürdü#

En yaygın sebep budur ve neredeyse her zaman bir bakım işinden sonra ortaya çıkar: yeni disk eklendi, swap dosyası tanımlandı, bir NFS/NAS bağlandı, disk değiştirildi ama UUID güncellenmedi. systemd açılışta /etc/fstab içindeki her satırı bağlamayı dener; bağlayamadığı satır varsa açılışı durdurur ve emergency mode'a düşer.

chroot içindeyken önce dosyayı doğrulayın:

# fstab satırlarını sözdizimi ve cihaz varlığı açısından denetler
findmnt --verify --verbose

# Hangi UUID gerçekte var?
blkid

findmnt --verify size hangi satırın hangi sebeple sorunlu olduğunu doğrudan söyler. Düzeltmenin iki yolu var:

A) Satırı doğru UUID ile güncelleyin. blkid çıktısındaki gerçek UUID'yi /etc/fstab içine yazın. Cihaz adları (/dev/sdb1) yeniden başlatmalarda değişebildiği için her zaman UUID kullanın.

B) Satırı isteğe bağlı hale getirin. Kritik olmayan bir veri diski yüzünden sunucunun hiç açılmaması kabul edilebilir bir davranış değildir. nofail ve makul bir zaman aşımı ekleyin:

# /etc/fstab
UUID=6f0c2c9e-2b1c-4c33-9a10-8c1f2b7a4d55  /          ext4  defaults                                   0 1
UUID=b41d9a77-1f8e-4a5b-9d21-0a7c6f3e8b12  /veri      ext4  defaults,nofail,x-systemd.device-timeout=15 0 2
/swapfile                                  none       swap  sw,nofail                                  0 0

Bu satırlarla disk yoksa sistem 15 saniye bekler, vazgeçer ve açılmaya devam eder. Emin olmadığınız satırı geçici olarak # ile yorum satırı yapmak da meşru bir ilk adımdır — sunucuyu ayağa kaldırıp sorunu sakin kafayla çözersiniz.

Değişiklikten sonra chroot içinde bağlamayı prova edin:

mount -a && echo "fstab temiz"

Bu komut hatasız dönüyorsa açılış artık bu satırda takılmayacaktır.

Senaryo 2: Disk Dolduğu İçin Sistem Açılmıyor#

Kök bölüm %100 dolduğunda systemd geçici dosya yazamaz, journald günlüğe kayıt açamaz, servisler tek tek başarısız olur ve sunucu ya emergency mode'a düşer ya da açılıp saniyeler içinde kullanılamaz hale gelir. En sinsi tarafı, SSH'ın bazen açılıp oturum açar açmaz kopmasıdır.

chroot içinde önce tabloyu görün:

df -h          # bloklar dolu mu?
df -i          # inode'lar dolu mu? (yüz binlerce küçük dosya)

Use% sütunu 100% ise blok doluluğu, IUse% sütunu 100% ise inode tükenmesi vardır; ikisinin çözümü farklıdır. Ardından kim şişirmiş bulun:

# Sadece kök dosya sisteminde kal, başka bağlı diske geçme (-x)
du -xh --max-depth=1 / 2>/dev/null | sort -rh | head -15
du -xh --max-depth=1 /var 2>/dev/null | sort -rh | head -15

Suçlu genellikle şu üç yerden biridir:

# systemd günlüklerini 200 MB'a indir
journalctl --vacuum-size=200M

# Paket önbelleği
apt clean          # Debian / Ubuntu
dnf clean all      # RHEL / AlmaLinux / Rocky

# Silinmiş ama bir süreç tarafından hâlâ tutulan dosyalar (yer boşalmıyorsa)
lsof +L1 | head -20

Son satır önemlidir: bir log dosyasını rm ile sildiğiniz hâlde df hâlâ dolu gösteriyorsa, dosyayı açık tutan süreç kapanana kadar alan geri gelmez. Rescue modda bu sorun yoktur çünkü hiçbir süreç çalışmamaktadır — dolu diski rescue modda temizlemenin bir avantajı da budur.

Acil durumda en az 1-2 GB boşaltıp sistemi ayağa kaldırın, kalıcı çözümü sonra kurun: log döndürme kurallarını gözden geçirmek ve doluluğun kök sebebini bulmak için disk dolu (No space left on device) çözümü yazısı bu işin devamıdır.

Senaryo 3: GRUB Bozuldu, Bootloader Kayboldu#

Belirti nettir: sunucu açılırken grub rescue> istemine düşer, error: unknown filesystem verir ya da GRUB menüsü hiç gelmez. Sebep genellikle disk klonlama/büyütme, bölüm tablosu değişikliği, yarım kalan bir kernel güncellemesi veya yanlış diske yapılmış bir grub-install işlemidir.

Çözüm, chroot içindeyken bootloader'ı yeniden kurup yapılandırmayı üretmektir. Komutlar dağıtıma ve önyükleme tipine göre değişir:

# --- BIOS (Legacy) önyükleme, Debian/Ubuntu ---
grub-install /dev/vda        # BÖLÜME değil, DİSKE kurulur (vda1 değil vda)
update-grub

# --- UEFI, Debian/Ubuntu (EFI bölümü /boot/efi'ye mount edilmiş olmalı) ---
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub

# --- RHEL / AlmaLinux / Rocky ---
grub2-install /dev/vda                          # BIOS
grub2-mkconfig -o /boot/grub2/grub.cfg          # BIOS
grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg   # UEFI

grub-install komutunu bölüme değil diske verdiğinizden emin olun; /dev/vda1 yazmak en sık yapılan hatadır ve sessizce işe yaramaz bir kurulum üretir.

Kernel paniği veya initramfs ile ilgili hata alıyorsanız başlangıç imajını da yeniden üretin:

# Debian / Ubuntu
update-initramfs -u -k all

# RHEL ailesi
dracut -f --regenerate-all

UEFI sistemlerde önyükleme girdisi kaybolmuşsa efibootmgr -v ile mevcut girdileri listeleyip eksik olanı yeniden ekleyebilirsiniz. Bu adımda rescue imajının mimarisinin (x86_64) sisteminizle aynı olması şarttır.

Rescue Moddan Çıkmadan Önce Doğrulama Listesi#

Kurtarmanın en pahalı hatası, düzelttiğini varsayıp yeniden başlatmak ve aynı ekrana dönmektir. chroot içindeyken şu beş kontrolü sırayla yapın:

1. fstab temiz mi? findmnt --verify --verbose hatasız dönmeli, mount -a sessizce tamamlanmalı.
2. Yer var mı? df -h ve df -i çıktılarında kök bölüm en az %10 boş olmalı.
3. Bootloader yerinde mi? ls /boot içinde vmlinuz-* ve initrd*/initramfs-* dosyaları, GRUB dizininde grub.cfg bulunmalı.
4. Erişim kanalınız açık mı? systemctl is-enabled ssh (veya sshd) enabled demeli. Şifreyi de burada sıfırlayabilirsiniz — yöntemi sunucu root şifresi değiştirme yazısında bulabilirsiniz.
5. Kritik servisler açılışta etkin mi? systemctl list-unit-files --state=enabled | head -30 ile web sunucusu ve veritabanının listede olduğunu görün.

Sonra düzgün biçimde çıkın. Sıralama önemlidir; bağlamaları ters sırada sökmezseniz diskte tutarsız veri kalabilir:

exit                          # chroot'tan çık
umount -R /mnt/sistem         # tüm alt bağlamalarla birlikte sök
sync

umount "target is busy" derse fuser -vm /mnt/sistem ile hangi sürecin tuttuğunu bulun. Ardından panelden rescue modu kapatın ve sunucuyu yeniden başlatın. Bu adım unutulursa makine tekrar kurtarma imajıyla açılır ve "hiçbir şey değişmemiş" izlenimi verir.

İlk açılıştan sonra konsolu kapatmadan bekleyin ve sistem ayağa kalkar kalkmaz günlüklere bakın:

journalctl -b -p err          # bu açılışta oluşan hatalar
systemctl --failed            # başlatılamayan servisler

Günlükleri okuma alışkanlığı için journalctl ile log yönetimi yazısı işinizi kolaylaştırır.

Rescue Modun Çözemediği Durumlar#

Rescue modu her şeyin çaresi değildir. Şu üç durumda uğraşmak zaman kaybıdır:

• Disk hiç görünmüyorsa. lsblk ve fdisk -l çıktısında diskiniz yoksa sorun sizin katmanınızda değildir; sanallaştırma tarafında disk bağlı değil ya da depolama arızalıdır. Doğrudan destek talebi açın.
• Dosya sistemi onarılamıyorsa. e2fsck/xfs_repair sürekli hata dönüyor, dizinler lost+found içine dökülüyorsa kurtarmaya devam etmek veriyi daha da bozabilir. Önce mümkün olduğunca çok veriyi rescue moddan dışarı kopyalayın (rsync üzerinden başka bir sunucuya), sonra yeniden kurulum planlayın. Yöntem için rsync ile yedekleme yazısı doğrudan uygulanabilir.
• Sunucuya saldırı şüphesi varsa. Boot sorununun arkasında şifrelenmiş dosyalar veya değiştirilmiş sistem ikilikleri varsa, "açılsın da bakarız" yaklaşımı yanlıştır. Diski salt okunur kopyalayıp temiz bir kurulumla devam etmek tek güvenli yoldur.

Son olarak: bu üç senaryonun üçü de önlenebilir. fstab'a eklediğiniz her yeni satırı mount -a ile prova etmek, kök bölüm doluluğu için %85 seviyesinde bir alarm kurmak ve kernel güncellemelerinden sonra bir kez planlı yeniden başlatma yapmak, gece yarısı rescue moda girme ihtimalinizi ciddi biçimde azaltır.

Sıkça Sorulan Sorular#

Rescue moda geçmek sunucudaki verileri siler mi?#

Hayır. Rescue modu, sağlayıcının sunucuyu ağdan yüklenen ayrı bir kurtarma imajıyla başlatmasıdır; bu imaj RAM üzerinde çalışır ve siz açıkça mount edip yazma işlemi yapmadıkça diskinize dokunmaz. Veri kaybı riski moda geçmekten değil, mod içinde yanlış bölümü biçimlendirmek veya xfs_repair -L gibi yıkıcı komutları düşünmeden çalıştırmaktan doğar.

Rescue modda SSH ile bağlanamıyorum, ne yapmalıyım?#

Rescue imajı çoğu zaman panelde gösterilen geçici bir root şifresiyle gelir ve bu şifre her etkinleştirmede değişir. Bağlanamıyorsanız önce yerel known_hosts uyarısını temizleyin, çünkü sunucunun anahtarı değişmiştir. Yine olmuyorsa panelin sanal konsolunu (VNC/noVNC) kullanın; konsol ağdan bağımsız çalıştığı için rescue modda her zaman erişilebilir olur.

chroot yapmadan sadece dosya düzenlesem yeterli olmaz mı?#

/etc/fstab düzeltmek ya da bir log dosyası silmek gibi işler için mount edip düzenlemek yeterlidir. Ancak paket kurmak, grub-install çalıştırmak, initramfs yeniden üretmek veya systemctl enable demek gerekiyorsa chroot şarttır. Bu komutlar sistemin kendi kütüphaneleri ve yapılandırmasıyla çalışmak zorundadır; rescue imajının ortamında çalıştırılırsa yanlış sonuç üretir.

Emergency mode'a düşen sunucuyu rescue moda geçmeden kurtarabilir miyim?#

Çoğu zaman evet. Emergency mode zaten kendi diskinizden açılmıştır, yani kök dosya sistemi okunabiliyordur. Konsolda root şifresini girip mount -o remount,rw / komutuyla diski yazılabilir yaptıktan sonra /etc/fstab düzeltmesi veya log temizliği yapabilirsiniz. Rescue moda ancak GRUB hiç gelmiyorsa, kök dosya sistemi bağlanamıyorsa veya root şifresini bilmiyorsanız ihtiyaç duyarsınız.

Rescue moddan çıktım ama sunucu yine kurtarma imajıyla açılıyor, sebebi ne?#

Neredeyse her zaman panelde rescue modun kapatılmamış olmasıdır. Birçok sağlayıcıda mod, siz kapatana kadar geçerli kalır ve her yeniden başlatmada kurtarma imajı yüklenir. Panelden modu devre dışı bırakın ve sunucuyu tamamen kapatıp yeniden açın. Bazı panellerde ayrıca boot sırasını "disk" olarak geri almanız gerekir.

Kurtarma sırasında yanlış diski mount etmediğimden nasıl emin olurum?#

Mount ettikten sonra hemen içeriğe bakın: cat /mnt/sistem/etc/hostname kendi sunucu adınızı, ls /mnt/sistem/home kendi kullanıcılarınızı, ls /mnt/sistem/var/www kendi sitelerinizi göstermelidir. Bunlardan biri bile beklediğinizle uyuşmuyorsa hiçbir yazma işlemi yapmadan umount edip lsblk -f çıktısını yeniden değerlendirin. Boyut ve dosya sistemi tipi, doğru bölümü ayırt etmenin en güvenilir iki ipucudur.