Linux Sunucu Bakım Kontrol Listesi ve Periyodik İşlemler

Linux sunucu bakımı gerçekte ne anlama gelir

Linux sunucu bakımı, bitişi olan bir proje değil, sabit bir takvimde yürütülen kısa bir kontrol listesidir. Haftalık olarak güncellemelerin yüklendiğini, diskte yer olduğunu, hiçbir servisin durmadığını ve yedekleme görevinin tamamlandığını doğrulamanız gerekir. Aylık olarak bir geri yükleme testi yapmalı, sertifika geçerlilik sürelerini kontrol etmeli, hesapları ve anahtarları denetlemeli, eski çekirdekleri ve log dosyalarını temizlemelisiniz. Her dağıtım sürümü için bir kez, sürüm yükseltme planı yapmalı ve erteleyip durduğunuz yeniden başlatma işlemini gerçekleştirmelisiniz.

Sunucuyu kurmak farklı bir iştir ve yeni bir VPS üzerindeki ilk on dakika bu kısmı kapsar. Bu sayfa ise kurulumdan sonraki yılı anlatır. Aşağıdaki her madde, önlediği hata durumunu belirtir; çünkü sonuçları olmayan bir kontrol listesi, insanların sessizce uygulamayı bıraktığı bir listedir.

Buradaki komutlar örnek niteliğindedir ve çalıştırılmadan önce okunmalıdır. Çıktılarını kendi sunucunuzla karşılaştırın, çünkü boş alan veya süreç sayısı için sağlıklı bir değer, sunucunun ne yaptığına bağlıdır. Bir kontrolün dağıtımlar arasında farklılık gösterdiği durumlarda metin bunu belirtir. Örnekler, apt kullanan Debian ve Ubuntu içindir. RHEL ailesinde araç dnf şeklindedir ve bazı yollar farklıdır.

Sürdürülebilir bir Linux sunucu bakım takvimi nasıl belirlenir

Haftalık kontroller, siz müdahale etmeseniz dahi değişen unsurları kapsar: paketler, disk kullanımı, servis durumu ve zamanlanmış görevler. Bu unsurlar kendi başlarına değişim gösterdiğinden, bir haftadan daha uzun süre kontrolsüz bırakılmamaları gerekir.

Aylık kontroller, yavaş ilerleyen bozulmaları kapsar: süresi dolmak üzere olan sertifikalar, silinmemiş kullanıcı hesapları, /boot dizininde biriken çekirdek dosyaları ve eşleşme kuralı artık çalışmayan log dosyaları. Bunların hiçbiri yarın sorun çıkarmaz; ancak hepsi zamanla bir arıza noktasına ulaşır.

Sürüm kontrolleri takvime bağlıdır. Bir dağıtım sürümü, dış kaynaklı bir son tarihe sahip olan tek bakım öğesidir; çünkü mevcut sürümünüzün destek süresi, siz hazır olsanız da olmasanız da sona erer.

Bakım işlemlerini sabit bir zamana planlayın; haftalık kontroller için Pazartesi sabahını, aylık kontroller için ise ayın ilk gününü seçin. "Vaktim olduğunda yaparım" yaklaşımıyla hazırlanan bir kontrol listesi, gerçek bir kontrol listesi değildir. Birkaç sunucudan fazlasını yönetiyorsanız, bu işlemleri manuel yapmak yerine tek bir merkezden yürütün; bu konu birden fazla Linux sunucusunu tek merkezden yönetme başlığında ele alınmıştır.

Haftalık: Güncellemeler gerçekten yüklendi mi?

unattended-upgrades özelliğini etkinleştirmek, çalıştığından emin olmakla aynı şey değildir. Servis maskelenmiş olabilir, yapılandırma kullanmadığınız bir kaynağa kısıtlanmış olabilir ve tutulan (held) tek bir paket sonraki tüm çalıştırma işlemlerini bozabilir. Kurulum süreci Ubuntu üzerinde otomatik güvenlik güncellemeleri bölümünde ele alınmıştır. Haftalık işin amacı, kurduğunuz sistemin görevini yerine getirdiğini kanıtlamaktır.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable dürüst bir ölçüttür; çünkü niyetten ziyade mevcut durumu raporlar. Bu listede bekleyen güvenlik güncellemeleri, otomasyonun görevini yapmadığı anlamına gelir; bu nedenle makinenin yamalandığını varsaymadan önce günlük kayıtlarını okuyun. apt-mark hold ile sabitlenmiş (pinned) bir paket sonsuza kadar atlanır ve hiçbir şey rapor etmez; bu yüzden apt-mark showhold aynı geçiş sürecine dahil edilmelidir.

Bu yaklaşımın önlediği hata şudur: Güncellemelerin otomatik olduğunu düşünürken, bilinen bir güvenlik açığına sahip paketi aylarca çalıştırmak.

Haftalık: disk ve inode kapasitesi

Dolu bir kök dosya sistemi, disk ile ilgisi yokmuş gibi görünen sorunlara yol açar. Veritabanı yazma işlemlerini reddeder, günlük kaydı durur, paket yükseltme işlemi yarıda kalır ve bazı kurulumlarda, kendi dosyalarını yazamadığı için yeni bir oturum açamazsınız.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i, çoğu kişinin göz ardı ettiği kısımdır. Inode'lar, dosya meta verilerini tutan sabit sayılı yapılardır ve bir dosya sistemi, df -h hala boş gigabaytlar gösterse bile bu yapılardan tüketebilir. Bu durumda yazma işlemleri, boş alan olduğunu gösteren bir çıktının yanında No space left on device hatasıyla başarısız olur; bu durum ilk karşılaşıldığında kafa karıştırıcı bir saat kaybetmenize neden olur. Sıkışmış bir posta kuyruğundan veya kimsenin temizlemediği bir oturum dizininden kaynaklanan milyonlarca küçük dosya, genellikle bu sorunun nedenidir.

du -xh, bind mount veya bağlı depolama birimleri olan bir sunucuda istediğiniz gibi tek bir dosya sistemi üzerinde kalır. Bir Docker ana makinesinde çözüm genellikle, VPS üzerinde Docker disk kullanımını temizleme bölümünde açıklandığı gibi temizlenen imaj katmanları ve kullanılmayan volume'lardır.

Boş alan size kapasite hakkında bilgi verir. Alttaki depolama birimi kendi zaman çizelgesine göre arızalanır; bu, VPS üzerinde disk sağlığı izleme bölümünde ele alınan ayrı bir kontroldür.

Haftalık: Size bildirimde bulunmadan duran nedir?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Çöken ve yeniden başlatma sınırına ulaşan bir birim, başarısız (failed) durumunda kalır ve sessizleşir. Bu durum hakkında size hiçbir e-posta gönderilmez. list-timers, daha kullanışlı olan kısımdır: her zamanlayıcının en son ne zaman çalıştığını ve bir sonraki sefer ne zaman tetikleneceğini gösterir. Bu nedenle, LAST değerinin zamanlayıcının kendi aralığından daha eski olması, ilgili işin hiç çalışmadığı anlamına gelir.

Birim için günlük kayıtlarını yeniden başlatmadan önce journalctl -u <unit> -n 100 --no-pager ile okuyun. Yeniden başlatma işlemi belirtiyi ortadan kaldırır; bu durumda aynı olay daha kötü bir saatte tekrar yaşanana kadar inceleme yapmanız için bir nedeniniz kalmaz.

Bu uygulamanın önlediği hata şudur: üç hafta önceki bir bellek artışından beri ölü olan bir izleme aracısı, kuyruk işleyicisi veya yedekleme servisi.

Haftalık: Yedekleme işi gerçekten tamamlandı mı?

Zamanlanmış bir yedekleme ile tamamlanmış bir yedekleme farklı durumlardır; yalnızca ikincisi geri yüklenebilir. Tamamlanma durumunu kontrol edin.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

İki şeyi doğrulayın. Son çalıştırma sıfır çıkış koduyla tamamlanmış olmalı ve en yeni arşiv hem güncel hem de beklenen boyuta yakın olmalıdır. Aniden normal boyutunun onda birine düşen bir yedekleme dosyası, dosya yazmış olsa bile başarısız olmuş bir dökümdür. Bu, yedekleme hatalarının en tehlikeli biçimidir çünkü süreçteki tüm sonraki adımlar normal görünür.

Eğer betiğiniz bir dökümü sıkıştırıcıya yönlendiriyorsa, betiğin en üstüne set -o pipefail ekleyin. Bu olmadan, işlem hattının çıkış durumu sıkıştırıcının durumuna göre belirlenir ve sıkıştırıcı hata mesajını başarıyla sıkıştırdığı için başarılı sayılır. Bu durumda iş, her gece hiçbir şey içermeyen küçük bir arşiv yazarken başarı raporu vermeye devam eder.

Aylık: yedeği başka bir yere geri yükleyin

Bu, çoğu kişinin atladığı ancak listenin geri kalanının bir anlam ifade edip etmeyeceğine karar veren maddedir.

Yedeği canlı verilerin üzerine değil, farklı bir makineye veya yeni bir container ortamına geri yükleyin. Ardından geri yüklediğiniz verileri açın ve gerçek olduklarını doğrulayın. Bir tablodaki satırları sayın. Bir belgeyi açın. Geri yüklenen uygulamaya giriş yapın. Tamamlanmış bir dışa aktarma işlemi, yalnızca arşivin okunabilir olduğunu kanıtlar, fazlasını değil.

Depo araçlarının kendi doğrulama mekanizmaları vardır: restic check --read-data-subset=5% ve borg check --verify-data, dizin yerine depolanan verileri okur. Bunları çalıştırın ve bir yedek yerine bir duman testi (smoke test) olarak değerlendirin. Doğrulama, baytların hayatta kaldığını kontrol eder. Geri yükleme ise, bu baytların uygulamanızın ihtiyaç duyduğu veriler olduğunu doğrular.

İnsanların zor yoldan öğrendiği iki detay vardır. Şifre çözme parolasını, anahtarı halihazırda bir aracıda (agent) tutmayan bir makinede test edin; çünkü şifresini çözemediğiniz bir yedek, yedek değildir. Ayrıca geri yükleme süresini ölçün; çünkü bu süre sizin gerçek kurtarma sürenizdir ve bunu keşfetmek için en yaygın an, bir kesinti sırasıdır.

Aylık: Hangi sertifikaların süresi yakında doluyor?

Yenileme otomasyonu sessizce başarısız olabilir. certbot zamanlayıcısı diskteki dosyayı yenilese bile, web sunucusu servisi yeniden yükleyen deploy hook çalışmadığı için bellekteki eski sertifikayı sunmaya devam edebilir. Bu nedenle, çalışan sunucuya dışarıdan bağlanarak hangi sertifikayı sunduğunu sorgulayın.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

-servername bayrağı, birden fazla site barındıran her adreste gerekli olan SNI (server name indication) ayarını yapar; aksi takdirde size ait olan yerine varsayılan sertifika sunulur. Eğer certbot bir snap üzerinden kurulduysa zamanlayıcının adı farklı olacaktır, bu yüzden varsayılan bir birim adı yerine ilgili kelimeyi aratarak eşleştirme yapın.

Otomasyonu olmayan sertifikaları unutmayın: bir posta sunucusu, VPN veya dahili bir sertifika yetkilisi (CA). Bunlar genellikle hafta sonu süresi dolan ve tarayıcılar ile istemcilerin uyarı vermek yerine doğrudan reddettiği sertifikalardır.

Aylık: kullanıcılar, sudo erişimi ve SSH anahtarları

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T, her Include birleştirildikten sonra daemon tarafından fiilen kullanılacak olan nihai yapılandırmayı yazdırır. Güncel Ubuntu imajları, /etc/ssh/sshd_config.d/ dizininde ek yapılandırma dosyaları ile gelir ve bunlar ana dosyayı geçersiz kılabilir; bu nedenle yalnızca sshd_config dosyasını okumak sizi yanıltabilir. RHEL ailesinde yönetim grubu sudo yerine wheel olduğundan, getent satırını buna göre düzenleyin.

Ardından authorized_keys dosyalarını inceleyin. Erişim hesap bazlı değil, anahtar bazlı verildiğinden, altı ay önce işi biten bir yüklenicinin geride bıraktığı anahtar, kullanıcı listesinde görünmeyen aktif bir giriş yöntemidir. Anahtarlar bir açıklama alanı içerir. Bu alanı kullanın ve kime ait olduğunu doğrulayamadığınız tüm anahtarları silin.

Giriş geçmişi için journalctl -t sshd --since "30 days ago" | grep -i accepted, birim adı yerine syslog tanımlayıcısına göre eşleşme yapar. Bu önemlidir çünkü Ubuntu 24.04, SSH servisini bir soket üzerinden etkinleştirir; bu nedenle her bağlantı, oluşturulan bağlantı bazlı bir birim altında günlüğe kaydedilir ve düz bir journalctl -u ssh komutu bu kayıtları gözden kaçırabilir.

Aylık bakım: eski çekirdekler ve dolu /boot bölümü

/boot, standart bir VPS imajında genellikle birkaç yüz megabaytlık ayrı bir bölümdür. Her çekirdek güncellemesi buraya bir imaj ve bir initramfs ekler. Bölüm dolduğunda, bir sonraki yükseltme işlemi yarıda kesilir ve paketler yapılandırılmamış halde kalır; bu durum, bir Cuma günü beklenmedik bir şekilde karşılaşılmaması gereken kötü bir senaryodur.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r komutu her zaman ilk adım olmalıdır: şu anda çalışan çekirdeği belirtir ve kaldırma işlemi sırasında bu çekirdeğin korunması gerekir. apt autoremove, Debian ve Ubuntu üzerinde normal durumları yönetir; çünkü çekirdekler otomatik yüklenmiş olarak işaretlenir ve mevcut olan korunur. Elle yüklenmiş bir çekirdek veya apt işlemini engelleyecek kadar dolmuş bir /boot gibi uç durumlar, Ubuntu üzerinde eski çekirdekleri temizleme rehberinde ele alınmıştır.

Aylık: günlük büyümesi ve systemd journal

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug bir deneme çalıştırmasıdır ve hiçbir şey yazmaz, bu nedenle canlı bir sunucuda kullanımı güvenlidir. Günlük döndürme kuralları dosya yolları üzerinden eşleştiği için bu komutu çalıştırmak faydalıdır: bir yükseltme sırasında günlük konumunu değiştiren bir uygulama artık kendi kuralı tarafından kapsanmaz ve ilgili dosya, disk dolana kadar sınırsız şekilde büyür.

Journal boyutu systemd tarafından sınırlandırılmıştır, ancak bu sınır sizin belirlediğiniz bir sayıdan ziyade dosya sisteminin bir oranıdır. Belirli bir üst sınır belirlemek istiyorsanız /etc/systemd/journald.conf dosyasında SystemMaxUse= ayarını yapılandırın ve systemd-journald servisini yeniden başlatın. sudo journalctl --vacuum-time=14d alanı hemen geri kazanır; bu bir politika değil tek seferlik bir işlem olduğundan, yapılandırma değişikliğiyle birlikte uygulanmalıdır.

Sürüm başına: erteleyip durduğunuz yeniden başlatma

Diskteki güncellenmiş bir kernel paketi, çalışan bir kernel değildir. Yeniden başlatma gerçekleşene kadar makine eski kerneli çalıştırmaya devam eder; canlı yama (live patching) özelliği mevcut olsa bile, bu yalnızca düzeltmelerin küçük bir kısmını kapsar.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

Bu bayrak dosyası, paket betikleri tarafından oluşturulan bir Debian ve Ubuntu geleneğidir. RHEL ailesi sistemler bu dosyayı oluşturmaz; bu sistemlerde aynı soruya, dnf-utils paketinden gelen needs-restarting -r komutu ile yanıt verilir. Güncel Ubuntu sunucu imajlarında varsayılan olarak yüklü gelen needrestart, kernelin bir alt seviyesindeki durumu yanıtlar: disk üzerinde değiştirilmiş bir kütüphaneyi hala belleğe eşleyen süreçleri listeler. Yama uygulanmış bir OpenSSL'in, onu kullanan servisler yeniden başlatılana kadar etkili olmamasının nedeni budur.

Yeniden başlatmayı ertelemek yerine planlayın. /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; ve Unattended-Upgrade::Automatic-Reboot-Time "03:00"; içerisinde kararı belirlediğiniz bir zamana bırakın. Planlı bir yeniden başlatma, aynı zamanda sunucunun tekrar ayağa kalkıp kalkmayacağını test etmenin tek yoludur; çünkü hatalı bir fstab girdisi veya etkinleştirmeyi unuttuğunuz bir servis, yalnızca önyükleme sırasında kendini belli eder.

Sürüm bazında: dağıtım yükseltmesini planlama

Ubuntu LTS sürümleri beş yıllık standart destek sunarken, ara sürümler dokuz aylık destek sunar; bu nedenle yaptığınız seçim, yıllar boyunca sürecek yükseltme iş yükünüzü belirler. Bu ödünleşim sunucuda LTS ve ara sürümler karşılaştırması başlığında açıklanmıştır.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade bu dosyayı okur ve Prompt=lts bunu LTS'den LTS'ye geçişlerle kısıtlar. LTS'den LTS'ye yükseltme yolu, genellikle sürümün yayınlandığı gün değil, yeni sürümün ilk ara sürümü (point release) yayınlandığında açılır; bu nedenle varsaydığınız bir tarihe göre plan yapmak yerine makinenize neyin teklif edildiğini kontrol edin. Yükseltme işleminin mekaniği Ubuntu 24.04'ten 26.04'e yükseltme başlığında yer almaktadır.

Üç aylık bir marj planlayın. Geri yükleme testini yaptığınız bir snapshot alın, üçüncü taraf apt depolarınızı listeleyin (yükseltme işlemi bunları devre dışı bırakır ve her birinin yeni sürüm için yeni bir hedefe ihtiyacı vardır) ve işleme başlamadan önce geri alma planınızı belirleyin. Ağustos 2026 itibarıyla, Ubuntu 24.04 LTS Nisan 2029'a kadar standart desteğe sahiptir; dolayısıyla bu bir acil durum değil, bir planlama meselesidir.

Nelerin otomatikleştirileceği ve nelerin manuel tutulacağı

Hali hazırda karar verdiğiniz süreçleri otomatikleştirin: güvenlik güncellemeleri, log rotasyonu, sertifika yenileme ve yedekleme işleri. Uyarı mekanizmalarını da otomatikleştirin; çünkü sizin hatırlamanıza bağlı olan bir kontrol, gece saat 02:00'de gerçekleşmeyecek bir kontroldür. Uptime Kuma ile self-hosted durum izleme gibi harici bir izleme aracı, sunucu üzerindeki hiçbir betiğin raporlayamayacağı tek durumu, yani sunucunun erişilemez olması durumunu yakalar.

İki şeyi manuel tutun: geri yükleme testi ve hesap denetimi. Her ikisi de sonucun doğru olup olmadığına karar verecek bir insan gerektirir. Eğer makine durumunu terminal yerine tarayıcıda okumayı tercih ediyorsanız, sunucu yönetimi için Cockpit ve Webmin karşılaştırması yaygın kullanılan iki web konsolunu kıyaslar.

Otomasyonun kendi kendini denetlemesi gerekir; bu nedenle bu listedeki ilk haftalık madde, güncelleyicinin doğrulanmasıdır. Sessizce başarısız olan bir otomasyon, hiç otomasyon olmamasından daha kötüdür; çünkü hem hatayı gizler hem de kontrol etme alışkanlığını ortadan kaldırır.

Tüm kontrol listesi tek bir yerde

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Linux sunucu bakımını ne sıklıkla yapmalıyım?

Kendi kendine değişen her şey için haftalık: güncelleme durumu, disk ve inode kapasitesi, başarısız birimler ve yedekleme işinin tamamlanıp tamamlanmadığı. Yavaş bozulmalar için aylık: geri yükleme testi, sertifika geçerlilik süresi, hesap ve SSH anahtarı denetimi, eski çekirdekler, log büyümesi. Sürüm yükseltme ve mevcut çekirdeğe yeniden başlatma için her dağıtım sürümünde bir kez. Haftalık kontrol, sağlıklı bir sunucuda birkaç dakika sürer; haftalık yapılmasının amacı da bir sorun görünmesini beklemeden süreci işletmektir.

Yedekleme işi başarı raporu veriyorsa neden geri yükleme testi yapmalıyım?

Çünkü iş, kendi çıkış durumunu raporlar ve arşiv kullanılamaz haldeyken bile bu durum başarılı (true) olabilir. set -o pipefail olmadan bir sıkıştırıcıya yönlendirilen döküm, sıkıştırıcının durumunu döndürür; bu nedenle sadece hata mesajı üreten başarısız bir döküm bile sıfır çıkış kodu üretir ve küçük bir dosya yazar. Farklı bir makineye geri yükleme yapın, veriyi açın ve bir şeyleri sayarak doğrulayın. Geri yükleme işlemi ayrıca kendi süresini ölçer; bu süre, gerçek kurtarma sürenizdir.

Her çekirdek güncellemesinden sonra yeniden başlatma yapmalı mıyım?

Yeni çekirdeğin çalışan çekirdek olması için yeniden başlatma yapmanız gerekir. Debian ve Ubuntu üzerinde /var/run/reboot-required dosyasının varlığı, bir paketin yeniden başlatma istediğini belirtir ve /var/run/reboot-required.pkgs hangisinin istediğini gösterir. RHEL ailesinde bu dosya bulunmaz ve dnf-utils paketinden needs-restarting -r komutu aynı soruyu yanıtlar. Yeniden başlatmayı süresiz ertelemek yerine /etc/apt/apt.conf.d/50unattended-upgrades içinde otomatik bir yeniden başlatma penceresi belirleyin; çünkü bir yıldır yeniden başlatılmamış bir makine, eski bir çekirdeğin yanı sıra test edilmemiş bir önyükleme yoluna da sahiptir.

Bu kontrollerin hangilerini güvenle otomatikleştirebilirim?

Kararı zaten verilmiş olan işlemleri otomatikleştirebilirsiniz: güvenlik güncellemeleri, log rotasyonu, sertifika yenileme, zamanlanmış yedeklemeler. Bildirimleri de otomatikleştirin; böylece başarısız bir birim veya dolan bir disk, bir insan komut çalıştırmak zorunda kalmadan size ulaşır. Geri yükleme testini ve anahtar denetimini manuel tutun, çünkü her biri sonucun doğru olup olmadığını değerlendirecek bir insan gerektirir. Ardından otomasyonun kendisi için bir kontrol ekleyin, çünkü sessiz bir güncelleme hatası, her şeyin yolunda olduğu izlenimini verebilir.