n8n Sunucuda Disk Dolarsa İlk Ne Kontrol Edilir?

n8n üzerinde çalışan otomasyonlar aniden duruyor, webhook yanıtları gecikiyor veya arayüzde beklenmeyen hatalar görünüyorsa disk alanı ilk kontrol edilmesi gereken kaynaklardan biridir. Disk tamamen dolduğunda yalnızca yeni workflow çalışmaları değil, veritabanı yazma işlemleri, log üretimi, Docker katmanları ve yedekleme süreçleri de etkilenebilir. Bu nedenle panik silme işlemleri yerine önce alanı neyin tükettiğini doğru görmek gerekir.

İlk kontrol: gerçekten disk mi dolu?

Önce sunucudaki genel disk kullanımını kontrol edin. Linux sunucularda en hızlı yaklaşım df -h çıktısına bakmaktır. Burada özellikle n8n’in kurulu olduğu bölüm, Docker kullanılıyorsa Docker’ın veri dizininin bulunduğu bölüm ve veritabanının çalıştığı disk izlenmelidir.

Disk yüzde 90’ın üzerindeyse risk başlamış demektir. Yüzde 100’e ulaşmış bir sistemde n8n yeni execution kaydı oluşturamayabilir, PostgreSQL veya SQLite yazma hatası verebilir, container yeniden başlatıldığında düzgün ayağa kalkmayabilir.

Alanı en çok tüketen dizinleri belirleyin

n8n disk dolması durumunda yapılan en yaygın hata, rastgele dosya silmektir. Bunun yerine büyük dizinleri sıralayarak ilerlemek gerekir. Genellikle kontrol edilmesi gereken alanlar şunlardır:

• Docker volume ve container log dizinleri
• n8n execution kayıtlarının tutulduğu veritabanı
• Geçici dosyalar ve indirilen binary veriler
• Eski yedekler ve arşivler
• Sistem logları, özellikle uzun süredir rotate edilmeyen log dosyaları

Docker ile çalışan kurulumlarda /var/lib/docker dizini beklenenden hızlı büyüyebilir. Özellikle uzun süredir temizlenmeyen image, stopped container ve volume kalıntıları disk kullanımını artırır. Ancak volume silme işlemi n8n verisini de etkileyebileceği için hangi volume’un neye ait olduğu netleşmeden müdahale edilmemelidir.

n8n execution kayıtları kontrol edilmeli

n8n’de her workflow çalışması execution verisi üretir. Hata alan, sık çalışan veya büyük veri taşıyan workflow’lar zamanla veritabanını büyütebilir. Binary data saklanıyorsa bu büyüme daha belirgin hale gelir.

Bu noktada n8n ayarlarında execution pruning politikasının açık olup olmadığı kontrol edilmelidir. Başarılı ve hatalı execution kayıtlarının ne kadar süre saklanacağı kurumsal ihtiyaçlara göre belirlenmelidir. Denetim gerekliliği yoksa aylarca gereksiz execution verisi tutmak operasyonel risk oluşturur.

Yanlış silme riskine dikkat edin

SQLite kullanan kurulumlarda tek bir veritabanı dosyası kritik olabilir. Bu dosyanın elle silinmesi tüm workflow geçmişini ve bazı konfigürasyonları kaybettirebilir. PostgreSQL kullanılıyorsa tablo bazlı büyüme analiz edilmeli, doğrudan veri dizinine müdahale edilmemelidir. Önce yedek alınmalı, ardından retention veya pruning ayarlarıyla kontrollü temizlik yapılmalıdır.

Log dosyaları ve Docker çıktıları

n8n veya reverse proxy logları uzun süre sınırlandırılmadığında GB seviyesine ulaşabilir. Docker container logları da benzer şekilde büyür. Bu nedenle log rotation ayarları kontrol edilmeli, yalnızca geçmiş ve ihtiyaç duyulmayan loglar temizlenmelidir.

Canlı hata analizi devam ediyorsa en yeni logların silinmesi sorunun kök nedenini görmeyi zorlaştırabilir. Önce dosya boyutları incelenmeli, ardından eski loglar arşivlenmeli veya güvenli biçimde boşaltılmalıdır.

Binary data ve dosya işleyen workflow’lar

Dosya indiren, e-posta eki işleyen, API’den büyük veri çeken veya rapor üreten workflow’lar disk tüketimini hızlandırabilir. n8n binary data ayarları, geçici dosya saklama davranışı ve workflow içinde üretilen dosyaların ne kadar süre tutulduğu gözden geçirilmelidir.

Özellikle büyük CSV, PDF, görsel veya video dosyaları işleniyorsa bu verilerin kalıcı olarak sunucuda tutulması yerine harici depolama alanlarına aktarılması daha sağlıklı olabilir. Böylece otomasyon sunucusu uygulama çalıştırmaya odaklanır, dosya arşivi görevini üstlenmez.

Hızlı müdahale sıralaması

• Disk kullanımını ve dolan partition’ı doğrulayın.
• En büyük dizinleri tespit edin; tahmine göre silme yapmayın.
• Docker logları, eski image’lar ve kullanılmayan container’ları inceleyin.
• n8n execution geçmişi ve binary data saklama politikasını kontrol edin.
• Veritabanı dosyasına veya volume’lara müdahale etmeden önce yedek alın.
• Kalıcı çözüm için log rotation, pruning ve izleme alarmı ekleyin.

n8n disk dolması yalnızca depolama kapasitesi problemi olarak değerlendirilmemelidir; çoğu zaman log yönetimi, execution saklama politikası, Docker temizliği veya workflow tasarımındaki veri akışıyla ilgilidir. Disk tekrar dolmadan önce alarm eşikleri belirlemek, yedeklerin konumunu ayırmak ve düzenli temizlik politikasını standart işletim sürecine eklemek n8n’in kararlı çalışmasını korur.