Sunucu Bakım Kontrol Listesi: Günlük, Haftalık ve Aylık Görevler

Sunucu bakımı; güvenlik güncellemelerinin uygulanması, servislerin ve disk alanının kontrolü, logların incelenmesi, yedeklerin tamamlandığının ve geri yüklenebildiğinin doğrulanması ile kullanıcı erişimlerinin denetlenmesidir. Servis ve disk kontrolleri günlük, güncelleme ve log incelemesi haftalık, yedekten geri dönüş testi ve erişim denetimi aylık yapılmalıdır. Rutin kontrollerin çoğu cron ve izleme araçlarıyla otomatikleştirilebilir.

Aşağıdaki liste Linux sunucular için yazıldı; Windows Server karşılıklarını ayrı bir tabloda verdik. Her görevin yanında, Bulutzone sunucu yönetimi paketleri içinde birebir karşılığı olup olmadığını da gösterdik.

Sunucu bakımı nedir, neden periyodik yapılır?

Sunucu bakımı, arızayı beklemeden yapılan düzenli kontrollerin toplamıdır. Periyodik yapılır, çünkü sorunların çoğu bir anda değil yavaş yavaş oluşur: disk her gün biraz dolar, yamalanmamış paket sayısı her hafta artar, sertifikanın bitiş tarihi sessizce yaklaşır. Bir takvime bağlanmayan kontrol, genellikle ilk kesintiye kadar ertelenir.

Özet tablo, hangi işin ne sıklıkla yapılacağını ve nasıl otomatikleştirileceğini gösteriyor. "SLA karşılığı" sütunu yalnızca Bulutzone paket listesinde birebir yer alan kalemleri gösterir; tire işaretli satırlar için kapsamı ayrıca sormanız gerekir.

Günlük kontroller

Günlük kontrollerin amacı, kullanıcıdan önce sorunu görmektir. Üç şeye bakılır: servisler çalışıyor mu, disk doluyor mu, sunucuya birileri zorla girmeye çalışıyor mu?

Servis durumu ve uptime

systemd, Linux'ta servisleri başlatan ve izleyen sistem yöneticisidir. Çökmüş servisleri ve sunucunun ne zamandır açık olduğunu şöyle görürsünüz:

systemctl --failed
uptime
curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://ornek.com

Son komut sitenin HTTP durum kodunu ve yanıt süresini verir. 200 dışında bir kod ya da olağandan uzun bir süre, servis ayakta olsa bile bir şeylerin ters gittiğini gösterir. Bu kontrolü elle değil, bir izleme aracıyla dakikalık aralıklarla yaptırmak gerekir.

Disk ve inode doluluğu

Inode, dosya sistemindeki her dosya için tutulan kayıttır. Disk alanı boş görünse bile inode tükenirse yeni dosya oluşturulamaz; milyonlarca küçük oturum ya da önbellek dosyası üreten sitelerde bu sık görülür.

df -h
df -i
sudo du -xh /var --max-depth=2 | sort -rh | head -15

Doluluk yüzde 80'i geçtiğinde uyarı, yüzde 90'da kritik alarm almak iyi bir başlangıç eşiğidir. Log dosyaları büyüyorsa önce logrotate yapılandırmasına bakın. systemd journal'ını sudo journalctl --vacuum-size=500M ile küçültebilirsiniz; bu komut eski kayıtları kalıcı olarak siler, inceleme gerekiyorsa önce dışa aktarın.

Başarısız giriş denemeleri

İnternete açık her sunucu, otomatik tarayıcıların SSH denemeleriyle karşılaşır. Önemli olan sayının kendisi değil, ani artışlar ve başarılı olmaması gereken bir girişin görünmesidir.

# Ubuntu / Debian (servis adı: ssh)
sudo journalctl -u ssh --since today | grep -Ei "failed|invalid" | tail -20

# AlmaLinux / Rocky (servis adı: sshd)
sudo journalctl -u sshd --since today | grep -Ei "failed|invalid" | tail -20

# Her iki dağıtımda
sudo lastb | head -20
last -a | head -20
sudo fail2ban-client status sshd

last çıktısında tanımadığınız bir IP'den başarılı giriş görürseniz bunu olağan bakım değil, olay müdahalesi olarak ele alın. Deneme sayısını kalıcı olarak azaltmanın yolu, SSH'ı anahtarla girişe taşımak ve sunucuyu adım adım sıkılaştırmaktır.

Haftalık kontroller

Haftalık döngü, sunucunun güncel ve geri döndürülebilir durumda olduğunu teyit eder.

Güvenlik güncellemeleri

Ubuntu'da unattended-upgrades paketi varsayılan olarak kuruludur ve güvenlik güncellemelerini kendiliğinden uygular. AlmaLinux ve Rocky'de aynı işi dnf-automatic yapar. Otomasyon açık olsa bile haftada bir bekleyen güncellemelere ve yeniden başlatma ihtiyacına bakın:

# Ubuntu / Debian
sudo apt update && apt list --upgradable
ls /var/run/reboot-required

# AlmaLinux / Rocky
sudo dnf check-update --security
sudo dnf needs-restarting -r

Kernel güncellemeleri ancak yeniden başlatmayla devreye girer. reboot-required dosyası varsa ya da needs-restarting yeniden başlatma öneriyorsa, bunu trafiğin düşük olduğu bir saate planlayın.

Yedeklerin tamamlandığının doğrulanması

Yedek işinin hata vermeden bitmesi, yedeğin doğru olduğu anlamına gelmez. Her hafta son yedeğin tarihine, boyutuna ve önceki haftalarla tutarlılığına bakın. Boyutu birden yarıya düşen bir yedek, genellikle bir dizinin ya da veritabanının dışarıda kaldığını gösterir.

ls -lh --time-style=long-iso /yedek | tail -5
restic snapshots --latest 3

Log incelemesi

Log incelemesi, hata ve uyarı seviyesindeki kayıtların düzenli okunmasıdır. Tüm logları okumak gerçekçi değildir; önceliği hata seviyesine verin ve aynı hatanın tekrar edip etmediğine bakın.

sudo journalctl -p err --since "7 days ago" --no-pager | tail -50

Aylık kontroller

Yedekten geri dönüş testi

Ayda bir, rastgele bir yedeği ana sunucudan ayrı bir test ortamına geri yükleyin. Uygulama açılıyor mu, veritabanındaki son kayıtlar beklenen tarihte mi, geri yükleme ne kadar sürdü? Bu sürenin kaydını tutun; felaket anında ne kadar süre kapalı kalacağınızın en gerçekçi tahmini budur. Geri yüklenmesi hiç denenmemiş bir yedek, yalnızca bir varsayımdır.

Kullanıcı ve SSH anahtarı denetimi

Projeden ayrılan geliştiricilerin hesapları ve anahtarları çoğu zaman sunucuda kalır. Ayda bir oturum açabilen kullanıcıları, sudo yetkisi olanları ve yetkili SSH anahtarlarını listeleyin:

awk -F: '$3 >= 1000 {print $1, $7}' /etc/passwd
getent group sudo wheel
sudo find / -xdev -name authorized_keys -path "*/.ssh/*" 2>/dev/null
ssh-keygen -lf ~/.ssh/authorized_keys

Son komut anahtarların parmak izlerini ve yorum alanlarını gösterir. Kime ait olduğunu bilmediğiniz bir anahtarı sorgulamadan bırakmayın.

SSL sertifika süreleri

Son güncelleme itibarıyla Let's Encrypt'in varsayılan sertifikaları 90 gün geçerlidir. Let's Encrypt süreleri kademeli olarak kısaltma planını da açıkladı: isteğe bağlı tlsserver profili Mayıs 2026'dan beri 45 günlük sertifika veriyor, varsayılan profilin Şubat 2027'de 64 güne, Şubat 2028'de 45 güne inmesi planlanıyor. Süre kısaldıkça otomatik yenilemenin çalıştığını kontrol etmek daha önemli hale gelir:

sudo certbot certificates
sudo certbot renew --dry-run
echo | openssl s_client -connect ornek.com:443 -servername ornek.com 2>/dev/null | openssl x509 -noout -enddate

Kaynak kullanım trendi

Tek bir anlık CPU değeri az şey söyler; önemli olan aydan aya eğilimdir. Bellek kullanımı her ay biraz artıyorsa ya da gece yedek saatinde disk beklemesi yükseliyorsa, bunu kesinti yaşanmadan kapasite planına yansıtın. sysstat paketindeki sar komutu ya da bir izleme sisteminin grafikleri bu iş için yeterlidir.

Üç aylık ve yıllık kontroller

İşletim sistemi destek süresi (EOL)

EOL (end of life), bir işletim sistemi sürümünün güvenlik güncellemesi almayı bıraktığı tarihtir. Bu tarihten sonra açılan her yeni zafiyet sunucunuzda kalıcı olarak açık kalır. Sürümünüzü cat /etc/os-release ile görün ve takvimle karşılaştırın:

Ubuntu LTS sürümleri beş yıl standart güvenlik bakımı alır; sonrası için ücretli uzatılmış bakım seçenekleri vardır. Sürüm yükseltmesini son aya bırakmayın, test ortamında deneyip en az bir çeyrek önceden planlayın.

Felaket kurtarma tatbikatı

Yılda bir, sunucunun tamamen kaybolduğunu varsayın ve sıfırdan ayağa kaldırmayı deneyin. Hangi yedekten, hangi sırayla, kimin şifreleriyle? Tatbikat genellikle dokümante edilmemiş bir adımı, eksik bir yapılandırma dosyasını ya da tek bir kişinin kafasındaki bir şifreyi ortaya çıkarır. Ölçtüğünüz süreyi iş tarafının kabul edebileceği kesinti süresiyle karşılaştırın.

Otomatikleştirilebilecekler (cron, izleme)

Cron, komutları belirli zamanlarda çalıştıran Linux zamanlayıcısıdır. Ölçüm ve alarm gerektiren kontroller otomatikleştirilmeli; karar gerektirenler insanda kalmalıdır. Örneğin disk doluluğu yüzde 85'i geçtiğinde çıktı üreten bir cron satırı:

MAILTO=operasyon@ornek.com
0 * * * * df -P -x tmpfs -x devtmpfs | awk 'NR>1 && $5+0 >= 85 {print $6, $5}'

Cron yalnızca komut çıktı ürettiğinde e-posta gönderir; bunun için sunucuda e-posta gönderebilen bir servis gerekir. Yoksa aynı eşiği izleme aracınızda tanımlayın. Otomasyona uygun diğer işler: güvenlik güncellemeleri, sertifika yenileme, log döndürme ve servis izleme. Geri dönüş testinin değerlendirilmesi, kullanıcı denetimi ve ana sürüm yükseltmeleri ise insan kararı ister.

Windows Server karşılıkları

Durmuş servisler listesinde başlangıç türü elle ayarlı olan ve zaten çalışmaması gereken servisler de görünür; yalnızca otomatik başlaması gerekenlere odaklanın.

Kopyalanabilir kontrol listesi

Aşağıdaki listeyi kopyalayıp kendi takviminize ya da iş takip aracınıza ekleyebilirsiniz:

GÜNLÜK
- Çökmüş servis var mı (systemctl --failed)
- Site ve API HTTP 200 dönüyor mu
- Disk ve inode doluluğu yüzde 80 altında mı
- Başarısız giriş denemelerinde ani artış var mı

HAFTALIK
- Güvenlik güncellemeleri uygulandı mı, yeniden başlatma gerekiyor mu
- Son yedek tamamlandı mı, boyutu tutarlı mı
- Hata seviyesindeki loglar okundu mu
- Kontrol paneli güncel mi

AYLIK
- Bir yedek test ortamına geri yüklendi mi, süre kaydedildi mi
- Kullanıcılar, sudo yetkileri ve SSH anahtarları denetlendi mi
- SSL sertifikaları ve otomatik yenileme kontrol edildi mi
- Firewall kuralları gözden geçirildi mi
- CPU, RAM ve disk trendi incelendi mi

ÜÇ AYLIK / YILLIK
- İşletim sistemi EOL tarihi kontrol edildi mi
- Felaket kurtarma tatbikatı yapıldı mı

Bu işleri kim yapmalı?

Listeyi düzenli uygulayacak birini adıyla belirleyemiyorsanız, liste uygulanmıyor demektir. Bu kişi ekibinizden biri olabilir ya da işlerin bir kısmını sağlayıcıya devredebilirsiniz; iki modelin sorumluluk sınırlarını managed ve unmanaged sunucu farkı yazısında ayrıntılı anlattık.

Özet tabloda SLA karşılığı olan satırlar, Bulutzone paketlerinde listelenen kalemlerdir: kontrol paneli güncellemesi SLA-1'de; işletim sistemi güncelleme, ping izleme, servis kontrolü ve log analizi SLA-2'de; web, SQL ve mail servis izleme, saldırı tespiti ve yazılımsal firewall işlemleri SLA-3'te yer alır. SLA-1 sunucuyla birlikte ücretsiz gelir. Geri dönüş testi, SSL takibi, kullanıcı denetimi ve EOL planı gibi karşılığı olmayan satırlar ayrıca anlaşılmadıkça sizde kalır.

Sık sorulan sorular

Bakım sırasında kesinti olur mu?

Kontrollerin çoğu, yani servis, disk, log ve kullanıcı denetimi, kesinti gerektirmez. Kesinti genellikle kernel güncellemesinden sonraki yeniden başlatmada ve servis yeniden başlatmalarında yaşanır; bu süre çoğunlukla birkaç dakikadır. Bu işleri trafiğin düşük olduğu saatlere planlayıp kullanıcılarınıza önceden duyurun.

Otomatik güncelleme açık olmalı mı?

Güvenlik güncellemeleri için evet; bilinen bir açığın yamasını haftalarca bekletmek, nadir görülen bir güncelleme sorunundan daha büyük risktir. Ana sürüm yükseltmeleri ve veritabanı, PHP gibi uygulamayı doğrudan etkileyen paketler ise test edilerek elle yapılmalıdır. Otomatik yeniden başlatmayı açacaksanız saatini açıkça belirleyin.

Sunucu bakımı ne sıklıkla yapılmalı?

Ölçüme dayalı kontroller sürekli ya da günlük, güncelleme ve log incelemesi haftalık, geri dönüş testi ve erişim denetimi aylık, EOL ve felaket kurtarma planı yılda en az bir kez gözden geçirilmelidir. Çok sayıda kullanıcısı ya da ödeme alan bir sitesi olan sunucularda aylık işleri iki haftaya indirmek mantıklıdır.

Bu listedeki güncelleme, izleme, log ve güvenlik kalemlerini kendiniz takip etmek yerine devretmek isterseniz sunucu yönetimi paketlerini inceleyin; hangi kalemin hangi pakette olduğunu yukarıdaki tabloyla karşılaştırabilirsiniz.

Kaynaklar

• Ubuntu Server documentation: Automatic updates
• Rocky Linux documentation: Patching servers with dnf-automatic
• Let's Encrypt: FAQ
• Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days
• Ubuntu release cycle
• AlmaLinux release notes