Debian Sistem Kurtarma: Rescue Mode Kullanımı

Bir gün gelir, sunucunuz ayağa kalkmaz. Ekran karşınıza panik mesajları döker ya da hiç açılmaz bile. İşte o an, rescue mode’un ne kadar değerli olduğunu anlarsınız. Debian sistemlerde kurtarma modu, kritik bir hatayı düzeltmek, bozuk bir dosya sistemini onarmak veya erişemediğiniz bir sisteme girmek için tasarlanmış hayat kurtarıcı bir araçtır. Bu yazıda rescue mode’u derinlemesine inceleyeceğiz; teoride değil, gerçek senaryolarda nasıl kullandığımı anlatacağım.

Rescue Mode Nedir ve Ne Zaman Kullanılır?

Rescue mode, sisteminizin normal olarak başlayamadığı durumlarda, minimal bir ortam üzerinden sisteme müdahale etmenizi sağlar. Normal bir önyükleme sürecinin aksine, rescue mode disk üzerindeki root dosya sisteminizi okuma/yazma modunda bağlamaya çalışır ve size bir shell sunar.

Rescue mode’a başvurmanız gereken tipik durumlar şunlardır:

• Bozuk GRUB yapılandırması: Yanlış bir kernel parametresi veya disk değişikliği sonrası sistem açılmıyor
• Hatalı /etc/fstab girişi: Var olmayan bir bölümü mount etmeye çalışan fstab sistemi kilitleyor
• Unutulan root şifresi: Sunucuya erişiminizi kaybettiniz
• Bozuk dosya sistemi: Filesystem corruption sonrası sistem ext4 veya btrfs üzerinde hata veriyor
• Kritik kütüphane veya binary hasarı: Yanlış bir rm -rf komutu sonrası sistem çöktü
• initramfs sorunları: Initial RAM disk düzgün oluşturulmamış

Ben bu senaryoların hepsini kariyerim boyunca yaşadım. En travmatik olanı, bir üretim sunucusunda gece 02:00’de fstab’a yanlış UUID girip sabah ekibinin geldiğinde sistemi çalışmaz bulmasıydı. O gece rescue mode olmasa çok zor bir süreç yaşanırdı.

GRUB Üzerinden Rescue Mode’a Giriş

Eğer sisteminiz GRUB ekranına kadar geliyorsa, işiniz görece kolaydır. GRUB menüsü görüntülendiğinde ilk yapmanız gereken şey beklemek ve e tuşuna basmaktır.

GRUB komut satırına düştüğünüzde veya entry’yi düzenlerken, kernel satırını bulup sonuna şu parametreyi ekleyebilirsiniz:

# GRUB'da kernel satırının sonuna ekleyin
linux /boot/vmlinuz-6.1.0-21-amd64 root=/dev/sda1 ro quiet
# Bunu şu hale getirin:
linux /boot/vmlinuz-6.1.0-21-amd64 root=/dev/sda1 ro single

single parametresi sistemi single-user mode’da başlatır. Bu, rescue mode’un en basit halidir. Alternatif olarak init=/bin/bash parametresini de kullanabilirsiniz; bu doğrudan bash shell açar ama bazı servisler başlamaz:

# Doğrudan bash başlatmak için
linux /boot/vmlinuz-6.1.0-21-amd64 root=/dev/sda1 rw init=/bin/bash

init=/bin/bash ile girdiğinizde / mount edilmiş ama birçok şey eksik olacaktır. Bu nedenle hemen şu komutları çalıştırmanızı öneririm:

# Proc ve sys dosya sistemlerini bağlayın
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs devtmpfs /dev

# Eğer root sadece okuma modundaysa yazma moduna alın
mount -o remount,rw /

Live ISO ile Chroot Tabanlı Kurtarma

Sisteminiz GRUB’a bile gelmiyorsa ya da disk düzeyinde bir sorun varsa, dışarıdan müdahale etmeniz gerekir. Bunun için Debian veya herhangi bir Linux live ISO kullanabilirsiniz. Ben genellikle Debian net install ISO’sunu tercih ederim çünkü zaten elimde bulunur ve rescue seçeneği sunar.

Debian installer ISO’sunu boot ettiğinizde menüde Advanced options > Rescue mode seçeneğini göreceksiniz. Bu seçeneği seçtiğinizde installer sizi disk bölümlerinizi seçmeye yönlendirir ve ardından o bölüm üzerinde bir shell açar.

Ancak ben daha fazla kontrol için genellikle live ISO ile manuel chroot yapmayı tercih ederim:

# Önce diskinizi ve bölümlerinizi listeleyin
lsblk
fdisk -l

# Root bölümünüzü /mnt altına bağlayın (örnek: /dev/sda1)
mount /dev/sda1 /mnt

# Eğer ayrı boot bölümünüz varsa
mount /dev/sda2 /mnt/boot

# EFI sistemi kullanıyorsanız
mount /dev/sda3 /mnt/boot/efi

Bölümleri bağladıktan sonra chroot ortamı için gerekli sanal dosya sistemlerini hazırlayın:

# Sistem dosya sistemlerini bağlayın
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

# Chroot'a girin
chroot /mnt /bin/bash

# Chroot içinde environment'ı düzeltin
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
source /etc/profile

Artık tamamen sisteminizin içinde çalışıyor gibisiniz. Yapacağınız değişiklikler gerçek sistemin diskinize yazılacak.

Senaryo 1: GRUB’u Yeniden Yüklemek

En sık karşılaştığım sorunlardan biri GRUB’un bozulması veya yanlış diske yüklenmesidir. Disk değiştirdiğinizde, RAID yeniden yapılandırdığınızda veya başka bir OS kurulumu GRUB’unuzun üzerine yazdığında bu sorun ortaya çıkar.

Chroot ortamındayken GRUB’u yeniden yüklemek oldukça basittir:

# Chroot içinde GRUB'u hedef diske yükleyin
grub-install /dev/sda

# GRUB konfigürasyonunu yeniden oluşturun
update-grub

# EFI tabanlı sistemlerde
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian
update-grub

update-grub komutu /boot/grub/grub.cfg dosyasını yeniden oluşturur ve tüm kernel’leri tarar. Çıktıyı dikkatlice okuyun; eğer kernel’leri bulamazsa bir sorun var demektir.

Senaryo 2: Bozuk fstab Düzeltme

Bu senaryo bizzat yaşadığım ve beni epey terleten bir durumdu. Bir LVM genişletme işlemi sonrasında fstab’a yanlış UUID girmistim ve sistem bir sonraki boot’ta mount hatası vererek emergency shell’e düşmüştü.

Emergency shell’de sistemi inceleyip düzeltmek için:

# Önce mevcut bölümlerin UUID'lerini listeleyin
blkid

# Çıktı şuna benzer:
# /dev/sda1: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"
# /dev/sda2: UUID="b2c3d4e5-f6a7-8901-bcde-f12345678901" TYPE="swap"

# fstab'ı düzenleyin
nano /etc/fstab

fstab dosyasındaki bir satır şu şekilde görünür:

# /etc/fstab örnek içeriği
UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 / ext4 errors=remount-ro 0 1
UUID=b2c3d4e5-f6a7-8901-bcde-f12345678901 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0

Düzenlemeyi yaptıktan sonra bağlama işlemini test etmek için:

# fstab'ı test edin (gerçekte mount etmez, sadece kontrol eder)
mount -a --fake

# Hata yoksa gerçekten bağlayın
mount -a

Bu komut hiçbir çıktı vermeden tamamlanırsa fstab’ınız doğrudur.

Senaryo 3: Root Şifresini Sıfırlamak

Miras aldığınız bir sunucunun root şifresi bilinmiyor veya kendiniz unuttunuz. Rescue mode bu durumda hayat kurtarır.

# Chroot ortamındayken şifreyi değiştirin
passwd root

# Ya da belirli bir kullanıcının şifresini sıfırlayın
passwd kullanici_adi

Alternatif olarak, eğer sadece sisteme girmek istiyorsanız ve şifre değiştirmek istemiyorsanız, /etc/shadow dosyasını doğrudan düzenleyebilirsiniz. Shadow dosyasındaki root satırında ikinci alan (iki : arasındaki hash) boş bırakılırsa şifresiz giriş aktif olur, ancak bunu güvenlik açısından yalnızca acil durumlarda ve hemen ardından şifre belirleyerek kullanın.

Senaryo 4: Dosya Sistemi Onarımı

Dosya sistemi bozulması, beklenmedik kapanmalar sonrasında veya donanım sorunları nedeniyle ortaya çıkabilir. GRUB geçse bile sistem boot sırasında fsck hatasıyla duruyorsa rescue mode şarttır.

# Önce dosya sistemini unmount edin (chroot dışındayken)
umount /mnt

# ext4 dosya sistemi kontrolü ve onarımı
fsck.ext4 -y /dev/sda1

# Daha ayrıntılı çıktı için
fsck.ext4 -v -y /dev/sda1

# Btrfs için
btrfs check --repair /dev/sda1

# XFS için (mount edilmemişken)
xfs_repair /dev/sda1

-y parametresi tüm sorulara otomatik olarak “evet” cevabı verir. Üretim ortamında bunu kullanmadan önce ne yapıldığını anlamak için -n ile readonly check yapmanızı öneririm:

# Önce ne bulduğunu görün, değiştirme yapmadan
fsck.ext4 -n /dev/sda1

# Çıktıyı inceledikten sonra onarımı başlatın
fsck.ext4 -y /dev/sda1

Ciddi bir corruption varsa e2fsck size kayıp dosyaları lost+found dizinine taşıyacağını söyler. Bu dosyalar orijinal isimlerini kaybetmiş olur ama içerikleri kurtarılabilir.

Senaryo 5: Kernel veya initramfs Yenileme

Bazen yanlış bir kernel güncellemesi veya bozuk bir initramfs sistemi boot edemez hale getirir. Bu durumda chroot üzerinden yeni bir initramfs oluşturabilirsiniz:

# Chroot içinde mevcut kernel'leri listeleyin
ls /boot/vmlinuz-*

# Belirli bir kernel için initramfs yenileyin
update-initramfs -u -k 6.1.0-21-amd64

# Tüm kernel'ler için yenileyin
update-initramfs -u -k all

# Yeni bir initramfs oluşturun
update-initramfs -c -k 6.1.0-21-amd64

Eğer kernel paketleri bozulduysa apt ile yeniden kurabilirsiniz:

# Chroot içinde network için resolv.conf'u kopyalayın
cp /etc/resolv.conf /mnt/etc/resolv.conf  # Chroot öncesi

# Chroot içinde
apt update
apt install --reinstall linux-image-amd64
update-grub

Senaryo 6: LVM ile Çalışan Sistemlerde Rescue

LVM kullanan sistemlerde rescue mode biraz daha karmaşıktır. Volume group’ları aktif etmeniz gerekir:

# Live ortamda LVM araçlarının kurulu olduğunu kontrol edin
which vgchange

# Tüm volume group'ları listeleyin
vgscan

# Volume group'ları aktif edin
vgchange -ay

# Logical volume'ları görün
lvdisplay
lvscan

# Artık LV'leri bağlayabilirsiniz
mount /dev/debian-vg/root /mnt
mount /dev/debian-vg/home /mnt/home

LUKS şifreli bir sistemdeyseniz önce şifreli birimi açmanız gerekir:

# LUKS birimi açın
cryptsetup luksOpen /dev/sda3 sda3_crypt

# Sonra LVM'yi aktif edin
vgchange -ay

# Mount edin
mount /dev/mapper/debian--vg-root /mnt

Rescue Mode Sonrası Temiz Çıkış

Kurtarma işlemini tamamladıktan sonra sistemi düzgün bir şekilde kapatmak, yapılan değişikliklerin diske yazılması açısından önemlidir:

# Chroot'tan çıkın
exit

# Bağlı dosya sistemlerini ayırın (ters sırada)
umount /mnt/dev/pts
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount /mnt/boot/efi  # EFI bölümü varsa
umount /mnt/boot      # Ayrı boot bölümü varsa
umount /mnt

# Sistemi yeniden başlatın
reboot

Disk buffer’larını temizlemek için sync komutunu umount öncesinde çalıştırmak iyi bir alışkanlıktır:

sync
umount /mnt

Rescue Mode için Hazırlıklı Olmak

Kriz anında panik yapmamak için önceden hazırlık yapmak çok önemlidir. Birkaç pratik öneri:

• Her zaman bootable bir USB bulundurun: Debian net install veya live ISO içeren güncel bir USB’yi fiziksel sunucular için kasada, sanal makineler için datastore’da hazır tutun
• /etc/fstab değişikliklerini dikkatli yapın: Özellikle UUID değişikliklerinde yeni UUID’yi blkid ile doğrulayın, değişiklik sonrası bir sonraki boot’tan önce mount -a ile test edin
• Boot konfigürasyonunu belgeleyin: Disk yapısı, LVM isimleri, LUKS bilgileri gibi kritik detayları güvenli bir yerde saklayın
• Chroot script hazırlayın: Sık kullandığınız mount komutlarını bir script’e yazın, kriz anında komutları yanlış yazmaktan kurtulursunuz
• Snapshot alın: Sanal makinelerde kritik işlemler öncesinde mutlaka snapshot alın, rescue mode’a hiç gerek kalmaz

# Kendim için hazırladığım basit chroot kurulum scripti
#!/bin/bash
# rescue-mount.sh

DISK=${1:-/dev/sda1}
MOUNTPOINT=/mnt

echo "Mounting $DISK to $MOUNTPOINT..."
mount $DISK $MOUNTPOINT

mount --bind /dev $MOUNTPOINT/dev
mount --bind /dev/pts $MOUNTPOINT/dev/pts
mount --bind /proc $MOUNTPOINT/proc
mount --bind /sys $MOUNTPOINT/sys

echo "Entering chroot..."
chroot $MOUNTPOINT /bin/bash

Bu script’i live USB’nize koyarsanız kriz anında tek komutla chroot ortamına girebilirsiniz.

Uzak Sunucularda Rescue Mode

Fiziksel erişiminizin olmadığı uzak sunucularda rescue mode çok daha kritiktir. Büyük cloud sağlayıcıları (AWS, GCP, Azure, Hetzner, DigitalOcean) panel üzerinden rescue mode veya recovery instance seçeneği sunar.

Hetzner gibi dedicated sunucu sağlayıcılarında Rescue System, panel üzerinden aktif edilir ve sunucu rescue Linux ile yeniden başlar. SSH ile bağlandığınızda kendinizi minimal bir sistemde bulursunuz:

# Hetzner rescue sisteminde diskinizi listeleyin
lsblk

# Dosya sistemini kontrol edin
fsck /dev/sda1

# Chroot ile müdahale edin
mount /dev/sda1 /mnt
# ... yukarıdaki chroot adımları

AWS EC2’de ise problematik instance’ın root volume’unu başka bir çalışan instance’a attach edip müdahale etmek yaygın bir yaklaşımdır. Bu tamamen rescue mode mantığıyla çalışır.

Sık Yapılan Hatalar

Yıllar içinde yaptığım veya gördüğüm birkaç kritik hatayı paylaşayım:

• Chroot içinde disk işlemi yapmak: fsck‘yı mount edilmiş bir dosya sistemi üzerinde çalıştırmak veriyi daha da bozabilir. Her zaman unmount edip çalıştırın
• Network olmadan apt kullanmaya çalışmak: Chroot içinde resolv.conf kopyalamayı unutmak, package kurulumlarını başarısız kılar
• init=/bin/bash ile rw mount: Bazı durumlarda bu yöntemle root olarak giriş yaparken sistemin tamamen yazılabilir olduğunu unutup kritik dosyalara zarar verebilirsiniz
• GRUB’u yanlış diske yüklemek: grub-install /dev/sda1 yerine grub-install /dev/sda kullanın; sda1 bölüm, sda disk demektir
• Çıkış yapmadan sistemi kapatmak: Chroot içindeyken direkt reset yapmak, yazılmamış verilerin kaybolmasına yol açabilir

Sonuç

Rescue mode, bir sistem yöneticisinin araç kutusundaki en değerli aletlerden biridir. Panikle değil, sistematik düşünerek yaklaşıldığında neredeyse her sorun çözülebilir. Disk yollarını doğru tanımlamak, mount sıralarına dikkat etmek ve chroot öncesinde sanal dosya sistemlerini hazırlamak, başarılı bir kurtarmanın temelini oluşturur.

En önemli tavsiyem şu: Bu adımları bir sorun çıkmadan önce test ortamında prova edin. Kriz anında ilk defa chroot yapmaya çalışmak, baskı altında hata yapma riskini artırır. Sanal bir makinede kasıtlı olarak fstab’ı bozun, GRUB’u silin, şifreyi değiştirin ve ardından bu yazıdaki adımlarla kurtarın. O alıştırmayı yaptıktan sonra gerçek bir kriz anında çok daha sakin olacaksınız.

Bir de şunu unutmayın: Her kurtarma işlemi sonrasında neden o duruma düştüğünüzü analiz edin. Monitoring, düzenli yedekleme ve değişiklik öncesi snapshot alma alışkanlığı, rescue mode’a olan ihtiyacı minimize eder. Ama tamamen ortadan kalkmaz. O USB’yi dolabınızdan çıkarmayın.