Öne Çıkanlar
- Reboot (yeniden başlatma) makineyi kapatıp açmaktan fazlasıdır; işletim sistemi ve servislerin düzgün kapanması önemlidir.
- Her reboot sorunu çözmez — altta yatan nedenleri (CPU, I/O, bellek, uyumsuz yazılım) tespit edip düzeltmek gerekir.
- Kontrollü adımlar: log incelemesi, servis restartları, config yedekleme ve gerekiyorsa panel/VNC üzerinden müdahale.
- Firewall ve port konfigürasyon hataları erişimi kesebilir; reboot bazen bu tür hataları düzeltmez, VNC/KVM ile müdahale gerekebilir.
- Uygun kaynak planlaması ve versiyon/uyumluluk yönetimi (PHP/MySQL/indeksleme) uzun vadede reboot ihtiyacını azaltır.
Sunucuya Reboot (Yeniden Başlatma) Atma Hakkında Bilmeniz Gerekenler
Sunucuya Reboot (Yeniden Başlatma) Atma konusu, genelde şöyle başlar: Panelden tıklıyorsun, “Yeniden Başlat” diyorsun, ekran dönüyor… ve sunucu bir daha gelmiyor. Ya da SSH kilitleniyor, işlem listesi inmiyor, CPU %100, “Şuna bir reboot atsak da kendine gelse” diyorsun. Aslında bu kadar kritik bir işlemi çoğu zaman refleksle yapıyoruz, arka planda neler olabileceğini pek düşünmeden. İşin güzel tarafı şu: Hem panelden hem SSH üzerinden güvenli şekilde reboot atmanın çok net, basit ve tekrar eden bazı kuralları var.
Bu yazıda işi akademik anlatmayacağım. Gerçek senaryo şu: Sunucu takıldı, SSH cevap vermiyor, kontrol paneli elinde tek kaldı. Ya da tam tersi; panel yok ama root SSH sende. Böyle anlarda “reset tuşuna abanmak” ile “kontrollü reboot” arasındaki fark, veritabanının bozulup bozulmaması kadar dramatik olabiliyor. Şöyle düşün: Tıpkı bir sunucunun güç kablosunu bir anda çekmekle, önce uygulamaları düzgün kapatıp sonra makineyi yeniden başlatmak arasındaki fark gibi.
| Özellik | Değer |
|---|---|
| Hizmet Türü | VDS / VPS / Cloud Sunucu |
| Hedef Kitle | Geliştirici, Sistem Yöneticisi, Orta Ölçekli Proje Sahipleri |
| Zorluk Seviyesi | Orta |
| Öne Çıkan Özellik | Stabilite ve Hızlı Kurtarma |
Yapılandırma ve Yönetim: Adım Adım
Kaynak Yönetimi – Limitleri Zorlamayın
Genelde kullanıcılarımızdan duyduğumuz en büyük şikayet şu oluyor: “Sunucuya reboot attım, düzeldi ama birkaç saat sonra yine kasmaya başladı.” Bu, klasik kaynak yönetimi sorunu. CPU, RAM ve disk I/O’yu izlemiyorsan, reboot sadece reset butonu gibi çalışır; sorunu kökten çözmez.
Şöyle düşünün: Bir araba yokuşta boğuluyorsa, motoru stop edip tekrar çalıştırmak anlık toparlatır ama asıl dert vites seçimi ya da motor gücüdür. Sunucuda da aynı. RAM yetmiyorsa sistem swap’e abanır, disk I/O kitlenir, sunucu “takıldı” diye görünür. Sen panelden Sunucuya Reboot (Yeniden Başlatma) Atma işlemi yaparsın, swap temizlenir, her şey bir süre akıcı gelir. Ama bellek aşımı yapan script’ini düzeltmediğin sürece döngü tekrarlanır.
Aşırı kaynak kullanımı uyarısı aldığında ilk bakacağın yer genelde log dosyalarıdır ama dürüst olmak gerekirse pratikte çoğu kişi ilk olarak Apache/Nginx ve MySQL log’larına bile bakmıyor. Panik yapmadan önce kontrol etmen gereken ilk dosya çoğu Linux sistemde şu olur: /var/log/messages veya dağıtıma göre /var/log/syslog. Burada kernel I/O hataları, OOM killer log’ları (RAM tükendiğinde süreç öldürme) gibi kritik ipuçları görürsün.
Ek olarak:
- CPU için
topveyahtopile hangi prosesin kasıp kavurduğunu takip et. - Disk I/O için
iotopveyaiostatkurtarıcıdır. - RAM için
free -mve cache kullanımını yorumlayabilmek önemli; her boş RAM iyi RAM değildir, Linux cache sever.
Bütün bunları yaptıktan sonra hâlâ sistem tamamen kilitlenmiş, SSH dahi açılmıyorsa, işte o noktada panelden kontrollü Sunucuya Reboot (Yeniden Başlatma) Atma mantıklı hale gelir.
Güvenlik Duvarı ve Port Ayarları
Dış dünyaya açık her port, açık bir penceredir. Ama şu da gerçek: Gereğinden fazla kısılmış bir firewall, senin kendi sunucuna bile erişememene sebep olabilir. “SSH’a giremiyorum, sunucu gitti” diye düşündüğün bazı anlarda aslında sistem ayaktadır; sadece port kapalıdır.
İşin püf noktası şu: SSH, RDP, FTP gibi servisleri hem mümkün olduğunca kısıtlamak hem de erişimi kaybetmeyecek şekilde yapılandırmak gerekiyor. Örneğin:
- SSH portunu 22’den farklı bir porta almak, bot taramalarını ciddi oranda azaltır ama iptables / firewalld kuralını güncellemeyi unutursan kendini dışarıda bulursun.
- FTP’yi aktif kullanmıyorsan kapat. Kullanıyorsan da SFTP/FTPS gibi şifreli protokolleri tercih et.
- Panel portlarını (örneğin cPanel/WHM, Plesk) IP erişim listesiyle sınırlandırmak iyi fikirdir.
Burada Sunucuya Reboot (Yeniden Başlatma) Atma ile bağlantı nerede dersen: Firewall konfigürasyonunda yaptığın bir hata, kendini kilitlemene sebep olabilir. SSH yok, panel yok, sunucu aslında çalışıyor ama sen giremiyorsun. Bu tip durumlarda sağlayıcının verdiği VNC/KVM konsol üzerinden bağlanıp firewall kurallarını düzeltmek gerekir. Panelden “Reboot”a asılarak sorunu çözmeye çalışmak, yanlış kuralı sıfırlamaz; bazen tam tersine boot sonrası kural script’leri tekrar çalışır ve her şey daha da kitlenir.
Yazılım Uyumluluğu ve PHP/Veritabanı Seçimi
Sunucu dünyasında sık duyduğumuz başka bir ezber: “En güncel sürüm her zaman en iyisidir.” Yeni her zaman hızlıdır ama her zaman stabil değildir. Özellikle üretim ortamında, PHP, MySQL/MariaDB gibi bileşenleri seçerken sadece versiyon numarasına bakmak büyük risk.
Şöyle düşünün: PHP 8.x’e geçiş yaptıktan sonra CPU kullanımı artmış, bazı eklentiler çalışmıyor, Apache error log’u uyarı dolmuş. Sunucuya Reboot (Yeniden Başlatma) Atma yaptığında bu sorunlar kaybolmaz; sadece servisler yeniden başlar. Altındaki uyumsuz kod ya da eklenti yine aynı hatayı üretir.
Veritabanı tarafında benim benimsediğim bir altın kural var: “Önce indeks, sonra sorgu.” Uygulama geliştiricilerinin çoğu sorguyu optimize etmeye çalışıyor ama eksik index’li bir tabloda ne yaparsan yap tam kurtulamıyorsun. Tıpkı büyük bir telefon rehberini sayfa sayfa aramakla, soyadına göre sıralı bir listede ikili arama yapmak arasındaki fark gibi. İndex’i doğru koyduğunda, sunucuya sırf “MySQL CPU’yu zorluyor” diye reboot atmak zorunda kalma ihtimalin çok azalıyor.
Bu arada özellikle WordPress gibi popüler içerik yönetim sistemleri için, sürüm uyumluluğu ve PHP seçimi noktasında WordPress hosting paketlerindeki önerilen kombinasyonlara da göz atabilirsin; sık kullanılan stack’ler pratikte çok daha az sürpriz çıkarır.
Uygulama: Kurulum ve Yayına Alma
Gelelim işin pratiğine. “Terminali açın, şu komutu girin” demiyorum ama mantık şu: Sunucuda kritik bir değişiklik yapacaksan (kernel güncellemesi, büyük bir paket yükseltmesi, panel update’i vb.) önce servis seviyesinde restart, sonra gerekirse sistem seviyesinde reboot düşünmelisin.
Tipik bir akış şöyle olur:
- Önce bağımlılıkları kontrol edin: Örneğin kernel güncellemesi yaptıysan
uname -rile hangi versiyonun yüklendiğine bak. - Config dosyasındaki kritik satırları yedekleyin:
/etc/fstab, network config dosyaları, firewall script’leri. Bir satır hata, reboot sonrası sistemin hiç açılmamasına sebep olabilir. - Servis bazlı restart deneyin: Apache/Nginx, PHP-FPM, MySQL/MariaDB gibi servisleri tek tek restart edip sorunun sistem genelinde mi, yoksa tek bir serviste mi olduğunu görün.
- Log’lara göz atın: En azından son 50 satırı (
tail -n 50) inceleyin ki reboot sonrası olası disk hatası veya fsck bekleyen bir dosya sistemi ile karşılaşmayın.
Genelde bu süreç 5 dakikadan fazla sürmez. Eğer tüm bunlara rağmen sistem cevap vermiyor, SSH açılmıyor, panel komutları takılıyorsa, işte o zaman sağlayıcının kontrol panelinden Sunucuya Reboot (Yeniden Başlatma) Atma adımı devreye girer. VDS/Cloud altyapılarda bu, fiziksel reset yerine sanal güç döngüsü (power cycle) şeklinde gerçekleştiği için, doğru yapılandırılmışsa veritabanı bozulma riski çıplak metale göre daha düşüktür.
Bu arada, performansınızı artırmak için Sunucu sayfamızdaki diğer çözümlere de bakabilirsiniz.
Sık Karşılaşılan Sorunlar ve Pratik Çözümler
| Sorun | Muhtemel Neden | Çözüm |
|---|---|---|
| Site Yavaş Açılıyor | Zayıf önbellekleme veya yüksek sorgu sayısı | Redis/Litespeed Cache kurulumu yapın |
| Bağlantı Zaman Aşımı | Firewall engeli veya hatalı DNS | Port izinlerini kontrol edin |
| SSH Cevap Vermiyor | Yoğun load, kill olmuş SSH servisi veya yanlış port ayarı | Önce panelden servis restart deneyin, olmazsa kontrollü reboot atın |
| Reboot Sonrası Site Hiç Açılmıyor | Disk bağlanma hatası, bozuk fstab, hatalı kernel | VNC/KVM ile bağlanıp boot loglarını inceleyin, son değişiklikleri geri alın |
Burada özellikle son satır kritik. Panelden Sunucuya Reboot (Yeniden Başlatma) Atma işlemi sonrası sistem hiç gelmiyorsa, genelde sorun donanım değil; senin az önce değiştirdiğin bir ayar, güncellediğin kernel veya üzerinde oynadığın disk/RAID yapılandırmasıdır. Bu yüzden büyük değişikliklerden önce snapshot veya imaj almak hayat kurtarır.
Sıkça Sorulan Sorular
Sunucuya Reboot (Yeniden Başlatma) Atma güvenli mi?
Doğru koşullarda evet, oldukça güvenli. Özellikle panel üzerinden “soft reboot” olarak geçen, önce işletim sistemine kapanış sinyali gönderip sonra yeniden başlatan yöntemler sağlıklı. Ancak yoğun disk yazımı varken, veritabanı üzerinde büyük bir işlem sürerken ya da dosya sistemi zaten hata veriyorken zorla reboot atmak, veri kaybı riskini artırır. Ek önlem olarak, kritik veriler için mutlaka düzenli yedek alın ve mümkünse farklı bir sunucuda ya da object storage üzerinde saklayın.
Fiyat/Performans dengesi nasıl kurulur?
Dürüst olmak gerekirse, herkes önce fiyata bakıyor. Ama işlediğimiz konu Sunucuya Reboot (Yeniden Başlatma) Atma olduğunda, sık sık reboot atmak zorunda kaldığın bir sunucu aslında sana gizli maliyet çıkarıyor. Sürekli limitte çalışan, CPU’su ve RAM’i yetersiz bir makineyi zorlayıp her gün yeniden başlatmak yerine, bir tık üst pakete çıkmak çoğu zaman daha kârlı. Özellikle trafik yükseldikçe Cloud sunucu gibi ölçeklenebilir çözümler fiyat/performans dengesini daha sağlıklı kurmanı sağlar.
Taşıma (Migration) işlemi zor mu?
İyi planlanmamışsa evet, zor ve yorucu. Ama doğru araçları kullanıp, DNS geçişini kontrollü yapıp, eski sunucuyu hemen kapatmayıp birkaç gün paralel koşturursan süreç oldukça konforlu hale geliyor. Biz Bilhost tarafında taşıma konusunda epey tecrübe kazandık; çoğu zaman panelden tam yedek alıp yeni sunucuya aktarmak ve IP/DNS geçişini doğru zamanlamak yeterli oluyor. Sunucuya Reboot (Yeniden Başlatma) Atma işlemi de bu aşamada sadece son bir test adımı gibi düşünülmeli: Yeni sunucu reboot sonrası sorunsuz açılıyorsa, konfigürasyonun temeli sağlam demektir. Domain, hosting veya ek servis ihtiyacın varsa da web hosting ve domain sorgulama sayfalarından altyapını uçtan uca toparlayabilirsin.
Sonuç
İşin özü şu: Sunucuya Reboot (Yeniden Başlatma) Atma, elinin altında duran çok güçlü ama yanlış kullanıldığında can sıkıcı sonuçlar doğurabilen bir araç. Sadece “takıldı, bir reboot atayım” refleksiyle değil; önce kaynağı, log’u, firewall’ı kontrol edip sonra karar vermek gerekiyor. Tıpkı bir araba motoru gibi, sunucular da yüksek devirde (trafikte) doğru soğutmaya (kaynağa) ihtiyaç duyar. Teknoloji ne kadar karmaşık görünürse görünsün, doğru yapılandırma ve kontrollü yönetim hayat kurtarır. Eğer bir yerde takılırsan biz buradayız, yorumlarda sorularını bekliyorum.
Bu arada, performans ve kaynak tarafında daha geniş görmek isterseniz VDS sunucu sayfasındaki kaynak paketlerine göz atmak da iyi bir referans olur; hangi projeye ne kadar kaynak ayırmak gerektiği kafanda daha net oturur.
