Hizmetleri Aksatmadan Linux Sunucusu Nasıl Güvenli Şekilde Temizlenir

Seviye: Orta (üretim sistemleri)
Tahmini süre: ~30 dakika
Amaç: Çalışan hizmetleri durdurmadan, kullanılmayan paketleri, eski çekirdekleri, eski günlükleri ve önbelleğe alınmış dosyaları kaldırarak bir Linux sunucusunda disk alanı boşaltmak.

Bu kılavuz, bir üretim ortamında veya üretim ortamına benzer bir VPS'ye SSH erişimi olduğunu varsayar. Anlık kopyası olmayan kritik sistemlerde bu işlemleri körü körüne uygulamayınız.

Giriş

Zamanla, az kullanılan bir VPS bile gereksiz yük biriktirir: sahipsiz paketler, güncel olmayan çekirdekler, gigabaytlarca döngüye alınmamış günlükler ve kalan paket önbelleği. Kontrol edilmezse, dolu bir disk web sunucunuzun çökmesine, veritabanı yazma işlemlerinin kesintiye uğramasına ve posta kuyruğunuzun dolmasına neden olur. Bu Linux sistem temizleme kılavuzu, bir Linux sunucusunu güvenli bir şekilde nasıl temizleyeceğinizi adım adım anlatır: önce disk kullanımını kontrol eder, kaldırılması güvenli olanları siler ve hizmetlerinizin işlemden sonra sorunsuz çalıştığını doğrular. Buradaki tüm komutlar, kesintiye neden olmadan canlı bir sunucuda güvenle çalıştırılabilir.

Temizleyeceğiniz öğeler

Kategori	Örnekler	Tipik tasarruf
Kullanılmayan paketler ve bağımlılıklar	Yetim kütüphaneler, değiştirilmiş sürücüler	100 MB - 2 GB
Eski çekirdekler	Önceki çekirdek sürümleri	Çekirdek başına 200 MB
Paket önbelleği	İndirilmiş .deb / .rpm dosyaları	500 MB - 5 GB
Günlük kayıtları	systemd günlük arşivleri	100 MB - 10 GB
Dönüşümlü günlük dosyaları	/var/log/*.gz, *.1	Değişken

Ön Koşullar

Başlamadan önce aşağıdaki koşulların sağlandığından emin olun:

• İşletim sistemi: Ubuntu 24.04/26.04 LTS, Debian 13 veya AlmaLinux 10
• Erişim: SSH üzerinden sunucuya sudo veya root erişimi
• Gerekli bilgiler: Linux terminalini ve temel komut satırı navigasyonunu rahatlıkla kullanabilme
• Yedekleme: Üretim sunucusunda paketleri toplu olarak kaldırmadan önce daima bir anlık görüntü veya yedek alın. INTROSERV'de, Müşteri Alanından doğrudan tam bir yedekleme siparişi verebilirsiniz.

Aşağıdakilerden herhangi biri geçerliyse devam etmeyin:

• / bölümü %95'in üzerinde doluysa - sisteminizde yazma işlemleri halihazırda başarısız olabilir. Öncelikle acil nedeni giderin (tek bir büyük dosyayı manuel olarak bulun ve silin).
• Hizmetler zaten kapalı veya beklenmedik şekilde çalışıyor. Linux sistemlerinin bağlı olduğu hizmetlerin bozulmasını önlemek için temizlemeden önce temel nedeni araştırın.
• Yedeklemeniz veya anlık görüntünüz yoksa, önce bir tane oluşturun; INTROSERV'de bu işlem, Müşteri Alanı'ndan 2 dakikadan az sürer.

Adım 1: Başlamadan önce disk kullanımını kontrol edin

Risk seviyesi: DÜŞÜK - Yalnızca salt okunur komutlar. Hiçbir şey değiştirilmez.

Asla körü körüne temizlik yapmayın. Öncelikle, depolama alanını gerçekte neyin kullandığını anlayın.

1.1 Genel disk kullanımını kontrol edin

Dosya sistemi düzeyinde disk kullanımını kontrol etmek için df komutunu çalıştırın:

df -h

Beklenen çıktı:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   34G  3.8G  90% /
tmpfs           1.0G     0  1.0G   0% /dev/shm

Kullanım oranı %80'in üzerinde olan bir / bölümü bir uyarı işaretidir. %95'in üzerinde ise hizmetler çalışmaz hale gelmeye başlar.

1.2 En fazla yer kaplayanları bulun

du komutunu kullanarak dizinleri detaylı olarak inceleyin. Kök dizinden başlayıp aşağı doğru ilerleyin:

sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20

Bu komut, / altındaki en büyük 20 dizini gösterir. Sıkça görülen suçlular /var/log, /var/cache, /usr ve /home dizinleridir.

Arama alanını daha da daraltın:

sudo du -h --max-depth=1 /var/log | sort -rh | head -10

1.3 inode kullanımını kontrol edin

Disk alanı tek sınır değildir. Inode'lar dosya sayısını takip eder. Bir bölümde boş alan olsa da inode'lar tükenebilir ve bu da yazma işlemlerinin başarısız olmasına neden olur.

df -i

Beklenen çıktı:

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 210543 2410897    9% /

IUse% değeri %80'in üzerindeyse, muhtemelen on binlerce küçük dosya içeren bir dizininiz vardır; bu genellikle bir posta kuyruğu, oturum dizini veya PHP önbelleğidir. Bunu bulmak için du --inodes komutunu kullanın:

sudo du --inodes -h --max-depth=2 /var | sort -rh | head -10

Adım 2: Kullanılmayan paketleri ve bağımlılıkları kaldırın

Risk seviyesi: ORTA - Paket kaldırma işlemi, paket yöneticisi geçmişi aracılığıyla geri alınabilir; ancak onaylamadan önce listeyi gözden geçirin.

Kullanılmayan paketleri temizlemek en güvenli yoldur. Bu paketler diskte yer kaplar, çalışan hiçbir işleme hizmet etmez ve bazı durumlarda yamalanmamış CVE'ler içerir.

2.1 Ubuntu / Debian - apt autoremove

apt autoremove, bağımlılık olarak yüklenmiş ancak artık hiçbir şey tarafından ihtiyaç duyulmayan paketleri kaldırır:

sudo apt autoremove --purge -y

--purge bayrağı, kalan yapılandırma dosyalarını da kaldırır. Bu bayrak kullanılmadığında, paket ikili dosyası silinir ancak yapılandırma dosyaları yerinde kalır.

Beklenen çıktı:

The following packages will be REMOVED:
  libfoo1 libbar2 old-driver-utils ...
0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

2.2 AlmaLinux / RHEL - dnf autoremove

sudo dnf autoremove -y

Eski RHEL 7 / CentOS 7 sistemlerinde yum autoremove komutunu kullanın:

sudo yum autoremove -y

2.3 Paket önbelleğini temizleme

Güncellemeler ve kurulumlardan sonra, paket yöneticileri indirilen arşiv dosyalarını yerel olarak depolar. Kurulum tamamlandıktan sonra bu dosyaları silmek güvenlidir.

Ubuntu / Debian:

sudo apt clean

Bu komut , /var/cache/apt/archives/ dizinindeki tüm önbelleğe alınmış .deb dosyalarını kaldırır . Yalnızca depoda artık bulunmayan paketleri (eski sürümleri) kaldırmak için:

sudo apt autoclean

AlmaLinux / RHEL:

sudo dnf clean all

Beklenen çıktı:

16 files removed

3. Adım: Eski çekirdekleri silin

Risk seviyesi: YÜKSEK - Yanlış çekirdeğin kaldırılması, bir sonraki yeniden başlatmanın ardından sunucunun önyüklenememesine neden olur. İşleme devam etmeden önce daima uname -r komutunu kontrol edin.

Her çekirdek güncellemesi, bir güvenlik önlemi olarak önceki sürümü yerinde bırakır. Sunucunuzun yeni çekirdekte kararlı çalıştığını doğruladıktan sonra eski çekirdekleri güvenle kaldırabilirsiniz; her biri genellikle 200-400 MB yer açar.

3.1 Hangi çekirdeğin çalıştığını kontrol edin

Asla şu anda önyükleme yaptığınız çekirdeği silmeyin:

uname -r

Beklenen çıktı:

5.15.0-105-generic

3.2 Yüklü tüm çekirdekleri listeleyin

Ubuntu / Debian:

dpkg -l | grep linux-image | awk '{print $2}'

Beklenen çıktı:

linux-image-5.15.0-100-generic
linux-image-5.15.0-105-generic
linux-image-generic

Meta-paket kaldırılmamalıdır - bu paket, şu anda önerilen çekirdeği takip eder:

• Ubuntu: linux-image-generic
• Debian: linux-image-amd64
• AlmaLinux: Meta paket kullanılmaz; dnf'deki installonly_limit özelliğine dayanır.

Yalnızca mevcut çekirdeğinizle uyumlu olmayan belirli sürümdeki paketleri kaldırın.

AlmaLinux / RHEL:

rpm -q kernel

Beklenen çıktı:

kernel-5.14.0-284.11.1.el9_2.x86_64
kernel-5.14.0-362.8.1.el9_3.x86_64

3.3 Eski çekirdekleri kaldırma

Ubuntu / Debian - otomatik yöntem:

Adım 2'dekiapt autoremove komutu, linux-image-generic yüklüyse Ubuntu'daki eski çekirdekleri zaten kaldırır. Bunları açıkça hedefleyebilirsiniz. Sürümü, kaldırmak istediğiniz sürümle değiştirin (şu anda çalışan sürüm değil):

sudo apt remove --purge linux-image-5.15.0-100-generic -y

AlmaLinux / RHEL:

dnf paket yöneticisi, yapılandırılabilir sayıda eski çekirdeği saklar. Sınırı /etc/dnf/dnf.conf dosyasında ayarlayın:

sudo nano /etc/dnf/dnf.conf

Aşağıdaki satırı ekleyin veya güncelleyin:

installonly_limit=2

Ardından şunu çalıştırın:

sudo dnf remove $(dnf repoquery --installonly --latest-limit=-1 -q)

Bu komut, en son iki çekirdek hariç tüm çekirdekleri kaldırır.

Adım 4: Günlük kayıtlarını temizleyin

Risk seviyesi: DÜŞÜK - Yalnızca arşivlenmiş günlük girişleri siler. Çalışan hizmetler etkilenmez.

systemd-journald, sistemdeki her hizmetten günlükleri toplar. Varsayılan olarak, disk sınırına ulaşana kadar veya disk sınırınız sıfıra düşene kadar sınırsız bir şekilde büyüyebilir.

4.1 Mevcut günlük boyutunu kontrol edin

journalctl --disk-usage

Beklenen çıktı:

Archived and active journals take up 2.3G in the filesystem.

4.2 Günlüğü küçültme

Yalnızca son 7 günlük günlükleri saklamak için:

sudo journalctl --vacuum-time=7d

Yalnızca son 500 MB'yi saklamak için:

sudo journalctl --vacuum-size=500M

Beklenen çıktı:

Deleted archived journal /var/log/journal/.../[email protected] (64.0M).
Vacuuming done, freed 1.8G of archived journals from /var/log/journal/.

4.3 Günlüğün gelecekte büyümesini önleme

Günlüğü kalıcı olarak sınırlamak için bir drop-in yapılandırma dosyası oluşturun (AlmaLinux 10'da, ana yapılandırma dosyası varsayılan olarak /etc/ dizininde bulunmadığından, bu standart yaklaşımdır):

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/99-size.conf <<EOF
[Journal]
SystemMaxUse=500M
MaxRetentionSec=30day
EOF

Değişikliği uygulayın:

sudo systemctl restart systemd-journald

Adım 5: Döndürülmüş ve eski günlük dosyalarını temizleyin

Risk seviyesi: ORTA - Yalnızca sıkıştırılmış arşivler silinir. .gz uzantısı veya sayısal son eki olmayan dosyalara dokunmayın.

/var/log/ dizinindeki uygulama günlükleri logrotate tarafından yönetilir. Normalde logrotate, belirli sayıda döndürülmüş kopyayı saklar ve bunları otomatik olarak sıkıştırır. logrotate yanlış yapılandırılmışsa veya çalışmıyorsa, çok sayıda .gz, .1, .2 dosyası birikmiş olabilir.

5.1 Büyük günlük dosyalarını bulun

find /var/log -type f -name "*.gz" -o -name "*.log" | xargs du -sh 2>/dev/null | sort -rh | head -20

Ya da daha basit bir şekilde:

sudo du -h /var/log | sort -rh | head -20

5.2 Eski sıkıştırılmış günlük arşivlerini silin

Sıkıştırılmış ve döndürülmüş günlükler (.gz) güvenle silinebilir. Bunlar, zaten kapatılmış günlük dosyalarının arşivleridir.

Öncelikle, neyin silineceğini önizleyin - listeyi görmek için -delete seçeneği olmadan komutu çalıştırın:

sudo find /var/log -name "*.gz" -mtime +30

Çıktı doğru görünüyorsa, silme işlemini gerçekleştirin:

sudo find /var/log -name "*.gz" -mtime +30 -delete

Bu komut, 30 günden daha eski .gz günlük arşivlerini siler.

5.3 logrotate'in doğru şekilde yapılandırıldığını doğrulayın

Hangi hizmetlerin logrotate yapılandırmalarına sahip olduğunu kontrol edin:

ls /etc/logrotate.d/

logrotate'in hatasız çalıştığını doğrulamak için logrotate'i hata ayıklama modunda manuel olarak çalıştırın:

sudo logrotate -d /etc/logrotate.conf

-d bayrağı bir deneme çalıştırmasıdır; hiçbir şey değiştirilmez, ancak tam olarak ne olacağını görebilirsiniz. /etc/logrotate.d/ dizininde eksik bir hizmet varsa, bunun için bir yapılandırma oluşturun. Tam logrotate yapılandırma talimatları için Günlük Döndürme kılavuzuna bakın.

Adım 6: Geçici dosyaları temizleyin

Risk seviyesi: ORTA - PHP oturumları ve uygulama önbellekleri, aktif kullanıcıları etkiler. Silmeden önce önizleme yapın.

6.1 /tmp dizinini temizleyin

Çoğu dağıtımda/tmp, yeniden başlatma sırasında temizlenir. Sunucunuz aylardır çalışıyorsa, büyük boyutlu geçici dosyalar birikmiş olabilir:

du -sh /tmp

7 günden eski dosyaları silmek için önce önizleme yapın:

sudo find /tmp -type f -mtime +7

Liste güvenli görünüyorsa, silme işlemini çalıştırın:

sudo find /tmp -type f -mtime +7 -delete

6.2 Uygulama önbelleklerini temizleme

Birçok uygulama kendi önbelleklerini oluşturur. Aşağıdaki yaygın konumları kontrol edin (not: bu dizinlerin sisteminizde mevcut olup olmadığını doğrulayın; temiz bir sistemde bunlar mevcut olmayabilir ve "Böyle bir dosya veya dizin yok" hatası alabilirsiniz):

# PHP session files (often forgotten, if installed)
sudo du -sh /var/lib/php/sessions/

# Pip / Python package caches (if running as root and installed)
sudo du -sh /root/.cache/pip/

# npm cache (if node is installed system-wide)
sudo du -sh /root/.npm/

Uygulama bu dizinleri aktif olarak kullanmıyorsa, bu dizinleri güvenle temizleyebilirsiniz.

7. Adım: Hizmetlerin hâlâ çalışıp çalışmadığını doğrulayın

Risk seviyesi: DÜŞÜK - Salt okunur doğrulama. Bunu sadece sonunda değil, her adımdan sonra çalıştırın.

Her temizleme işleminden sonra, hizmetlerinizin çalışmaya devam ettiğini doğrulayın. Bunu, SSH oturumunuzu kapatmadan önce yapın.

7.1 Kritik hizmetlerin durumunu kontrol edin

Yalnızca sunucunuzda gerçekten kurulu olan hizmetleri kontrol edin (temiz bir sistemde nginx veya mysql kontrol edildiğinde " Birim bulunamadı" hatası verilir).

Ubuntu / Debian:

systemctl status nginx
systemctl status mysql
systemctl status ssh

AlmaLinux / RHEL:

systemctl status nginx
systemctl status mysqld
systemctl status sshd

Her birinin durumu "Active: active (running)" olarak görünmelidir. Herhangi birinin durumu "failed" veya "inactive" olarak görünüyorsa, ilgili hizmetin günlüklerini kontrol edin:

journalctl -u nginx --since "10 minutes ago"

7.2 Disk kullanımında iyileşme olduğunu doğrulayın

df -h

"Use%" sütununu 1. Adımda gördüklerinizle karşılaştırın. Değişiklik, boşalttığınız alanı yansıtmalıdır.

7.3 Uygulamanızı test edin

Bir web sunucusu çalıştırıyorsanız, bir test isteği gönderin:

curl -I http://localhost

Beklenen çıktı:

HTTP/1.1 200 OK
Server: nginx/1.24.0

200 OK kodu, nginx'in trafiği normal şekilde işlediğini gösterir.

Sorun Giderme

Paketleri kaldırdıktan sonra `df` komutunda herhangi bir iyileşme görülmüyor

Paketlerin kaldırılması, alanı anında boşaltır. Eğer ` df ` çıktısında değişiklik olmazsa, dosyalar hala açıktır. Açık ancak silinmiş dosyaları bulun:

sudo lsof | grep deleted

Dosyayı açık tutan hizmeti yeniden başlatın; böylece alan geri kazanılır.

`apt autoremove` komutu, önemli gibi görünen bir şeyi kaldırmak istiyor

Listeyi dikkatlice okuyun. Çalışan bir hizmetin bağımlılığı olarak tanıdığınız bir paket adı görürseniz, N tuşuna basın ve durumu inceleyin. Pakete neyin bağımlı olduğunu görmek için ` apt-cache rdepends <paket> ` komutunu çalıştırın.

`journalctl --vacuum-time` komutu herhangi bir değişiklik yapmıyor

Günlük, hedef boyuttan zaten daha küçük olabilir. `journalctl --disk-usage` komutuyla kontrol edin. Ayrıca günlüğün kalıcı olduğundan emin olun: `/var/log/journal/ ` dizinini kontrol edin. Yalnızca `/run/log/journal/` dizini varsa, günlük RAM'de depolanır ve yeniden başlatma sırasında otomatik olarak silinir.

`apt autoremove` komutundan sonra hizmet çalışmıyor

systemctl status <hizmet> komutunu çalıştırın ve hatayı kontrol edin. Paylaşılan bir kütüphane kaldırılmışsa, onu sağlayan paketi yeniden yükleyin:

sudo apt install --fix-broken

Boş disk alanı olmasına rağmen inode'lar tükeniyor

En fazla dosya bulunan dizini bulun:

find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -10

Sık görülen nedenler: /var/spool/mail dizinindeki posta kuyrukları, /var/lib/php/sessions dizinindeki PHP oturumları veya geçici dosyalar oluşturan kontrolsüz bir cron işi.

Geri alma

Temizlik işlemlerinin çoğu geri alınamaz; silinen dosyalar kalıcı olarak kaybolur. Bu nedenle, Ön Koşullar bölümündeki yedekleme adımı zorunludur.

Özellikle paket kaldırma işlemi için, kaldırılanları yeniden yükleyebilirsiniz:

Ubuntu / Debian:

sudo apt install <package-name>

AlmaLinux / RHEL:

sudo dnf install <package-name>

Mevcut oturumda kaldırılanların geçmişini görmek için:

Ubuntu / Debian:

cat /var/log/dpkg.log | grep "^$(date +%Y-%m-%d)" | grep " remove "

AlmaLinux / RHEL:

sudo dnf history list
sudo dnf history undo last

dnf history undo last, en son işlemde kaldırılan paketleri yeniden yükler; bu, autoremove komutunun istenenden daha fazlasını yapması durumunda kullanışlı bir kurtarma aracıdır.

Sonuç

Kesintiye neden olmadan bir Linux sunucusunu temizlemek üç şeye bağlıdır: önce ölçüm yapın, yalnızca sistemin kullanılmadığını doğruladığı öğeleri kaldırın ve her adımdan sonra hizmetleri doğrulayın. Herhangi bir işlem yapmadan önce df -h ve du komutlarını çalıştırın. Kullanılmayan paketler için apt autoremove / yum autoremove komutlarını, günlük kayıtlarını temizlemek için journalctl --vacuum-time komutunu ve eski, döngüsel olarak silinen arşivler için /var/log -name "*.gz" komutunu kullanın. Eski çekirdekleri, yalnızca uname -r komutunun sakladığınız çekirdekle eşleştiğini doğruladıktan sonra kaldırın. Terminali kapatmadan önce her zaman systemctl status komutunu kontrol edin.

Bir INTROSERV VPS için, / dizinindeki kullanım oranını %80'in altında tutmak pratik bir hedeftir; bu, acil müdahaleye gerek kalmadan günlük dosyalarında ani artışlara ve paket güncellemelerine yer bırakır. Disk alanı tekrarlayan bir sorun haline gelirse, INTROSERV Müşteri Alanı'ndan doğrudan VPS depolama alanınızın boyutunu değiştirmeyi düşünün.

Belge Sürümü: 1.0
Son Güncelleme: Mayıs 2026
Sorumlu: Teknik Dokümantasyon Ekibi