VPS Disk Kullanımı ve logrotate Ayarlarıyla “No Space Left on Device” Hatasını Önlemek

VPS sunucularda en can sıkıcı hatalardan biri, uygulamanız tam da iş başındayken karşınıza çıkan “No space left on device” uyarısıdır. Çoğu zaman bu hata gerçekten “bütün diski doldurdum” anlamına gelmez; yanlış log ayarları, kontrolsüz yedekler, sistem günlükleri veya geçici dosyalar yüzünden disk alanınızın kritik bir bölümü sessizce tüketilir. Sonuçta veritabanınız yazamaz, web sunucunuz log üretemez, hatta bazı durumlarda SSH bile stabil çalışamaz.

DCHost olarak sahada gördüğümüz gerçek vakaların büyük kısmında, sorun doğrudan disk kapasitesinden ziyade log yönetimi ve logrotate yapılandırması ile ilgilidir. Doğru disk planlaması, düzenli izleme ve iyi kurgulanmış logrotate ayarlarıyla bu hatayı neredeyse tamamen hayatınızdan çıkarabilirsiniz. Bu yazıda, VPS disk kullanımını nasıl okuyacağınızı, hangi klasörlerin diski patlattığını, logrotate ile log dosyalarınızı nasıl kontrol altına alacağınızı ve “No space left on device” hatasını kalıcı olarak nasıl önleyeceğinizi adım adım anlatacağım.

VPS Disk Kullanımı Neden Bir Anda Dolar?

VPS diskinin “bir anda” doluyor gibi görünmesinin birkaç tipik sebebi var. Bunları bilmek, teşhis süresini dakikalardan saniyelere indirir:

• Log dosyaları kontrolsüz büyür: Nginx/Apache erişim ve hata logları, PHP hata logları, uygulama logları, veritabanı slow query logları.
• Otomatik yedekler aynı diske atılır: Günlük veya saatlik full yedekler /home ya da /var altında saklanır, logrotate yoksa hızla onlarca GB olur.
• Geçici dizinler temizlenmez: /tmp, /var/tmp, uygulamaların kendi temp klasörleri.
• systemd journal sınırsız büyür: /var/log/journal altında GB’larca binary log birikir.
• Uygulama cache ve upload klasörleri: Özellikle medya ağırlıklı sitelerde eski cache dosyaları ve kullanılmayan upload’lar.
• Docker ve container logları: /var/lib/docker altında container logları ve imajları hızla şişer.

Bu noktada logların nasıl çalıştığını anlamak kritik. Eğer henüz logların neyi ifade ettiğini tam oturtmadıysanız, Apache ve Nginx loglarını okuyarak 4xx–5xx hatalarını teşhis etmeyi anlattığımız rehbere mutlaka göz atın. Logları anlamadan logrotate ayarı yapmak, gözleri kapalı disk yönetimi yapmak gibidir.

“No Space Left on Device” Hatasını Tanımak ve Hızlı Teşhis

Bu hatayı genelde şu çıktılarda görürsünüz:

• Uygulama loglarında veya terminalde: write failed: No space left on device
• MySQL/PostgreSQL loglarında disk yazma hataları
• Nginx/Apache error loglarında log dosyasına yazılamadığına dair kayıtlar

İlk iş olarak şu temel komutlarla durumu netleştirin:

• df -h – Disk kullanımını insan okunabilir formatta gösterir (GB, MB).
• df -i – inode kullanımını gösterir. Bazen alan dolmaz, inode biter ve yine aynı hatayı alırsınız.
• du -sh /* 2>/dev/null – Kök dizin altındaki klasörlerin kabaca ne kadar yer kapladığını görürsünüz.
• du -sh /var/* /home/* 2>/dev/null – Özellikle log ve kullanıcı dosyalarının olduğu yerleri inceleyin.

Eğer df -h çıktısında özellikle / veya /var yüzde 100’e yakınsa, diski asıl dolduran kaynağı bulmak için adım adım derine inmeniz gerekir. İş genellikle /var/log, /var/lib/mysql, /home veya /var/www altında biter.

VPS’te Logların Diski Doldurmasını Önlemek

Linux tabanlı VPS’lerin kalbi /var/log dizinidir. Burada:

• Web sunucusu logları (Nginx, Apache)
• Veritabanı logları (MySQL/MariaDB, PostgreSQL)
• Mail sunucusu logları
• SSH, sistem ve kernel logları
• Uygulama servis logları

bulunur. Bunların çoğu metin dosyasıdır ve günlerce, haftalarca döndürülmeden tutulursa 10 GB ve üzeri boyutlara rahatlıkla ulaşır.

Bir noktadan sonra tek sunucuda logla boğuşmak yerine merkezi çözümlere geçmek isteyebilirsiniz. Bu noktada VPS log yönetimini Grafana Loki + Promtail ile merkezi hale getirmeyi anlattığımız rehberi incelemenizi öneririm. Ancak tek bir VPS’te bile olsanız, ilk yapmanız gereken şey logrotate’i doğru kurmak.

logrotate Nedir, Nasıl Çalışır?

logrotate, Linux sistemlerde log dosyalarını otomatik döndürüp (rotate), sıkıştırıp (compress) belli bir süre sonra silen küçük ama hayati bir araçtır. Genellikle günlük olarak cron veya systemd timer ile çalışır ve şu işleri yapar:

• Belli bir boyuta ya da zamana ulaşmış log dosyalarını “döndürür”.
• Eski log dosyalarını sıkıştırır (gzip ile .gz uzantılı hale getirir).
• Belirli sayıda eski kopyayı saklar (örn. son 7 dosya).
• İsteğe göre döndürme öncesi/sonrası komutlar çalıştırır (örn. servis reload).

Konfigürasyon mantığı iki katmandan oluşur:

• /etc/logrotate.conf – Genel ayarlar ve global varsayılanlar.
• /etc/logrotate.d/ – Servis bazlı, detaylı logrotate dosyaları.

Sisteminizde neler tanımlı görmek için:

ls -lah /etc/logrotate.d/

komutunu çalıştırabilirsiniz.

Temel logrotate Konfigürasyon Örnekleri

Örnekleri basit ve pratik tutalım. Diyelim ki Nginx loglarınız /var/log/nginx/access.log ve /var/log/nginx/error.log altında.

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -s /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid)
    endscript
}

Bu ayar ne yapar?

• daily: Logları günlük döndürür.
• rotate 14: Son 14 dosyayı saklar (yaklaşık 2 haftalık log).
• compress/delaycompress: Eski logları gzip ile sıkıştırır, en güncel döndürülmüş dosyayı bir sonraki turda sıkıştırır.
• notifempty: Boş dosyalar için döndürme yapmaz.
• create: Yeni log dosyasını belirtilen izin ve kullanıcı/grup ile oluşturur.
• postrotate: Nginx’e USR1 sinyali gönderip, yeni log dosyasına yazmaya başlamasını sağlar.

Benzer mantıkla Apache, PHP-FPM veya özel uygulama loglarınızı da yönetebilirsiniz. Örneğin kendi uygulamanız /var/www/app/storage/logs/app.log dosyasına yazıyorsa:

/var/www/app/storage/logs/app.log {
    size 100M
    rotate 10
    compress
    missingok
    notifempty
    copytruncate
}

Burada size 100M ile dosya boyuta göre döndürülür; trafik dalgalıysa ve günlük rota yetersiz kalıyorsa bu daha güvenli bir yaklaşımdır. copytruncate, dosyanın eski halini kopyalayarak yeni dosyayı sıfırlar; uygulama log dosyasını açık tutuyorsa bu yöntem iş görür.

Logların ne kadar süre saklanacağı, sadece disk yönetimi değil aynı zamanda hukuki ve kurumsal gereksinimlerle de ilgilidir. Bu konuda daha geniş çerçeve görmek için hosting ve e‑posta altyapısında log saklama sürelerini anlattığımız rehberi okumanızı öneririm.

systemd journal Boyutunu Sınırlandırmak

Birçok modern dağıtımda syslog yerine systemd-journald kullanılır ve loglar /var/log/journal altında binary formatta tutulur. Varsayılan ayarlar genellikle agresif değildir ama uzun süre dokunulmadığında birkaç GB’ı rahatlıkla aşabilir.

Önce mevcut kullanımınızı görün:

journalctl --disk-usage

Örneğin 8 GB üstü bir kullanım görüyorsanız sınır koymanın zamanı gelmiş demektir. /etc/systemd/journald.conf dosyasını açın:

[Journal]
SystemMaxUse=1G
SystemMaxFileSize=200M
MaxRetentionSec=1month

Sonra:

systemctl restart systemd-journald

komutuyla servisi yeniden başlatın. Acil temizlik gerektiğinde:

journalctl --vacuum-size=500M

ile logların toplam boyutunu 500 MB’a indirebilirsiniz.

VPS Disk Kullanımını Adım Adım Analiz Etmek

Disk dolduğunda panik yapmak yerine sistematik ilerlemek işinizi kolaylaştırır. Sahada en çok kullandığımız adımları paylaşayım:

1. Hangi disk/partition dolu?
   df -h ile kontrol edin. Özellikle /, /var, /home gibi bölümleri inceleyin.
2. Hangi klasör şişmiş?
   du -sh /* 2>/dev/null, ardından problemli klasör için benzer komut: du -sh /var/* 2>/dev/null.
3. Log klasörlerini kontrol edin:
   du -sh /var/log/* 2>/dev/null ile hangi logların GB seviyesine çıktığını bulun.
4. Yedek ve upload dizinlerini inceleyin:
   Örneğin /home/backup, /var/backups, /var/www/site.com/storage/app/backups gibi klasörlere bakın.
5. inode kullanımını kontrol edin:
   df -i ile %100’e yaklaşmış inode olup olmadığını görün. Çok küçük dosya sayısı fazla ise bu ortaya çıkar.

Yeni bir VPS aldıysanız ve henüz temel bakımları yapmadıysanız, “Yeni VPS’te İlk 24 Saat” kontrol listemiz disk ve log tarafında da sağlam bir başlangıç yapmanıza yardımcı olur.

Geçici Dosyalar ve /tmp Temizliği

/tmp ve /var/tmp dizinleri; upload işlemlerinde, sıkıştırma/açma operasyonlarında, bazı uygulamaların geçici dosya yazımlarında yoğun kullanılır. Normalde dağıtımınız bunları periyodik olarak temizler; ancak bazı durumlarda bu temizlik yapılandırılmamış olabilir.

systemd tabanlı sistemlerde /etc/tmpfiles.d altında kurallar tanımlayarak belirli yaşın üstündeki dosyaların otomatik silinmesini sağlayabilirsiniz. Örneğin:

# /etc/tmpfiles.d/custom-tmp.conf
D /tmp 1777 root root 7d

Bu kural, /tmp içindeki 7 günden eski dosyaların temizlenmesini sağlar. Fakat kritik uygulamalarınızın tmp kullanım şekline hakim olmadan agresif süreler vermekten kaçının.

logrotate Stratejisi: Zaman mı Boyut mu?

Logları nasıl döndüreceğinize karar verirken iki temel soru var:

• Zamana göre döndürme (daily, weekly, monthly)
• Boyuta göre döndürme (size 100M, size 1G)

Gerçek dünyada genellikle hibrit bir yaklaşım daha mantıklı:

• Düşük trafikli siteler için weekly + rotate 8 (yaklaşık 2 ay log).
• Orta trafikli siteler için daily + rotate 14 (2 hafta log).
• Yüksek trafikli projeler için size 100M + rotate 30 gibi boyut bazlı döndürme.

E‑ticaret veya yüksek trafik senaryolarında, uygulama ve veritabanı optimizasyonu da log hacmini doğrudan etkiler. Örneğin WooCommerce için MySQL/InnoDB tuning rehberinde anlattığımız şekilde slow query log’unu optimize etmek, hem performans hem disk kullanımı açısından çift taraflı kazanç sağlar.

MySQL/MariaDB ve Diğer Servis Logları

MySQL/MariaDB tarafında özellikle üç log türü diski doldurur:

• Error log
• Slow query log
• General query log (çoğu zaman kapalı olmalı)

Örnek bir logrotate tanımı:

/var/log/mysql/*.log {
    daily
    missingok
    rotate 10
    compress
    notifempty
    create 0640 mysql adm
    sharedscripts
    postrotate
        test -x /usr/bin/mysqladmin || exit 0
        /usr/bin/mysqladmin flush-logs
    endscript
}

Benzer mantığı mail sunucusu, PHP-FPM ve uygulama loglarına da uygulayabilirsiniz. Önemli olan, her büyük log dosyasının /etc/logrotate.d/ altında bir karşılığı olmasıdır.

VPS Disk Kullanımını Proaktif Yönetmek

Diskin dolmasını beklemek yerine, diskin dolma hızını izlemek çok daha sağlıklı bir yaklaşımdır. Bunu iki seviyede ele alabilirsiniz:

• Elle takip: Periyodik olarak df -h, du komutlarını çalıştırmak.
• Otomatik izleme ve alarm: Belirli bir yüzdeye gelince e‑posta, Slack vb. uyarı almak.

İkinci yolu tercih ediyorsanız, Prometheus, Grafana ve Uptime Kuma ile VPS izleme ve alarm kurulumuna giriş rehberimizi mutlaka inceleyin. Disk kullanımı ve inode kullanımı için metrikleri toplayıp, örneğin %80 üzerine çıkınca alarm üretmek işinizi ciddi anlamda rahatlatır.

Otomatik Temizlik, Yedekleme ve Merkezi Loglama

Sağlıklı bir VPS disk stratejisi üç bacaklı olmalı:

• Log döndürme ve sıkıştırma: logrotate + systemd journal limitleri.
• Yedeklerin doğru yerde tutulması: Mümkünse aynı diskte devasa yedekler biriktirmemek; harici depolama veya Object Storage kullanmak.
• Merkezi loglama: Uygun olduğunda logları VPS dışına akıtmak.

Özellikle birden fazla VPS veya dedicated sunucu yönetiyorsanız, logları tek tek disklerde tutmak hem yönetim hem disk planlaması açısından yorucu olur. Bu durumda ELK veya Loki stack ile merkezi loglama rehberimiz size daha ölçeklenebilir bir yol sunar.

Yedek tarafında ise, uygulama dosyaları ve veritabanı dump’larını aynı VPS diskinde yıllarca saklamak yerine, S3 uyumlu depolama gibi harici çözümlere taşımak uzun vadede hem maliyeti hem riski azaltır. Bu konuda Object Storage vs Block Storage vs File Storage karşılaştırma yazımız strateji belirlerken işinize yarayacaktır.

DCHost Üzerinde VPS Kullanıyorsanız Nelere Dikkat Etmelisiniz?

DCHost altyapısında VPS kullanırken disk tarafında pratik önerilerimiz şöyle:

• Başlangıçta gerçekçi disk boyutu seçin: WordPress + WooCommerce gibi projeler için sadece dosya boyutuna değil, log ve yedek büyümesini de hesaba katın.
• NVMe disk avantajını kullanın: Yüksek IOPS sayesinde log döndürme, sıkıştırma ve büyük dosya operasyonları çok daha hızlı tamamlanır.
• Disk kullanımı için alarm kurun: İzleme panelinizde disk ve inode için eşik değerleri belirleyin (örn. %80 uyarı, %90 kritik).
• Destek ekibiyle iletişimde olun: Disk sürekli %80 üzerindeyse, daha büyük diske geçiş veya ek disk ekleme planını birlikte değerlendirebiliriz.
• Snapshot ve yedek stratejisini ayırın: Anlık snapshot’ları kurtarma senaryoları, harici yedekleri ise uzun vadeli saklama için kullanın.

Gerçek Dünya Senaryoları: Disk Dolma Vakalarından Çıkan Dersler

Senaryo 1: WordPress debug.log Dosyasının Diski Gömmesi

Geliştirme aşamasında açılan WP_DEBUG_LOG, canlıya geçişte kapatılmadığı için /wp-content/debug.log dosyası haftalar içinde 20–30 GB’a ulaştı. Disk %100’e vurdu, site zaman zaman 500 hataları vermeye başladı.

Çözüm:

• debug.log geçici olarak sıkıştırılıp taşındı.
• wp-config.php üzerinden WP_DEBUG_LOG kapatıldı.
• İlgili dizin için boyut bazlı logrotate kuralı eklendi.

Ek olarak, WordPress tarafındaki genel bakım ve optimizasyonlar için WordPress yedekleme stratejileri ve sunucu tarafı optimizasyon rehberimiz de uygulamaya alındı.

Senaryo 2: MySQL Slow Query Log’unun Kontrolden Çıkması

Yoğun sorgu alan bir e‑ticaret sitesinde MySQL slow query log açık bırakılmış, ancak ne döndürme ne de sıkıştırma yapılmamıştı. Birkaç hafta içinde sadece slow query log 15 GB’ı geçti.

Çözüm:

• Önce logrotate ile günlük döndürme + sıkıştırma ayarlandı.
• Ardından sorgu optimizasyonu ve indeksleme çalışmaları yapıldı.
• Slow query threshold değeri ve log detay seviyesi mantıklı bir seviyeye çekildi.

Burada disk yönetimi ile performans optimizasyonunun el ele yürüdüğünü görmek önemli. Sorgu tarafına derinlemesine bakmak isterseniz, az önce link verdiğimiz WooCommerce/MySQL tuning rehberi iyi bir başlangıç.

Senaryo 3: systemd journal ve /var/log/journal Şişmesi

Uygulama logları gayet kontrol altında olmasına rağmen, /var dizini beklenmedik şekilde doluyordu. İnceleme sonucunda /var/log/journal altında 8+ GB boyutunda systemd journal dosyaları biriktiği görüldü.

Çözüm:

• journalctl –vacuum-size ile acil olarak boyut 1 GB’a çekildi.
• journald.conf içinde kalıcı limitler tanımlandı (SystemMaxUse=1G vb.).
• Önemli logların metin tabanlı syslog’a da yazılması sağlandı.

Özet ve Yol Haritası

VPS’te “No space left on device” hatası, çoğu zaman şanssızlık değil öngörülmemiş disk ve log stratejisinin doğrudan sonucu. Doğru adımları attığınızda bu hatayı görme ihtimaliniz ciddi oranda düşer:

• Disk ve inode kullanımını düzenli izleyin, %80 üzeri değerleri ciddiye alın.
• /var/log, /var/lib, /home ve uygulama klasörlerini periyodik olarak boyut analizi yapın.
• Tüm büyük log dosyaları için logrotate kuralı tanımlayın; zaman ve boyut bazlı hibrit politikalar kullanın.
• systemd journal için makul boyut limitleri belirleyin.
• Yedekleri ve uzun süre saklanacak logları mümkünse VPS diski dışına alın.
• İzleme ve alarm sistemi kurarak, diskin dolmasını beklemeden aksiyon alın.

DCHost olarak, VPS ve dedicated sunucularınızda disk yönetimi, logrotate kurgusu, merkezi loglama ve yedek stratejisi gibi konularda ekibimizle birlikte yanınızdayız. Mevcut VPS’inizde diskin neden dolduğunu tam anlayamıyorsanız veya yeni projeye başlarken en baştan temiz bir mimari kurmak istiyorsanız, altyapınızı birlikte gözden geçirip size en uygun çözümü netleştirebiliriz. İyi planlanmış bir disk ve log stratejisi, uzun vadede kesintisiz ve sorunsuz bir barındırma deneyiminin en güçlü garantisidir.