VPS Disk Doluluğu: logrotate ve Journal Ayarları

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. Bu uyarı, tüm fiziksel diskin dolduğu anlamına gelmek zorunda değildir; yazılan dosya sistemindeki boş alanın veya inode’ların tükenmesi de buna yol açabilir. Yanlış log ayarları, kontrolsüz yedekler, sistem günlükleri veya geçici dosyalar disk alanını tüketebilir. Sonuçta veritabanınız yazamaz, web sunucunuz log üretemez, hatta bazı durumlarda SSH bile stabil çalışamaz.

Disk kapasitesi kadar log yönetimi ve logrotate yapılandırması da önemlidir. Doğru disk planlaması, düzenli izleme ve uygun logrotate ayarlarıyla disk dolma riskini azaltabilirsiniz. Bu yazıda, VPS disk kullanımını nasıl okuyacağınızı, hangi dizinlerin alan tükettiğini, logrotate ile log dosyalarınızı nasıl kontrol altına alacağınızı ve “No space left on device” hatasının tekrarlama riskini nasıl azaltacağınızı 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, sorunun kaynağını daha hızlı bulmanıza yardımcı olabilir:

• 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; saklama ve eski yedekleri silme politikası yoksa hızla onlarca GB olabilir.
• Geçici dizinler temizlenmez: /tmp, /var/tmp, uygulamaların kendi temp klasörleri.
• systemd journal disk alanı tüketir: Saklama moduna göre /var/log/journal veya /run/log/journal altında ikili günlükler birikir; etkin limitleri ayrıca kontrol edin.
• Uygulama cache ve upload klasörleri: Özellikle medya ağırlıklı sitelerde eski cache dosyaları ve kullanılmayan upload’lar.
• Docker ve container logları: Container logları, imajlar ve volume verisi ayrı alan tüketicileridir; Docker’ın etkin depolama yolunu ve log sürücüsünü kontrol edin.

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

Önce hatayı veren işlemin yazdığı dosya sistemini bulun. Aşağıdaki GNU/Linux komutları teşhis içindir; büyük dizinleri taramak I/O yükü oluşturabilir. Yetki hatalarını gizlemeyin:

• df -h – Bağlı dosya sistemlerinde kullanılan ve kullanılabilir alanı gösterir; tek fiziksel diskle aynı şey değildir.
• df -i – Dosya sisteminin bildirdiği inode kullanımını gösterir. Boş GB varken inode tükenebilir.
• sudo du -xh --max-depth=1 / – Kök dosya sistemi içindeki dizinleri bir seviye ayrıntıyla inceler; -x başka dosya sistemlerine geçmez.
• sudo du -xh --max-depth=1 /var – Sorunlu yol /var ise daha derine iner. /home veya /var ayrı bağlanmışsa taramayı ilgili bağlama noktasından başlatın.

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.

df dosya sistemini, du erişebildiği dosyaları ölçer; aynı toplamı vermeleri gerekmez. Silinmiş fakat bir süreç tarafından açık tutulan dosyalar du taramasında görünmeyebilir, ancak alanları df kullanımına dâhil kalır. sudo lsof +L1 ile bu dosyaları ve sahibi olan süreci inceleyin. Gerekli kayıtları koruduktan sonra servisin belgelenmiş log yeniden açma yöntemini kullanın; yalnız gerekirse ilgili servisi kontrollü yeniden başlatın. Boş alan/inode yeterli görünüyorsa uygulamanın gerçek yazma yolu, ayrı tmpfs, kota ve depolama katmanı sınırlarını da inceleyin.

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ı

bulunabilir; kullanılan yollar servis yapılandırmasına bağlıdır. Metin logları, kayıt hacmi yüksekse ve günlerce, haftalarca döndürülmeden tutulursa 10 GB ve üzeri boyutlara ulaşabilir.

Bir noktadan sonra tek sunucuda logla boğuşmak yerine merkezi çözümlere geçmek isteyebilirsiniz. Bu noktada Loki ile merkezi VPS log yönetimi rehberini incelemenizi öneririm. Tek bir VPS’te de metin loglarının nasıl döndürüldüğünü kontrol etmek ve gerektiğinde logrotate ayarlarını düzenlemek önemlidir.

Promtail 2 Mart 2026’da kullanım ömrünün sonuna ulaştı; yeni kurulumlarda Grafana Alloy veya desteklenen başka bir istemci seçin. Merkezi aktarım, yerel kopyaları veya aktarım kesildiğinde büyüyen kuyrukları kendiliğinden temizlemez.

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

logrotate, Linux sistemlerde log dosyalarını otomatik döndürüp (rotate), sıkıştırıp (compress) saklama politikasına göre eski kopyaları 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:

logrotate sürekli çalışan bir boyut izleyicisi değildir: koşulları ancak cron veya timer onu çağırdığında değerlendirir. Çalıştırma sıklığını, durum dosyasını ve hata kayıtlarını kontrol edin. Bu rehberdeki direktifler upstream logrotate 3.22.0 belgesiyle karşılaştırılmıştır; yerel logrotate --version ve man logrotate ile dağıtımınızı doğrulayın.

• 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.

Bir kural eklemeden önce ana dosyanın bu dizini gerçekten içerdiğini ve aynı log için ikinci bir kural bulunmadığını kontrol edin. Saklama gereksinimi, olay incelemesi ve geri dönüş için gerekli kopyaları belirleyin; rotasyon eski dosyaları silebilir. Kopyalama ve sıkıştırma için ayrıca boş çalışma alanı gerekir.

sudo logrotate -d /etc/logrotate.conf kararları gösterir; logları veya durum dosyasını değiştirmez. Bu kontrol servisin yeni dosyayı açabildiğini kanıtlamaz. -f gerçek rotasyon, hook ve silme işlemlerini tetikleyebilir; ancak kapsamı, saklama ve boş alanı değerlendirilmiş bir servis kuralında kontrollü kullanın. Tek dosyayla çağırma, yüklenmeyen ana yapılandırmanın varsayılanlarını devralmaz.

Temel logrotate Konfigürasyon Örnekleri

Diyelim ki Nginx loglarınız /var/log/nginx/access.log ve /var/log/nginx/error.log altında. Aşağıdaki örnek ayrıca www-data kullanıcısı, adm grubu ve /run/nginx.pid yolunun kurulumunuza uygun olduğunu varsayar; bu değerleri kendi sisteminizle karşılaştırın.

Dağıtımın Nginx kuralı varsa onu inceleyin; üzerine ikinci kural eklemeyin. Örnek çalışan Nginx master sürecinin güvenilir PID dosyasını ve yazılabilir yeni log yolunu varsayar. Bu yolları, kullanıcıları ve PID’yi doğrulamadan sinyal göndermeyin. maxsize ile erken rotasyon ancak logrotate gün içinde yeniden çalıştırılıyorsa gerçekleşir.

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

Bu ayar ne yapar?

• daily + maxsize 50M: Günlük rotasyon koşulunu korur; dosya 50M’ı aşarsa daha erken bir çalıştırmada döndürülebilir. Bu, dosyanın 50M’ı hiçbir zaman aşmayacağı anlamına gelmez.
• rotate 14: En fazla 14 döndürülmüş kopya saklar; gün içinde birden fazla rotasyon varsa 14 gün garanti etmez.
• compress/delaycompress: gzip sıkıştırmasını bir sonraki rotasyon turuna erteler. Dosya hâlâ yazılıyorsa yalnız geciktirmeye güvenmeyin; yeniden açmanın başarılı olduğunu doğrulayın.
• missingok/notifempty: Olmayan ve boş loglar için ilgili davranışı belirler; yolun yanlış olması da bu nedenle gözden kaçabilir.
• create: Yeni aktif dosyayı belirtilen izin ve sahiplikle oluşturur; eski kayıtları tek başına taşımaz veya silmez.
• sharedscripts/postrotate: Birlikte ele alınan loglar için betiği bir kez çalıştırır. Nginx master’a USR1 gönderilince loglar yeniden açılır; hata çıktısını ve yeni dosyaya yazmayı kontrol edin.

Apache, PHP-FPM ve özel uygulamalarda yeniden açma yöntemi farklı olabilir. Uygulama logları için önce uygulamanın kendi rotasyon desteğini inceleyin. Aşağıdaki /var/www/app/storage/logs/app.log örneği yalnız yeniden açma desteği bulunmayan, kayıt kaybı riski kabul edilmiş metin logu içindir. copytruncate kopyalama ile sıfırlama arasındaki kayıtları kaybettirebilir; bu riski kabul edemiyorsanız bu yöntemi kullanmayın. app burada örnek servis kullanıcısı/grubudur; gerçek sahiplik ve dizin izinleriyle değiştirin.

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

Burada size 100M ile dosya boyuta göre döndürülür. Eşik yalnız logrotate çağrıldığında kontrol edilir; arada dosya büyümeye devam eder. size zaman koşullarıyla aynı anda uygulanmaz: son belirtilen koşul önceliklidir. copytruncate önce kopya oluşturur, sonra orijinal açık dosyayı yerinde sıfırlar; yeni dosyayı sıfırlamaz. Bu yöntemle create etkisizdir. Kopyalama için alan ayırın; kayıpsızlık veya eksiksiz denetim izi garantisi yoktur.

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

systemd-journald ile rsyslog gibi syslog servisleri aynı sistemde birlikte çalışabilir ve aynı olayın birden fazla kopyasını tutabilir. Storage=persistent genellikle /var/log/journal kullanır, erken açılışta veya disk yazılamadığında /run/log/journal’a dönebilir. volatile /run/log/journal kullanır; auto ise /var/log/journal dizininin varlığına göre seçer. none journal saklamasını kapatır fakat yönlendirmeyi mutlaka kapatmaz. Varsayılan modu dağıtım ve derleme belirleyebilir; etkin yapılandırmayı okuyun.

Journal varsayılan olarak sınırsız değildir. Upstream belgede MaxUse varsayılanı ilgili dosya sisteminin %10’u, KeepFree varsayılanı %15’idir; hesaplanan her varsayılan 4G ile sınırlanır. İki koşuldan daha sıkı olanı uygulanır. Bunlar tüm VPS’ler için uygun bir saklama planı veya diğer uygulamalara kesin boş alan garantisi değildir.

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

journalctl --disk-usage

Kullanımı disk kapasiteniz ve log saklama ihtiyacınızla karşılaştırarak bir bütçe belirleyin; 8 GB gibi tek bir eşik her VPS için uygun değildir. Aşağıdaki değerler örnektir. /etc/systemd/journald.conf dosyasını açın:

Mevcut ana dosyayı koruyun; yerel ayarlar için /etc/systemd/journald.conf.d/60-disk-budget.conf gibi bir drop-in kullanabilirsiniz. Aşağıdaki System ayarları kalıcı depolama içindir; /run altındaki geçici depolama için karşılık gelen RuntimeMaxUse, RuntimeKeepFree ve RuntimeMaxFileSize ayarlarını seçin. Örnekler varsayılan journal namespace içindir.

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

SystemMaxFileSize dosya rotasyonunun ayrıntı düzeyini etkiler; MaxRetentionSec=1month en az bir aylık kayıt garantisi değildir. Boyut sınırı eski kayıtları daha erken kaldırabilir ve yalnız arşivlenmiş dosyalar temizlenir. Gereken kayıtları dışarıda doğrulanmış biçimde koruyun. Yetkili yönetici, ilgili yapılandırmayı kontrol ettikten sonra şu servis yeniden başlatmasını uygulayabilir:

sudo systemctl restart systemd-journald

Ardından servis hatalarını ve yeni kayıt akışını kontrol edin. Journald için ayrı stop/start işlemleri yerine restart kullanın; standart çıktı akışlarının korunması bu işlemde önemlidir. Acil temizlikte aşağıdaki komut en eski arşivlenmiş journal dosyalarını geri döndürülemez biçimde siler. Önce saklama, inceleme ve yedek gereksinimlerini değerlendirin; gerekli kopyaları dolu dosya sistemi dışında doğrulayın:

sudo journalctl --vacuum-size=500M

--vacuum-size=500M arşivlenmiş dosyaların kullanımını sınırlar; aktif dosyalar silinmediği için journalctl --disk-usage toplamı 500M’dan büyük kalabilir. --vacuum-time=30d ise 30 günden eski arşivleri siler; 30 günlük geçmişi garanti etmez. İki sınır birlikte kullanılırsa ikisi de uygulanır. --rotate aktif dosyaları önce arşive dönüştürerek daha çok kaydı silinebilir hâle getirir; sırf daha çok alan kazanmak için incelemeden eklemeyin. Vacuum seçenekleri systemd 218+, rotate 227+ belgesinde yer alır; yerel sürümü doğrulayın.

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. Şu sırayla inceleyebilirsiniz:

1. Yazma yolu ve dosya sistemi: df -h ve df -i ile alan/inode durumunu kontrol edin; /, /var ve /home ayrı olabilir.
2. Büyük dizin: İlgili bağlama noktasında sudo du -xh --max-depth=1 /var gibi bir taramayla başlayın; /var örnek yoldur.
3. Log alt dizinleri: sudo du -xh --max-depth=1 /var/log ile büyümenin kaynağını daraltın. Büyük görünen dosyanın metin logu, journal veya veritabanı verisi olduğunu ayırın.
4. Yedek ve upload: /home/backup, /var/backups ve uygulama depolamasını inceleyin; yaşlı dosya otomatik olarak silinebilir değildir.
5. İnode ve görünmeyen alan: GNU du --inodes -x --max-depth=1 /var çok sayıda dosya barındıran dizinleri, sudo lsof +L1 silinmiş açık dosyaları bulmaya yardımcı olur. Büyük taramaları yükü gözeterek daraltın.

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.

Otomatik temizlik de veri siler. Önce dağıtımın mevcut tmpfiles kurallarını, zamanlayıcısını ve uygulamanın geçici dosyaları ne zaman bırakacağını inceleyin. Tüm /tmp için ikinci bir çakışan kural eklemek yerine yalnız uygulamaya ayrılmış, içeriğinin yedi günden sonra atılabileceği doğrulanmış bir dizin örneği kullanın; app örnek kullanıcı/gruptur:

# /etc/tmpfiles.d/app-tmp.conf
d /var/tmp/app 0700 app app 7d -

d dizini oluşturma/izin ve yaşa göre temizlik davranışını tanımlar; D ayrıca –remove işleminde içeriği kaldırabildiğinden burada kullanılmaz. Yaş, dosyanın yalnız oluşturulma tarihi değildir; tmpfiles ilgili zaman damgalarını değerlendirir. Temizlik ancak ilgili görev çalıştığında yapılır. Açık bir dosyanın her koşulda korunacağını varsaymayın; uygulama sahipliği, yaşam döngüsü ve geçerli istisnaları doğrulayı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)

Hibrit koşul için daily + maxsize 100M gibi bir seçim yapılabilir. minsize hem zamanın dolmasını hem boyut koşulunu ister; size ise zaman koşulunun yerine geçebilir. Upstream belgedeki bu ayrımı yerel sürümünüzde doğrulayın:

• weekly + rotate 8: Sekiz rotasyon kopyası tutar; boş loglar, atlanan çalıştırmalar ve ek koşullar nedeniyle tam iki ay garantisi değildir.
• daily + rotate 14: Günlük koşullu 14 kopya; sıklığı gerçek timer/cron belirler.
• daily + maxsize 100M + rotate 30: Sık çağrıldığında gün içinde erken rotasyon yapabilir. Otuz kopya otuz gün anlamına gelmez.
• Yalnız size 100M: Zaman yerine boyut koşulu isteniyorsa kullanın; çalışma aralığında büyümeyi durdurmaz.

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 sorguları incelemek faydalıdır. Eşiği yükseltmek kayıt hacmini azaltabilir ama sorguyu hızlandırmaz; performans iyileşmesini ölçün ve gerekli teşhis verisini kaybetmeyin.

MySQL/MariaDB ve Diğer Servis Logları

MySQL/MariaDB’de tanılama logları ile kurtarma ve replikasyon verilerini ayrı değerlendirin:

• Error log
• Slow query log
• General query log; hacim ve hassas veri içerebildiği için yalnız gerekçeli ihtiyaca göre açın.
• Binary log, redo/undo ve PostgreSQL WAL gibi veriler farklı yönetilir; bunları metin logu sanıp logrotate, truncate veya dosya silmeyle temizlemeyin.

Aşağıdaki örnek yalnız dosyaya yazılan MySQL 8.4 error/slow logları içindir; gerçek yolları ve paket kuralını kontrol edin. /etc/mysql/logrotate-client.cnf önceden hazırlanmış, yalnız yetkili yöneticinin okuyabildiği örnek istemci dosyasıdır; bağlantı ve gerekli log flush yetkisi doğrulanmalıdır. Parolayı komut satırına koymayın. MariaDB’de kendi sürümünün mariadb-admin ve paket yönergesini kullanın; ikisini koşulsuz aynı kabul etmeyin.

/var/log/mysql/error.log /var/log/mysql/mysql-slow.log {
    daily
    maxsize 50M
    missingok
    rotate 10
    compress
    delaycompress
    notifempty
    create 0640 mysql adm
    sharedscripts
    postrotate
        /usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate-client.cnf flush-logs error slow
    endscript
}

MySQL’de log dosyalarını yeniden açmak için flush işleminin başarılı olması ve yeni yolun uygun sahiplikle yazılabilir olması gerekir. Hataları gizlemeyin; yeni loga kayıt düştüğünü kontrol edin. Genel flush-logs binary logları da etkileyebilir; örnekte error/slow seçimi bunun kapsamını daraltır. MySQL 8.4 binary-log saklama için binlog_expire_logs_seconds ve sunucunun purge işlemleri kullanılır; replikaların ihtiyacı ve noktaya geri dönüş planı doğrulanmadan süreyi kısaltmayın. MariaDB ayarları sürüme göre ayrıca değerlendirilir.

Her log için tek bir doğru yönetici seçin: dosyaya yazılan servis loglarında logrotate veya servisin kendi rotasyonu, journal’da journald, Docker loglarında etkin sürücünün rotasyonu. Docker json-file dosyalarını dışarıdan döndürmeyin; yeni varsayılanlar mevcut container’lara kendiliğinden uygulanmaz.

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 ve inode metrikleri için node_exporter gibi uygun bir sistem veri kaynağı kullanın. Uptime Kuma erişilebilirlik kontrolleri, kendi başına dosya sistemi metriklerinin yerine geçmez. %80 uyarı/%90 kritik yalnız örnek eşiklerdir; kalan GB, büyüme hızı ve müdahale süresiyle birlikte değerlendirin.

Log büyümesi kontrol altındayken ölçümler gerçek kapasite ihtiyacını gösteriyorsa “Bulut Sunucuda Disk Büyütme ve Dosya Sistemi Ayarı” rehberi, bölüm ve dosya sistemi katmanlarını doğrulayarak alan genişletme adımlarını açıklar.

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 aynı hata alanına bağımlılığı azaltabilir; toplam maliyet aktarım, saklama ve geri getirme ücretlerine bağlıdır. Silmeden önce kopyanın bütünlüğünü ve geri yüklemeyi doğrulayın; snapshot tek başına bağımsız yedek değildir. 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:

• Kapasiteyi ölçün: Uygulama verisi yanında log, yedek, rotasyon ve sıkıştırma çalışma alanını hesaba katın.
• Depolama performansını doğrulayın: NVMe etiketi her iş yükünde daha hızlı sıkıştırma garantisi vermez; CPU, I/O sınırı ve iş yükünü birlikte ölçün.
• Alarm kurun: Disk ve inode eşiğini boş alanın tükenme süresiyle birlikte belirleyin; alarmın gerçekten ulaştığını sınayın.
• Genişletmeyi teyit edin: Ek disk veya disk büyütme desteği, kota, maliyet ve işletim sistemi adımlarını kullandığınız ürün için doğrulayın.
• Kurtarmayı planlayın: Snapshot’ın tutarlılığını ve hangi hata alanında kaldığını bilin; dış yedek, saklama ve geri yükleme testlerini ayrıca planlayın.

Örnek Senaryolar: Disk Dolma Nedenleri ve Müdahale

Senaryo 1: WordPress debug.log Dosyasının Büyümesi

Örnek bir WordPress kurulumunda WP_DEBUG ve WP_DEBUG_LOG açıkken tekrarlayan hatalar debug.log dosyasını büyütebilir. Varsayılan konum sitenin wp-content dizinidir; özel bir yol da seçilebilir. Bu varsayımsal senaryoda alan tükenmesi yazma ve istek hatalarına yol açabilir. Birikim hızı, kaydedilen olay sayısına ve kayıtların boyutuna bağlıdır.

Çözüm:

• Hatanın kaynağını inceleyin; gerekli kayıtları başka depolamaya doğrulanmış şekilde alın. Dolu diskte sıkıştırmanın ek alan isteyebileceğini hesaba katın.
• Geçici debug ihtiyacı bittiyse ilgili ayarları kapatın; kullanıcıya hata gösterimini ayrı değerlendirin ve log dosyasının webden erişilemediğini doğrulayın.
• Log tutmaya devam ediliyorsa uygulamayla uyumlu rotasyon ve saklama seçin; dosyayı açık tutma davranışını sınayın.

Ek olarak, WordPress tarafındaki genel bakım ve optimizasyonlar için WordPress yedekleme stratejileri ve sunucu tarafı optimizasyon rehberimiz konuyu tamamlayabilir.

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

Varsayımsal bir e-ticaret sitesinde slow query log dosyaya yazılıyor fakat rotasyon çalışmıyorsa birikim disk bütçesini tüketebilir. Bu durumda önce logun büyüme hızını ve hangi sorguların kaydedildiğini ölçün; saklama bütçesini ölçülen büyümeye göre belirleyin.

Çözüm:

• Gerekli teşhis kayıtlarını koruyup dosya yolu, yetki, rotasyon ve yeniden açmayı doğrulayın.
• Yavaş sorguları ve indeksleri gerçek ölçümlerle inceleyin.
• Slow query eşiğini teşhis ihtiyacına göre belirleyin; yalnız eşiği yükseltmek sorguyu hızlandırmaz ve belirtileri gizleyebilir.

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

Örnek bir sunucuda uygulama metin logları kontrollüyken journal beklenenden fazla alan kullanabilir. Önce journalctl --disk-usage, etkin Storage modu, varsa ayrı namespace ve System/Runtime sınırlarını inceleyin; tekrarlayan olayın kaynağını bulun.

Çözüm:

• Saklanması gereken kayıtları doğrulanmış dış kopyaya alın; yalnız silinebilecek arşivleri journalctl vacuum seçenekleriyle temizleyin.
• Etkin depolama moduna uygun limitleri belirleyin ve kayıt akışını tekrar kontrol edin; aktif dosyalar yüzünden kullanım hedefin üstünde kalabilir.
• Syslog’a ayrıca yazmak ikinci yerel kopya oluşturabilir. Merkezi saklama gerekiyorsa aktarım başarısını, yerel kuyrukları ve saklama politikasını birlikte izleyin.

Özet ve Yol Haritası

VPS’te “No space left on device” hatasının nedenini dosya sistemi, inode, açık dosya ve log kaynağı düzeyinde ayırmak gerekir. Kapasite planlaması ve çalışan rotasyon riskleri azaltır; her durumda önleme garantisi vermez:

• Disk ve inode kullanımını, kalan alanı ve büyüme hızını izleyin.
• /var/log, /var/lib, /home ve uygulama dizinlerini doğru dosya sistemi sınırında inceleyin; silinmiş açık dosyaları unutmayın.
• Metin logları için tek bir rotasyon yöneticisi seçin; koşul ile zamanlayıcı sıklığını ayrı kontrol edin.
• Journal’da System/Runtime bütçeleri ve arşivlenmiş dosyaların temizliği arasındaki farkı koruyun.
• Yedek ve logları silmeden önce gerekli geçmişi ve geri yüklenebilir dış kopyaları doğrulayın.
• Değişiklik sonrasında hata çıktısını, aktif loga yazmayı, boş alanı ve alarm teslimini kontrol edin.

DCHost üzerinde VPS veya dedicated sunucu seçerken disk büyütme, yedekleme ve yönetim hizmetinin kapsamını kullandığınız paket için doğrulayın. Kendi sorumluluğunuzdaki işletim sistemi, uygulama logları ve saklama kurallarını belgeleyin. Düzenli ölçüm, kontrollü değişiklik ve geri yükleme testleri disk doluluğuna karşı uygulanabilir bir bakım planı oluşturur.

Birincil teknik belgeler: logrotate 3.22.0, journald.conf, journalctl, Nginx, MySQL 8.4.