Sunucu Kurtarma Desteği İçin Pratik Bir Rehber
27 Ağustos 2026 tarihinde yayımlandı
Bir sunucu acil durumu nadiren dramatik bir uyarıyla başlar. Daha sık olarak bir web sitesi yavaşlar, bir yedekleme işi sessizce başarısız olur, disk alanı daralır ya da bir güncelleme, diğer her şeyin bağlı olduğu tek bir ayarı değiştirir. Sunucu kurtarma desteğine ilişkin bu rehber, bir sunucu beklenmedik davranmaya başladığında stresli bir durumu daha da kötüleştirmeden nasıl yanıt vereceğinize dair pratik bir yaklaşım sunar.
Sunucu kurtarma desteği yalnızca bir web sitesini yeniden çevrimiçi duruma getirmekle ilgili değildir. Amaç; verileri korumak, kesinti süresini azaltmak, gerçek nedeni bulmak ve sunucuyu olay başlamadan öncekinden daha iyi durumda bırakmaktır. Bu da sakin bir süreç, net erişim ve gece 2'de rastgele düzeltmelerden kaçınma disiplini gerektirir.
Sunucu Kurtarma Desteği Gerçekte Neleri Kapsar
Sunucu kurtarma desteği; kullanılamayan, kararsız, güvenliği ihlal edilmiş, yanlış yapılandırılmış ya da kaynakları tükenmekte olan bir sunucu için uygulamalı yardımdır. Yapılacak iş tam olarak olaya bağlıdır, ancak yaygın olarak erişimin geri yüklenmesini, hizmetlerin kontrol edilmesini, günlüklerin incelenmesini, web siteleri veya veritabanlarının kurtarılmasını, sistemin güvenliğinin sağlanmasını ve sonrasında nelerin değişmesi gerektiğinin belirlenmesini içerir.
Kurtarma kelimesi her sorunun acil olduğu izlenimini verebilir. Bu her zaman tam bir hizmet kesintisi değildir. Gönderim yapmayı durdurmuş bir posta kuyruğu, kullanılabilir belleğin tamamını tüketen bir veritabanı ya da hata döndüren bir WordPress sitesi; hızlı ve dikkatli müdahale gerektirebilir. Doğru yanıt, iş etkisine ve canlı bir sistemde değişiklik yapmanın riskine bağlıdır.
Yararlı bir destek süreci üç işi birbirinden ayırır: hizmeti istikrara kavuşturmak, eksik veya bozuk olanı kurtarmak ve hatanın yeniden tekrarlanmasını önlemek. Bir site yeniden erişilebilir olmadan doğrudan önleme aşamasına geçmek sinir bozucudur. Site geri döndükten sonra önlemeyi atlamak ise aynı acil durumun gelecek hafta yeniden yaşanmasına yol açar.
Tahminle Değil, Kapsama ile Başlayın
Bir sunucu baskı altındayken, planlanmamış her değişiklik yeni bir değişken yaratır. İlk hedef, olayın yayılmasını durdurmaktır. Bu; bozuk bir siteyi bakım moduna almak, kontrolden çıkmış bir yedekleme görevini duraklatmak, şüpheli trafiği engellemek ya da otomatik bir dağıtımın çalışan dosyaların üzerine yazmasını önlemek anlamına gelebilir.
Kimse onarıma başlamadan önce temel bilgileri kaydedin: ne başarısız oldu, ne zaman başladı, hangi web siteleri veya hizmetler etkilendi ve yakın zamanda neler değişti. Başarısız bir güncelleme, süresi dolmuş bir sertifika, trafik artışı ya da hatalı bir DNS ayarlaması; incelemeyi farklı yönlere sevk edebilir.
Olayın Kapsamını Doğrulayın
Tek bir hata sayfası gördüğünüzde tüm sunucunun kapandığını varsaymayın. Sunucunun ağ üzerinden yanıt verip vermediğini, kontrol panelinin kullanılabilir olup olmadığını ve web sunucusu, veritabanı, posta hizmeti ile zamanlanmış görevler gibi tek tek hizmetlerin çalışıp çalışmadığını kontrol edin.
Ardından ziyaretçinin bakış açısından kontrol edin. Web sitesine her yerden erişilemiyor mu, yalnızca belirli bölgelerde mi yavaş, yoksa belirli bir hata mı döndürüyor? Örneğin 502 hatası, çoğu zaman web sunucusu ile bir uygulama hizmeti arasındaki iletişim sorununa işaret eder. 500 hatası; bir uygulama, izinler, hatalı bir yapılandırma ya da tükenmiş kaynaklardan kaynaklanabilir. Kod size bir başlangıç noktası verir, kesin hüküm değil.
Her Şeyi Yeniden Başlatmadan Önce Kanıtları Koruyun
Bir hizmeti yeniden başlatmak doğru çözüm olabilir. Bir şeyler yanlış görünüyor diye tüm sunucuyu yeniden başlatmak, çoğu zaman yalnızca yararlı ipuçlarını silmenin hızlı bir yoludur.
Önce son günlükleri, CPU ve bellek kullanımını, disk kapasitesini, başarısız oturum açma girişimlerini, etkin süreçleri ve hizmet durumunu inceleyin. Bir veritabanı kilitliyse ya da bir süreç kaynak tüketiyorsa, bu bilgiler sunucunun neden başarısız olduğunu açıklamaya yardımcı olur. Ayrıca destek ekiplerinin yalnızca belirtinin üzerini örten bir düzeltme uygulamasını da önlemeye yardımcı olur.
Bir güvenlik olayından şüpheleniyorsanız, günlükleri koruyun ve incelenene kadar tanımadığınız dosyaları silmekten kaçının. Çok hızlı temizlik yapmak, erişimin nasıl elde edildiğini anlamak için gereken kanıtları ortadan kaldırabilir.
Net Bir Kurtarma Özeti Oluşturun
İyi sunucu kurtarma desteği, yardım eden kişinin durumu dağınık ekran görüntüleri ve yarım yamalak hatırlanan değişikliklerden yeniden kurmak zorunda kalmaması durumunda daha hızlı olur. Sorunu üst ekibe iletmeden önce kısa bir kurtarma özeti hazırlayın.
Şu ayrıntıları ekleyin:
- Sunucunun IP adresi veya ana makine adı ve etkilenen alan adları
- Saat dilimi dâhil olmak üzere sorunun başladığı zaman
- Tam hata mesajı, ekran görüntüleri veya son izleme uyarıları
- Güncellemeler, DNS, SSL, eklentiler, güvenlik duvarı kuralları veya dağıtımlarla ilgili son değişiklikler
- Web siteleri, veritabanları, e-posta veya kontrol paneli gibi etkilenen hizmetler
- Panel erişimi, SSH erişimi, sağlayıcı konsol erişimi ve yedekleme konumları dâhil olmak üzere mevcut erişim yöntemleri
Parolaları asla korumasız bir mesajda göndermeyin. Geçici kimlik bilgilerini paylaşmak için onaylı güvenli yöntemi kullanın ve olaydan sonra bu kimlik bilgilerini kaldırın veya değiştirin. Bu, sırf evrak işi olsun diye yapılan bir işlem değildir. Sunucunun kendisine erişilemediğinde hiç kimse sağlayıcı konsoluna erişemediği için kurtarma çalışması bir saat boyunca durabilir.
Hizmeti Doğru Sırayla Geri Yükleyin
Çalışan bir web sitesine giden en hızlı yol her zaman en güvenli yol değildir. Bir veritabanı geri yüklemesi verileri geri getirebilir, ancak son siparişlerin, form gönderimlerinin veya müşteri kayıtlarının üzerine yazabilir. Bir yapılandırmayı hafızadan yeniden oluşturmak erişimi geri getirebilir, ancak daha sonra postayı veya yenilemeleri bozacak küçük bir hataya yol açabilir.
En az yıkıcı kurtarma seçeneğiyle başlayın. Bir hizmet yalnızca durmuşsa, nedenini araştırın ve ancak sunucunun onu çalışır durumda tutacak kadar disk, bellek ve kullanılabilir sürece sahip olduğunu doğruladıktan sonra yeniden başlatın. Bir güncelleme arızaya neden olduysa, bilinen tek bir değişikliği geri almak; bir bileşen yığınını yeniden kurmaktan daha güvenli olabilir.
Veri kurtarma için önce kurtarma noktası hedefini belirleyin. Düz Türkçeyle: işletme ne kadar yeni veriyi kaybetmeyi göze alabilir? Beş dakika önce alınmış bir yedek, bir önceki gece alınmış bir yedekten farklıdır. Yoğun bir e-ticaret sitesi için yeni işlemler hesaba katılmadan bir veritabanını geri yüklemek, ilk kesintiden daha büyük bir operasyonel sorun yaratabilir.
Yedeklere Süs Değil, Kurtarma Aracı Olarak Yaklaşın
Bir yedek yalnızca bulunabiliyor, erişilebiliyor ve geri yüklenebiliyorsa önemlidir. Kurtarma sırasında yedek tarihini doğrulayın, dosyaların eksiksiz olduğunu kontrol edin ve yedeğin veritabanlarını, web sitesi dosyalarını, posta kutularını ve sunucu yapılandırmasını içerip içermediğini onaylayın.
Mümkün olduğunda önce ayrı bir konuma geri yükleyin. Bu, üretim içeriğini değiştirmeden önce verilerin kullanılabilir olduğunu doğrulamanıza olanak tanır. Biraz daha uzun sürer, ancak müşteri verileri veya birden fazla barındırılan hesap söz konusu olduğunda genellikle buna harcanan zamana değer.
FASTPANEL, temel web sitesi, alan adı, veritabanı ve sunucu yönetimi görevlerini tek ve net bir çalışma alanında tutmaya yardımcı olur; bu da sorun gidermenin ilk aşamalarını çok daha az kaotik hâle getirebilir. Bir kontrol paneli iyi olay yönetiminin yerini almaz, ancak görünürlük ve düzenli erişim size çok daha iyi bir başlangıç noktası sağlar.
Sorunun Tek Bir Hizmetten Daha Büyük Olduğunu Ne Zaman Anlamanız Gerektiğini Bilin
Bazı sorunlar yerel gibi görünür ama aslında altyapı sorunlarıdır. DNS yanlış adrese işaret ederken bir web sunucusu sağlıklı olabilir. Bir site, SSL sertifikasının süresi dolduğu için başarısız olabilir. Bir veritabanı hatası dolu bir diskten kaynaklanabilirken, gerçek disk kullanımı aşırı büyük günlüklerden veya unutulmuş yedek arşivlerinden geliyor olabilir.
Başarısız olan hizmetin çevresindeki bağımlılıkları kontrol edin: ağ erişilebilirliği, DNS kayıtları, sertifika geçerliliği, depolama, bellek, güvenlik duvarı kuralları, üst sağlayıcının durumu ve uygulama yapılandırması. Kurtarma desteğinin değerini gösterdiği yer burasıdır. Görünen arıza çoğu zaman yalnızca son dominodur.
Güvenlik olayları ekstra dikkat gerektirir. Beklenmedik yönetici hesapları, değiştirilmiş dosyalar, giden spam, kripto madenciliği süreçleri veya tekrarlanan oturum açma girişimleri olağan performans sorunları gibi ele alınmamalıdır. Gerekirse etkilenen hizmeti izole edin, kimlik bilgilerini değiştirin, erişim günlüklerini inceleyin, giriş noktasını yamalayın ve kalıcılık mekanizmalarını tarayın. Temiz görünümlü bir web sitesi yine de güvenliği ihlal edilmiş bir sunucuya bağlı olabilir.
Çalışma Sürerken İletişim Kurun
Sessizlik, kesintinin daha uzun sürdüğü hissini yaratır. İster tek bir web sitesini ister yüzlerce müşteri hesabını yönetin, erken aşamada kısa bir güncelleme gönderin: neler etkilendi, ekip incelemeye ne zaman başladı ve bir sonraki güncelleme ne zaman gelecek. Yeterli kanıta sahip olmadan geri yükleme süresi konusunda söz vermekten kaçının.
Güncellemeleri olgusal tutun. Sorun test edilene kadar düzeldi demek yerine veritabanı bağlantısının geri yüklendiğini söyleyin. Hizmet geri döndüğünde, insanların gerçekten kullandığı yolları doğrulayın: ana sayfa, oturum açma, ödeme veya iletişim formları, e-posta teslimi, zamanlanmış işler ve yönetici erişimi. Yeşil bir durum göstergesi yararlıdır, ancak gerçek bir test daha iyidir.
Kurtarmayı Daha İyi Bir Kuruluma Dönüştürün
Acil sorun çözüldükten sonra, zaman çizelgesi hâlâ tazeyken kısa bir değerlendirme planlayın. Neyin başarısız olduğunu, mevcut uyarının bunu neden önlemediğini, kurtarmayı neyin geciktirdiğini ve hangi tek iyileştirmenin riski en çok azaltacağını sorun.
Yanıt basit olabilir: disk uyarılarını artırmak, geri yüklemeleri aylık olarak test etmek, terk edilmiş eklentileri kaldırmak, sağlayıcı konsol erişimini belgelendirmek, yedekleri sunucudan ayırmak veya durana kadar görünmez olan bir hizmet için izleme kurmak. Her olay büyük bir yeniden tasarım gerektirmez. Küçük, hedefe yönelik iyileştirmeler çoğu zaman gelecekteki stresi en çok azaltan sonuçları verir.
Sunucu kurtarma desteği, panik düğmesi olarak değil bir süreç olarak ele alındığında en iyi şekilde çalışır. Erişimi düzenli tutun, yedekleri test edilebilir tutun, önemli kaynakları izleyin ve yapılan değişikliklerin neden yapıldığını kayda geçirerek hareket edin. Bir şey gerçekten ters gittiğinde, çözecek daha az gizeminiz ve normale dönüş için çok daha net bir yolunuz olur.