Logrotate Nedir? Linux Sunucularda Log Rotasyonu ve Disk Koruma Rehberi

Son Güncelleme: Haziran 2026

Logrotate, Linux sunucularda log dosyalarının belirli aralıklarla döndürülmesini, sıkıştırılmasını, arşivlenmesini ve gerektiğinde silinmesini sağlayan kritik bir sistem aracıdır. Özellikle hosting, VPS, VDS, web sunucusu, veritabanı ve uygulama altyapılarında kontrolsüz büyüyen log dosyaları disk doluluğuna, servis kesintisine ve performans sorunlarına yol açabilir. Bu rehberde Logrotate mantığını, temel yapılandırma dosyalarını, örnek senaryoları, güvenlik ipuçlarını ve en iyi uygulamaları detaylı şekilde ele alacağız.

İçindekiler

• Logrotate Nedir?
• Log Rotasyonu Neden Önemlidir?
• Logrotate Nasıl Çalışır?
• Temel Yapılandırma Dosyaları
• En Çok Kullanılan Logrotate Parametreleri
• Örnek Logrotate Yapılandırmaları
• Test ve Hata Ayıklama
• Güvenlik ve Performans İpuçları
• Pratik Kullanım Senaryoları
• Sıkça Sorulan Sorular
• Sonuç

Logrotate Nedir?

Logrotate, Linux işletim sistemlerinde log dosyalarının büyümesini kontrol altında tutmak için kullanılan bir log rotasyonu aracıdır. Log rotasyonu; mevcut log dosyasının belirli bir kurala göre yeniden adlandırılması, yeni bir boş log dosyasının oluşturulması, eski logların sıkıştırılması ve belirli sayıdan veya süreden eski kayıtların silinmesi işlemidir.

Bir web sunucusunda /var/log/nginx/access.log, /var/log/apache2/error.log, /var/log/mysql/error.log veya uygulama bazlı /var/www/site/storage/logs/laravel.log gibi dosyalar zaman içinde büyür. Trafiği yüksek bir sitede access log dosyası birkaç saat içinde gigabayt seviyesine ulaşabilir. Bu durum özellikle küçük diskli Linux VPS veya VDS sunucu ortamlarında ciddi risk oluşturur.

Logrotate, sistem yöneticisine şu soruların yanıtını otomatikleştirme imkanı verir: Log dosyası ne zaman döndürülecek? Kaç eski kopya saklanacak? Eski loglar sıkıştırılacak mı? Servis yeniden başlatılacak mı? Yeni log dosyasının sahibi ve izinleri ne olacak? Böylece log yönetimi manuel bir işlem olmaktan çıkar ve sürdürülebilir bir altyapı standardına dönüşür.

Log Rotasyonu Neden Önemlidir?

Log dosyaları sistem sağlığını, güvenlik olaylarını, uygulama hatalarını ve kullanıcı trafiğini anlamak için vazgeçilmezdir. Ancak logların tamamen sınırsız bırakılması, faydadan çok zarar getirebilir. Log rotasyonu, hem operasyonel süreklilik hem de güvenlik açısından kritik bir ihtiyaçtır.

• Disk doluluğunu önler: Kontrolsüz büyüyen log dosyaları /var bölümünü doldurabilir. Disk tamamen dolduğunda web sunucusu, veritabanı veya e-posta servisi düzgün çalışmayabilir.
• Performansı korur: Çok büyük log dosyalarının okunması, taranması ve yedeklenmesi daha uzun sürer. Düzenli rotasyon, analiz süreçlerini hızlandırır.
• Arşiv düzeni sağlar: Günlük, haftalık veya aylık olarak ayrılmış loglar olay incelemesini kolaylaştırır.
• Yedekleme maliyetini azaltır: Sıkıştırılmış eski loglar daha az disk alanı kaplar ve yedekleme süresini düşürür.
• Uyumluluk süreçlerini destekler: Bazı sektörlerde logların belirli süre saklanması gerekir. Logrotate, saklama politikalarının uygulanmasına yardımcı olur.
• Servis kesintilerini azaltır: Disk doluluğu nedeniyle oluşan ani kesintilerin önüne geçilir.

Özellikle paylaşımlı Linux Hosting, kurumsal Sanal Sunucu ve yüksek trafikli Kiralık Sunucu ortamlarında log rotasyonu, temel sistem bakım politikalarından biri olmalıdır.

Logrotate Nasıl Çalışır?

Logrotate genellikle zamanlanmış görevler üzerinden çalışır. Birçok Linux dağıtımında Logrotate, günlük olarak cron veya systemd timer mekanizmasıyla tetiklenir. Çalıştığında ana yapılandırma dosyasını okur, ilgili servisler için tanımlanmış kuralları inceler ve rotasyon şartı oluşmuşsa işlem yapar.

Basit bir rotasyon süreci şu adımlardan oluşur:

1. Log dosyası kontrol edilir: Dosyanın boyutu, yaşı veya tanımlanan zaman aralığı incelenir.
2. Eski dosya yeniden adlandırılır: Örneğin access.log dosyası access.log.1 haline getirilebilir.
3. Yeni dosya oluşturulur: Servisin yazmaya devam edebilmesi için boş bir log dosyası oluşturulur.
4. İzin ve sahiplik atanır: Yeni dosyaya doğru kullanıcı, grup ve dosya izni verilir.
5. Eski log sıkıştırılır: Genellikle gzip ile .gz uzantılı arşiv oluşturulur.
6. Servis bilgilendirilir: Bazı servislerin yeni dosyaya yazması için yeniden yükleme veya sinyal gönderme gerekir.
7. Saklama sınırı uygulanır: Tanımlanan sayıdan eski log dosyaları silinir.

Bu işlemler doğru yapılandırıldığında kullanıcı trafiğini kesmeden ve servisleri gereksiz yere yeniden başlatmadan log yönetimi yapılabilir.

Temel Yapılandırma Dosyaları

Logrotate yapılandırması çoğunlukla iki ana konumda bulunur. Dağıtıma göre küçük farklılıklar olabilir; ancak genel mantık aynıdır.

• /etc/logrotate.conf: Global ayarların bulunduğu ana yapılandırma dosyasıdır. Varsayılan rotasyon sıklığı, sıkıştırma ve dahil edilecek dizinler burada tanımlanabilir.
• /etc/logrotate.d/: Servis bazlı yapılandırma dosyalarının bulunduğu dizindir. Nginx, Apache, MySQL, PHP-FPM veya özel uygulamalar için ayrı dosyalar burada tutulur.
• /var/lib/logrotate/status: Logrotate tarafından tutulan durum dosyasıdır. Hangi log dosyasının en son ne zaman döndürüldüğü burada izlenir.

Ana yapılandırma dosyasını incelemek için aşağıdaki komut kullanılabilir:

cat /etc/logrotate.conf

Servis bazlı kuralları listelemek için:

ls -lah /etc/logrotate.d/

Logrotate durum dosyasını görüntülemek için:

cat /var/lib/logrotate/status

Özel bir uygulama için yapılandırma eklemek istenirse genellikle /etc/logrotate.d/uygulama-adi formatında yeni bir dosya oluşturulur. Bu yaklaşım, global dosyayı karmaşıklaştırmadan servis bazlı yönetim sağlar.

En Çok Kullanılan Logrotate Parametreleri

Logrotate esnek bir araçtır ve farklı senaryolar için birçok parametre sunar. Aşağıdaki tablo, en yaygın kullanılan seçenekleri ve kullanım amaçlarını özetler.

Parametre seçimi sunucunun kullanım amacına göre yapılmalıdır. Örneğin yüksek trafikli bir e-ticaret sitesinde daily, rotate 30, compress ve delaycompress mantıklı olabilir. Küçük bir kurumsal tanıtım sitesinde ise weekly ve rotate 8 yeterli olabilir.

Örnek Logrotate Yapılandırmaları

Bu bölümde gerçek hayatta sık kullanılan servisler için örnek Logrotate yapılandırmaları yer almaktadır. Örneklerdeki kullanıcı ve grup adları dağıtıma göre değişebilir. Ubuntu tabanlı sistemlerde web servisleri çoğunlukla www-data, bazı sistemlerde ise apache veya nginx kullanıcısıyla çalışabilir.

Nginx Access ve Error Logları

Nginx loglarını günlük döndürmek, 14 günlük arşiv tutmak ve eski logları sıkıştırmak için şu yapılandırma kullanılabilir:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        systemctl reload nginx >/dev/null 2>&1 || true
    endscript
}

sharedscripts parametresi, birden fazla log dosyası eşleşse bile postrotate bloğundaki komutun tek kez çalışmasını sağlar. Bu, gereksiz servis yeniden yüklemelerini önler.

Apache Logları

Apache üzerinde access ve error logları için benzer bir yaklaşım uygulanabilir:

/var/log/apache2/*.log {
    weekly
    missingok
    rotate 8
    compress
    delaycompress
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        systemctl reload apache2 >/dev/null 2>&1 || true
    endscript
}

Apache logları yüksek trafikte hızla büyüyebilir. Bu nedenle haftalık rotasyon yeterli değilse weekly yerine daily tercih edilmelidir.

Laravel Uygulama Logları

Laravel projelerinde storage/logs/laravel.log dosyası zaman içinde büyüyebilir. Uygulama seviyesinde günlük loglama kullanılsa bile sunucu tarafında ek kontrol sağlamak faydalıdır.

/var/www/proje/storage/logs/*.log {
    daily
    missingok
    rotate 10
    compress
    delaycompress
    notifempty
    create 0640 www-data www-data
    su www-data www-data
}

su parametresi, Logrotate işleminin belirtilen kullanıcı ve grup bağlamında yapılmasına yardımcı olur. Özellikle uygulama dizinlerinde izin sorunlarını önlemek için önemlidir.

Özel Uygulama Logları

Node.js, Python, Go veya özel bir arka plan servisi için /opt/app/logs altında log tutuluyorsa şu örnek kullanılabilir:

/opt/app/logs/*.log {
    size 200M
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

copytruncate, çalışan uygulamanın log dosyasını kapatıp yeniden açamadığı durumlarda kullanılabilir. Bu seçenek mevcut dosyayı kopyalayıp içeriğini sıfırlar. Pratik olsa da çok yoğun yazma yapılan sistemlerde kısa süreli veri kaybı riski oluşturabileceği için dikkatli kullanılmalıdır.

Test ve Hata Ayıklama

Logrotate yapılandırması eklendikten sonra doğrudan üretim ortamında beklemek yerine test edilmelidir. Yanlış izin, hatalı dosya yolu veya servis yeniden yükleme komutu sorunlara neden olabilir.

Bir yapılandırmayı debug modunda test etmek için:

logrotate -d /etc/logrotate.d/nginx

-d parametresi gerçek işlem yapmadan Logrotate’ın ne yapacağını gösterir. Bu mod, yapılandırma hatalarını anlamak için güvenlidir.

Rotasyonu zorla çalıştırmak için:

logrotate -f /etc/logrotate.d/nginx

Tüm Logrotate yapılandırmasını debug modunda kontrol etmek için:

logrotate -d /etc/logrotate.conf

Logrotate çalıştıktan sonra ilgili dizindeki dosyalar kontrol edilmelidir:

ls -lah /var/log/nginx/

Durum dosyasında ilgili kaydın oluşup oluşmadığını görmek için:

grep nginx /var/lib/logrotate/status

En sık karşılaşılan hatalar arasında yanlış dosya yolu, hatalı kullanıcı adı, eksik grup, dosya izinlerinin uygulama tarafından desteklenmemesi ve postrotate içinde başarısız servis komutu bulunur. Bu nedenle her yeni kural kontrollü şekilde test edilmelidir.

Güvenlik ve Performans İpuçları

Logrotate yalnızca disk alanı yönetimi aracı değildir; doğru kullanıldığında güvenlik ve performans süreçlerine de katkı sağlar. Ancak hatalı yapılandırma, hassas logların yetkisiz kişilerce okunmasına veya uygulamaların log yazamamasına neden olabilir.

• Dosya izinlerini sınırlı tutun: Log dosyaları IP adresi, kullanıcı adı, oturum bilgisi, hata detayları veya özel uygulama çıktıları içerebilir. Bu nedenle 0640 gibi sınırlı izinler tercih edilmelidir.
• Herkese açık dizinlerde log tutmayın: Log dosyaları web kök dizini altında erişilebilir olmamalıdır. /public veya /html altında log saklamak güvenlik riski oluşturur.
• Sıkıştırmayı aktif kullanın: compress parametresi eski logların disk kullanımını ciddi oranda azaltır.
• Servisi gereksiz yeniden başlatmayın: Mümkünse restart yerine reload kullanın. Yeniden başlatma kısa süreli kesinti oluşturabilir.
• Uygun saklama süresi belirleyin: Her logu aylarca saklamak her zaman gerekli değildir. Güvenlik, yasal gereklilik ve disk kapasitesi birlikte değerlendirilmelidir.
• Merkezi loglama ile birlikte kullanın: Kritik sistemlerde yerel log rotasyonu yapılırken loglar ayrıca merkezi bir log sunucusuna gönderilebilir.
• Disk alarmı kurun: Logrotate iyi yapılandırılmış olsa bile beklenmeyen trafik artışı veya uygulama hatası disk kullanımını artırabilir. Disk doluluk alarmları ihmal edilmemelidir.
• Uygulama log seviyesini kontrol edin: Üretim ortamında gereksiz debug logları yüksek disk tüketimine yol açabilir.

Güvenli ve sürdürülebilir bir altyapı için log rotasyonu, yedekleme ve izleme süreçleri birlikte düşünülmelidir. Kritik verilerin düzenli korunması için Yedekleme Hizmeti gibi çözümlerle log ve sistem verilerinin bütünlüğü desteklenebilir.

Pratik Kullanım Senaryoları

Logrotate yapılandırması her sunucuda aynı olmamalıdır. Sunucu rolü, trafik seviyesi, disk kapasitesi ve uyumluluk gereksinimleri dikkate alınmalıdır.

Senaryo 1: Küçük Kurumsal Web Sitesi

Düşük trafikli bir kurumsal sitede haftalık rotasyon ve 8 haftalık saklama genellikle yeterlidir. Bu yapılandırma hem geçmiş hata kayıtlarını saklar hem de disk kullanımını düşük tutar.

• Rotasyon sıklığı: Haftalık
• Saklama: 8 kopya
• Sıkıştırma: Aktif
• Ek öneri: Boş loglar için notifempty kullanımı

Senaryo 2: Yüksek Trafikli E-Ticaret Sitesi

Yoğun trafikli e-ticaret altyapılarında access loglar çok hızlı büyür. Günlük rotasyon hatta boyut bazlı ek rotasyon gerekebilir. Bu tür sistemlerde loglar analiz ve güvenlik incelemesi için değerlidir.

• Rotasyon sıklığı: Günlük veya size bazlı
• Saklama: 30 gün veya iş ihtiyacına göre daha fazla
• Sıkıştırma: Aktif
• Ek öneri: Merkezi log toplama ve disk alarmı

Senaryo 3: Uygulama Sunucusu

API, mikroservis veya arka plan işçisi çalıştıran sunucularda uygulama logları çok hızlı büyüyebilir. Özellikle hata döngüsüne giren bir servis dakikalar içinde büyük log üretebilir.

• Rotasyon sıklığı: Boyut bazlı, örneğin size 100M
• Saklama: 7 veya 14 kopya
• Sıkıştırma: Aktif
• Ek öneri: Uygulama log seviyesinin üretim ortamına uygun ayarlanması

Senaryo 4: Çoklu Web Sitesi Barındıran Hosting Sunucusu

Birden fazla web sitesinin barındırıldığı sunucularda her site için ayrı log dosyaları oluşabilir. Bu durumda standart bir Logrotate şablonu kullanmak yönetimi kolaylaştırır. Hosting ortamlarında logların site bazlı ayrılması, hem hata takibini hem de müşteri bazlı kaynak analizini kolaylaştırır.

• Rotasyon sıklığı: Günlük veya haftalık
• Saklama: Paket politikasına göre 7, 14 veya 30 gün
• Sıkıştırma: Aktif
• Ek öneri: Kullanıcı bazlı izinlerin sıkı kontrol edilmesi

Senaryo 5: Güvenlik Odaklı Sunucu

Güvenlik incelemelerinde auth log, firewall log ve uygulama hata logları kritik rol oynar. Bu logların çok kısa sürede silinmesi olay analizi yapmayı zorlaştırabilir. Bu nedenle güvenlik odaklı sistemlerde saklama süresi daha uzun planlanmalıdır.

• Rotasyon sıklığı: Günlük
• Saklama: En az 30 gün, ihtiyaca göre daha fazla
• Sıkıştırma: Aktif
• Ek öneri: Uzak log sunucusuna kopyalama

Sıkça Sorulan Sorular

Sonuç

Logrotate, Linux sunucularda log dosyalarının düzenli, güvenli ve kontrollü şekilde yönetilmesini sağlayan temel araçlardan biridir. Doğru yapılandırıldığında disk doluluğunu önler, performansı korur, olay incelemelerini kolaylaştırır ve operasyonel sürekliliğe katkı sağlar. Web sunucusu, veritabanı, uygulama servisi veya çoklu hosting altyapısı fark etmeksizin her üretim ortamında log rotasyonu planlı şekilde uygulanmalıdır.

İyi bir Logrotate stratejisi; doğru rotasyon sıklığı, uygun saklama süresi, güvenli dosya izinleri, sıkıştırma, test süreci ve izleme mekanizmalarından oluşur. Küçük bir yapılandırma hatası bile uygulamanın log yazamamasına veya disk alanının beklenmedik şekilde dolmasına neden olabilir. Bu nedenle her kural test edilmeli, sunucu rolüne göre özelleştirilmeli ve düzenli olarak gözden geçirilmelidir.

Corelux altyapılarında web sitesi, uygulama veya kurumsal servislerinizi güvenilir şekilde barındırmak için Türkiye VDS Sunucu, Bulut Sunucu ve Uygulama Sunucuları çözümlerini değerlendirebilirsiniz. Düzenli log rotasyonu, güçlü sunucu altyapısı ve doğru yedekleme politikası bir araya geldiğinde daha stabil, güvenli ve sürdürülebilir bir sistem yönetimi elde edilir.