cPanel ve VPS’te Log Arşivleme Stratejisi: gzip, S3 ve Saklama Süreleri

Neden cPanel ve VPS’te Log Arşivleme Stratejisi Şart?

Loglar, bir sunucunun kara kutusudur: Performans sorunlarını, güvenlik ihlallerini, e‑posta teslim problemlerini ve uygulama hatalarını geriye dönük olarak analiz etmenin tek somut kaynağıdır. Ancak plansız loglama, birkaç ay içinde diski dolduran, arandığında bulunamayan ve KVKK/GDPR tarafında başınızı ağrıtabilecek bir veri yığınına dönüşür. Özellikle cPanel kullanan paylaşımlı hosting ortamlarında ve kendi yönettiğiniz VPS sunucularda, logların nasıl sıkıştırıldığı, nereye arşivlendiği ve ne kadar süre saklandığı net tanımlanmadığında, bir gün ansızın “No space left on device” veya “şu tarihteki erişimleri gösterebilir misiniz?” sorusuyla karşılaşmanız an meselesidir.

Bu yazıda DCHost ekibi olarak, cPanel ve VPS ortamlarında gördüğümüz gerçek senaryolardan yola çıkarak log arşivleme için uygulanabilir bir yol haritası çıkaracağız. gzip ile sıkıştırma seviyeleri, S3/object storage offload mimarisi ve KVKK/GDPR ile uyumlu saklama süresi politikaları üzerinden gideceğiz. Yazıyı bitirdiğinizde, ister tek bir cPanel hesabınız olsun ister onlarca VPS yönetin, loglar için tutarlı, otomasyona bağlanmış ve test edilmiş bir arşivleme stratejisini nasıl kuracağınızı net şekilde kafanızda canlandırmış olacaksınız.

cPanel Ortamında Log Türleri ve Varsayılan Davranış

cPanel sunucularda loglar birçok farklı klasöre dağılmış durumdadır ve varsayılan ayarların ne yaptığını bilmezseniz, bazı kritik kayıtları gereğinden kısa, bazılarını ise gereksiz yere uzun süre saklayabilirsiniz.

Başlıca log türleri

• Apache erişim logları (domlogs): Genellikle /usr/local/apache/domlogs/ altında tutulur. Her domain için ayrı dosyalar vardır.
• Apache hata logu: Örneğin /usr/local/apache/logs/error_log. PHP hataları, 500 hataları vb. burada görünür.
• cPanel kullanıcı logları: Her hesabın cPanel > Metrics > Errors ve Raw Access menülerinden indirebildiği loglar.
• Mail logları: Exim için /var/log/exim_mainlog, exim_rejectlog; Dovecot/IMAP için ayrı loglar.
• FTP, cPHulk, erişim logları: Giriş denemeleri, brute-force tespitleri, panel erişimleri vb. için.
• Sistem logları: /var/log/messages, /var/log/secure gibi çekirdek ve servis logları.

WHM tarafında log ayarları

cPanel/WHM’de Tweak Settings > Stats and Logs bölümünde birkaç kritik ayar bulunur:

• “Archive logs in /usr/local/apache/domlogs too?” – Erişim loglarını arşivleyip sıkıştırılmış şekilde domlogs altında biriktirir.
• “Keep log files at least X days” – Apache loglarının minimum saklama süresini belirler.
• Stat programları (AWStats, Webalizer) için log saklama – İstatistik üretimi için ne kadar geriye dönük log tutulacağını belirler.

Bu ayarları log arşivleme stratejinizle uyumlu hale getirmediğinizde, cPanel kendi içinde bir şeyler yaparken sizin harici otomatizasyonlarınız farklı bir mantıkla log silip bırakabilir. Özellikle raw access log dosyalarının ne kadar süre cPanel hesabı içinde tutulacağını belirlemek, hem diski hem de KVKK uyumunu doğrudan etkiler.

cPanel logları için ilk yapılması gerekenler

• Hangi log dosyalarının uygulama hatası debuggingi için, hangilerinin güvenlik ve yasal ispat için kritik olduğunu listeleyin.
• Apache, Exim ve sistem logları için /etc/logrotate.d/ altındaki dosyaları inceleyin; rotasyon sıklığını ve saklama sayısını not alın.
• Paneldeki “archive logs” ayarlarını, planladığınız gzip + object storage offload stratejisiyle uyumlu olacak şekilde güncelleyin.

VPS Üzerinde Loglar: Nginx, Apache, Uygulama ve Sistem

Kendi yönettiğiniz VPS’lerde cPanel olmak zorunda değil; Nginx, Apache, Node.js, Laravel, Docker vb. birleşik mimarilerde logların dağınıklığı daha da artar. DCHost üzerinde yönettiğimiz VPS ortamlarında en sık gördüğümüz log konumları şöyle:

• Nginx: /var/log/nginx/access.log, /var/log/nginx/error.log
• Apache: /var/log/httpd/ veya /var/log/apache2/ altındaki erişim ve hata logları
• PHP-FPM: /var/log/php-fpm/error.log veya havuz bazlı loglar
• Uygulama logları: Laravel için storage/logs/laravel.log, Node.js uygulamaları için kendi oluşturduğunuz logs/ klasörleri vb.
• systemd / journald: journalctl üzerinden erişilen servis logları, /var/log yerine binary journal formatında tutuluyor olabilir.

Eğer log rotasyonu sadece Nginx ve Apache için kurulu, ancak Laravel veya Node.js logları hiç rotate edilmiyorsa, disk dolma problemleri neredeyse her zaman bu custom loglardan çıkıyor. Bu konuyu daha önce detaylı ele aldığımız VPS disk kullanımı ve logrotate ile “No space left on device” hatasını önleme rehberine mutlaka göz atmanızı öneririm.

gzip ile Log Sıkıştırma: Temel İlkeler ve logrotate Örnekleri

Log arşivleme stratejisinin ilk ayağı, doğru sıkıştırmadır. Amaç; analiz için ihtiyaç duyduğunuz kadar detaylı logu saklarken, disk maliyetini minimumda tutmak ve sıkıştırma/de-sıkıştırma sırasında sunucuyu boğmamaktır.

gzip sıkıştırma seviyeleri

gzip komutu, 1–9 arası sıkıştırma seviyelerine sahiptir:

• -1, -2: Daha az CPU, daha büyük dosyalar
• -5, -6: Çoğu sunucu için dengeli; iyi sıkıştırma, makul CPU kullanımı
• -9: Maksimum sıkıştırma, ancak yoğun CPU tüketimi; yüksek trafikli sunucularda önerilmez

Loglar genellikle tekrarlı metin içerdiği için orta seviye bir gzip ayarı bile dosya boyutunu 5–10 kata kadar düşürebilir. DCHost tarafında pratikte, logrotate ile varsayılan gzip ayarları çoğu iş yükü için yeterli; ekstra olarak compressoptions -5 gibi bir ayarla CPU yükünü biraz hafifletebilirsiniz.

Nginx için örnek logrotate konfigürasyonu

Tipik bir /etc/logrotate.d/nginx dosyası şöyle olabilir:

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

• daily: Günlük rotasyon
• rotate 14: 14 gün geriye dönük log tutulur (toplam ~2 hafta)
• compress: Eski log dosyaları .gz uzantısıyla sıkıştırılır
• delaycompress: En son dönen dosya bir sonraki rotasyonda sıkıştırılır; o güne ait log dosyasını hemen analiz etmek isterseniz işinizi kolaylaştırır.

Benzer bir yapı Apache ve diğer servisler için de kullanılabilir. Önemli olan; lokal disk üzerinde ne kadar süre tutulacağı ile object storage’a ne zaman taşınacağı arasındaki ilişkiyi iyi kurmanızdır.

Custom uygulama logları için logrotate

Laravel, Node.js veya başka bir framework ile çalışan uygulamalarınız varsa, onların log klasörlerini de logrotate’e eklemelisiniz:

/var/www/proje-1/storage/logs/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

copytruncate, logu kesmeden dosyayı kopyalayıp boşaltır; uygulamayı yeniden başlatmak istemediğiniz durumlarda kullanışlıdır.

S3/Object Storage’a Log Offload Mimarisi

gzip ile lokal disk tarafını rahatlattıktan sonra ikinci adım, logları düşük maliyetli ve ölçeklenebilir bir depoya taşımaktır. Bunun için en pratik ve esnek çözüm, S3 uyumlu object storage kullanmaktır. DCHost altyapısında sunduğumuz S3 uyumlu depolama, log arşivleme senaryolarında sıkça kullandığımız yapı taşlarından biri.

Object storage’ın log arşivleme için neden ideal olduğunu, daha geniş bir bakış açısından Object Storage vs Block Storage vs File Storage rehberimizde detaylıca anlatmıştık. Burada doğrudan log özelinde mimariye odaklanalım.

Hedef mimari

• cPanel sunucu veya VPS üzerinde loglar günlük olarak rotate edilip gzip ile sıkıştırılır.
• Her gece (örneğin 03:00’te) sıkıştırılmış loglar, rclone benzeri bir araçla S3 uyumlu object storage’a senkronize edilir.
• Bucket içinde proje-adi/logs/<sunucu-adı>/<yıl>/<ay>/<gün> gibi anlamlı klasör hiyerarşisi kullanılır.
• Object storage tarafında Lifecycle Policy ile loglar belirli bir süreden sonra soğuk depolamaya taşınır veya tamamen silinir.

rclone ile log offload örneği

rclone ile object storage’a otomatik yedek alma konusunu, uygulamalı olarak object storage’a otomatik yedek alma rehberimizde ayrıntılı anlattık. Aynı yaklaşımı log dosyalarınız için de kullanabilirsiniz.

1. rclone remote tanımı
   Örneğin logs adında bir remote:

rclone config
# Yeni remote ekleyin, tip olarak S3 uyumlu depolamayı seçin,
# DCHost tarafında size verilen erişim anahtarlarını girin.

2. Senkranizasyon komutu
   cPanel veya VPS üzerinde, sıkıştırılmış logları senkronize etmek için:

rclone sync 
  /var/log/nginx/ 
  logs:proje-1/logs/web01/nginx/ 
  --include "*.gz" 
  --max-age 30d 
  --transfers=4 --checkers=8

Burada:

• –include “*.gz” sadece gzip’lenmiş dosyaları taşır.
• –max-age 30d son 30 günden eski dosyaları senkronizasyon dışında bırakır; böylece gereksiz listeleme maliyetlerini azaltırsınız.

Cron ile otomasyon

Her gece saat 03:15’te log offload çalıştırmak için basit bir cron girdisi yeterlidir:

15 3 * * * root /usr/local/bin/rclone sync 
    /var/log/nginx/ 
    logs:proje-1/logs/web01/nginx/ 
    --include "*.gz" --max-age 30d 
    --log-file /var/log/rclone-logs-sync.log --log-level INFO

Aynı yapıyı Apache, mail ve uygulama logları için farklı klasörlerle çoğaltabilirsiniz. Kritik nokta, bucket içinde okunabilir bir klasör yapısı kurmak ve her sunucuyu/uygulamayı ayırt edilebilir hale getirmektir.

Güvenlik ve erişim kontrolleri

• Object storage erişim anahtarlarını yalnızca log sync işlemi için özel bir kullanıcıyla sınırlayın.
• Mümkünse bucket düzeyinde salt okunur ve salt yazılabilir ayrı politika tanımlayın.
• Taşıma sırasında TLS kullanın; DCHost object storage uç noktalarımızda HTTPS zorunludur.
• Bucket içinde KVKK hassasiyeti olan loglar (IP adresi, e‑posta, kullanıcı ID’leri vb.) için şifreleme ve erişim denetimi katmanlarını daha sıkı kurgulayın.

Saklama Süresi Politikaları: Operasyon, Güvenlik ve KVKK Dengesi

Logları nereye koyacağınızı çözmek tek başına yeterli değil; asıl kritik konu, ne kadar süre saklayacağınızı tanımlayan politika. Bu konuda daha genel çerçeveyi, yedek saklama süresi ve KVKK/GDPR dengesini anlattığımız rehberde ele almıştık. Log özelinde ise biraz daha farklı nüanslar var.

Log türüne göre önerilen saklama seviyeleri

Aşağıdaki süreler, sahada gördüğümüz makul değerlerdir; elbette sektörünüzdeki yasal gereksinimleri ayrıca kontrol etmelisiniz.

• Web erişim logları (Apache/Nginx)
  • Lokal disk (sıcak veri): 7–30 gün
  • Object storage (sıcak/ılık): 6–12 ay
  • Soğuk arşiv (gerekiyorsa): 1–2 yıl
• Güvenlik ve sistem logları (ssh, sudo, firewall, cPHulk vb.)
  • Lokal disk: 30–90 gün
  • Object storage: 1–3 yıl (siber olay incelemesi için)
• Mail logları
  • Lokal disk: 30–90 gün
  • Object storage: 1–2 yıl (kurumsal uyumluluk ihtiyaçlarına göre)
• Uygulama logları (Laravel, Node.js vb.)
  • Lokal disk: 7–30 gün
  • Object storage: 6–12 ay (hata analizi ve audit trail için)

Bu süreler, hosting ve e‑posta altyapısında log saklama süreleri yazımızda anlattığımız prensiplerle uyumlu olacak şekilde seçilmiştir: Ne gereğinden kısa, ne de gereksiz yere uzun.

Object storage tarafında Lifecycle Policy kullanımı

Çoğu S3 uyumlu depolama sisteminde bucket bazlı Lifecycle Policy tanımlayabilirsiniz. Örneğin:

• 0–30 gün: Sıcak depolama (standart klasmanda; sık sorgulanan loglar)
• 30–365 gün: Infrequent Access / Warm tier (daha düşük maliyetli, nadiren erişilen loglar)
• 365+ gün: Tamamen sil (veya çok soğuk arşiv sınıfına taşı)

Böylece, DCHost üzerindeki VPS veya cPanel sunucunuzdan sadece günlük senkronizasyonu yönetirsiniz; hangi dosyanın ne zaman daha ucuz depoya taşınacağını ve ne zaman silineceğini object storage otomatik halleder.

KVKK/GDPR boyutu ve anonimleştirme

IP adresleri, kullanıcı ajanları, cookie değerleri, e‑posta adresleri gibi bilgiler loglarda yer aldığında, bu kayıtlar kişisel veri kapsamına girebilir. Bu noktada sadece saklama süresi değil, maskeleme/anomimleştirme stratejisi de devreye giriyor. Bu konuyu teknik örneklerle anlattığımız KVKK ve GDPR için log anonimleştirme rehberimizi mutlaka incelemenizi tavsiye ederim.

cPanel’de Uygulanabilir Log Arşivleme Senaryosu (Adım Adım)

Şimdi tüm bu parçaları birleştirip, tek bir cPanel sunucusu için somut bir senaryo üzerinden ilerleyelim. Varsayalım ki DCHost üzerinde bir cPanel sunucunuz var ve üzerinde 50 civarı site barındırıyorsunuz.

1. Envanter ve hedefler

• Hangi logların kritik olduğunu belirleyin: Apache erişim/hata, Exim, Dovecot, cPHulk, sistem logları, PHP error_log vb.
• Hangi loglar için analiz süresi (ör. 30 gün detaylı analiz), hangileri için hukuki ispat süresi (ör. 1–2 yıl) gerekeceğini netleştirin.

2. WHM log ayarlarını güncelleyin

• Archive logs in /usr/local/apache/domlogs too? seçeneğini aktif edin; böylece domlogs altında arşivli erişim loglarınız olacak.
• Keep log files at least alanını örneğin 14 gün yapın; böylece en azından iki haftalık lokal erişim logunuz garanti altına alınmış olur.

3. logrotate yapılarını gözden geçirin

/etc/logrotate.d/ altındaki httpd, exim, cpanel ve diğer logrotate dosyalarını inceleyin. Gerekirse:

• Rotasyon sıklığını haftalık yerine günlük yapın.
• rotate değerini 7–14 arasına çekerek lokal disk tutma süresini sınırlayın.
• compress ve delaycompress seçeneklerinin aktif olduğundan emin olun.

4. rclone ile object storage senkronizasyonu kurun

1. DCHost object storage hesabınızı oluşturun ve erişim anahtarlarını alın.
2. cPanel sunucusuna rclone kurun ve logs adında bir remote tanımlayın.
3. Aşağıdaki gibi bir senkronizasyon script’i yazın:

#!/bin/bash
set -e

HOSTNAME=$(hostname -s)
DATE=$(date +%Y/%m/%d)

# Apache domlogs
rclone sync 
  /usr/local/apache/domlogs/ 
  logs:cpanel-logs/${HOSTNAME}/apache/${DATE}/ 
  --include "*.gz" --ignore-existing

# Exim mail logları
rclone sync 
  /var/log/ 
  logs:cpanel-logs/${HOSTNAME}/mail/${DATE}/ 
  --include "exim*gz" --ignore-existing

Bu script’i örneğin /usr/local/sbin/log-offload.sh olarak kaydedip, çalıştırılabilir yapın.

5. Cron ile zamanlama ve lokal temizlik

Her gece saat 03:30’da offload script’ini çalıştırın ve 30 günden eski lokal gzip loglarını silin:

30 3 * * * root /usr/local/sbin/log-offload.sh >> /var/log/log-offload.log 2>&1
45 3 * * * root find /usr/local/apache/domlogs/ -name "*.gz" -mtime +30 -delete

Böylece:

• cPanel sunucunuzda son 30 günlük sıkıştırılmış loglar kalır.
• Daha eski tüm loglar, DCHost object storage üzerinde, Lifecycle Policy ile yönetilen düşük maliyetli depoda tutulur.

6. Geri dönüş (restore) senaryosunu test edin

Arşivleme stratejisi, geri dönüşü test edilmemişse tamamlanmış sayılmaz. Rastgele bir tarihteki log dosyasını object storage’tan indirip açarak; hem erişim yetkilerinizin doğru olduğunu, hem de sıkıştırmanın/verinin bozulmadığını doğrulayın.

VPS’te Gelişmiş Log Arşivleme: Merkezi ve Çok Sunuculu Yapılar

Birden fazla VPS yönettiğinizde, log arşivlemeyi sadece tek sunucu özelinde düşünmek yerine merkezi bir mimariye taşımak büyük avantaj sağlar. DCHost blogunda bunu iki farklı boyutuyla anlattık:

• ELK ve Loki stack ile merkezi hosting loglama
• Grafana Loki + Promtail ile VPS log yönetimi

Merkezi loglama ile object storage arşivini birlikte kullandığınızda ortaya şu mimari çıkar:

1. Her VPS, Promtail/beat/agent aracılığıyla logları gerçek zamanlı olarak merkezi Loki veya Elasticsearch kümesine gönderir.
2. Merkezi sistemde kısa vadeli saklama (ör. 7–30 gün) ve gelişmiş sorgulama/alarmlar kurulur.
3. Aynı loglar eş zamanlı veya periyodik olarak S3 uyumlu object storage’a sıkıştırılmış arşiv olarak yazılır.
4. Merkezi sistemde tutma süresi dolan veriler silinir; ancak object storage’taki uzun vadeli arşivler Lifecycle Policy ile yönetilmeye devam eder.

Böylece:

• Operasyon ekibiniz, son günlerin loglarını hızlı ve etkileşimli bir arayüz üzerinden inceler.
• Uyumluluk ve inceleme ihtiyaçları için yıllara yayılan arşiv, düşük maliyetli object storage üzerinde yaşar.

Sık Yapılan Hatalar ve DCHost Tarafında Önerdiğimiz İpuçları

Sahada en sık gördüğümüz hataları ve bunlara karşı önerilerimizi kısaca derleyelim:

• Hata: Sadece varsayılan logrotate’e güvenmek.
  Çözüm: Custom uygulama loglarını da logrotate’e dahil ettiğinizden ve gzip’in açık olduğundan emin olun.
• Hata: Tüm logları NVMe disk üzerinde yıllarca tutmaya çalışmak.
  Çözüm: cPanel/VPS diskini sadece kısa vadeli loglar için kullanın, uzun vadeyi mutlaka object storage’a offload edin.
• Hata: KVKK kapsamındaki verileri süresiz saklamak.
  Çözüm: Log saklama sürelerini iş amacıyla orantılı belirleyin, gerekirse IP maskeleme ve anonimleştirme uygulayın.
• Hata: Yedek/alarm kurup geri dönüş testini hiç yapmamak.
  Çözüm: En azından 3 ayda bir, rastgele bir günün loglarını object storage’tan indirip açarak test edin.
• Hata: Logları tek kopya ve tek lokasyonla sınırlamak.
  Çözüm: Kritik loglar için 3‑2‑1 prensibiyle en az bir kopyayı farklı depolama türünde (örneğin object storage) tutun.

Daha geniş resimde, KVKK/GDPR uyumluluğu, log saklama ve anonimleştirme konularını birlikte ele almak için KVKK ve GDPR uyumlu hosting stratejisi rehberimizi de inceleyebilirsiniz.

Sonuç ve DCHost ile Yol Haritanızı Netleştirin

cPanel ve VPS ortamlarında log arşivleme, “disk dolmasın” diye yapılan basit bir temizlik işi değildir. Doğru kurgulandığında; performans sorunlarını hızla teşhis etmenize, güvenlik olaylarını geriye dönük olarak detaylı incelemenize, e‑posta ve ödeme hatalarını somut verilerle kanıtlamanıza ve en önemlisi, KVKK/GDPR tarafında denetime hazır bir pozisyonda olmanıza yardımcı olur.

Bu yazıda, gzip ile sıkıştırma, S3 uyumlu object storage’a offload ve saklama süresi politikalarını bir arada ele alan uygulanabilir bir çerçeve çizdik. Sıradaki adım, kendi altyapınıza bakıp şu üç soruyu sormaktır:

• Hangi logları nerede ve ne kadar süre saklıyorum?
• Disk dolduğunda veya inceleme talebi geldiğinde elimde hangi kanıtlar olacak?
• Bu yapıyı nasıl otomatikleştirip, geri dönüşünü nasıl test edeceğim?

Eğer bu soruların cevabı henüz net değilse, DCHost olarak hem cPanel hosting hem de VPS/dedicated sunucu müşterilerimiz için log arşivleme stratejisini birlikte tasarlamaktan memnuniyet duyarız. Mevcut sunucunuzu bize taşıyor olun veya sıfırdan bir altyapı planlıyor olun; DCHost’un S3 uyumlu object storage çözümleri, merkezi loglama mimarileri ve yedekleme stratejileriyle, loglarınızı hem ölçeklenebilir hem de uyumlu bir yapıya taşıyabilirsiniz.