Linux Crontab En İyi Uygulamalar Rehberi: Yedek, Rapor ve Bakım İşleri İçin Güvenli Zamanlama

Linux crontab ile otomasyonun omurgasını kurmak

Linux tarafında belli bir ölçeğe gelmiş her projede aynı soruya geliyoruz: “Hangi işleri otomatikleştirdik ve hangileri hâlâ elle yapılıyor?” Yedek alma, log temizleme, rapor üretme, disk kontrolü, sertifika yenileme gibi işler birkaç sunucuda elle idare edilebilir; ancak işler büyüdükçe manuel süreçler hem risk hem de zaman kaybı hâline gelir. İşte Linux crontab, bu tekrar eden işleri güvenli ve öngörülebilir biçimde otomatikleştirmenin en temel aracı.

Bu rehberde, DCHost altyapısında yıllardır kullandığımız pratiklerden süzülmüş bir çerçeveyle ilerleyeceğiz. Amacımız sadece “cron nedir?” demek değil; yedek, rapor ve bakım işlerini hem güvenli hem de sürdürülebilir şekilde planlayabileceğiniz bir yol haritası sunmak. Zamanlama söz diziminden kilitlemeye (flock), log takibinden systemd timer’lara ne zaman geçmeniz gerektiğine kadar, gerçek dünyada işinize yarayacak detaylara odaklanacağız.

Linux crontab temelleri: Ne, nerede, nasıl çalışır?

Cron, Linux/Unix sistemlerde zamanlanmış görevleri çalıştıran bir servistir (daemon). Kullanıcıların görev tanımladığı dosyaya ise crontab denir. Temel bileşenler şöyle:

• crond: Arka planda çalışan servis; tanımlı tüm cron job’larını takip eder ve zamanı geldiğinde çalıştırır.
• Kullanıcı bazlı crontab: Her kullanıcı için ayrı tablo. Düzenleme komutu: crontab -e
• Sistem crontab: Genellikle /etc/crontab ve /etc/cron.d/ altındaki dosyalar.

En sık kullanılan komutlar:

# Geçerli kullanıcının crontab'ini düzenle
crontab -e

# Geçerli kullanıcının crontab'ini listele
crontab -l

# Geçerli kullanıcının crontab'ini sil
crontab -r

Genel olarak iyi bir pratik, uygulama bazlı görevleri ilgili kullanıcı hesabının crontab’ine yazmak; sistem genelini ilgilendiren işleri ise /etc/cron.d/ veya /etc/crontab üzerinden yönetmektir. Örneğin web uygulamanız www-data kullanıcısı altındaysa, onun crontab’ini kullanmak hem yetki hem de güvenlik açısından daha doğrudur.

Cron zamanlama söz dizimini doğru anlamak

Crontab satırının temel yapısı şöyledir:

* * * * * komut
| | | | |
| | | | +----- Haftanın günü (0-7, 0 ve 7 Pazar)
| | | +------- Ay (1-12)
| | +--------- Ayın günü (1-31)
| +----------- Saat (0-23)
+------------- Dakika (0-59)

Örnek:

# Her gece 03:15'te çalıştır
15 3 * * * /usr/local/bin/backup.sh

# Her 5 dakikada bir çalıştır
*/5 * * * * /usr/local/bin/check_queues.sh

# Her pazartesi saat 08:00'de çalıştır
0 8 * * 1 /usr/local/bin/weekly-report.sh

Söz diziminde sık düşülen hatalara dikkat etmek önemli:

• Ayın günü ve haftanın günü beraber kullanımı: İki alan da doluysa cron, ikisinden biri eşleştiğinde görevi çalıştırır. Çoğu kişi “ve” gibi davranacağını varsayıp yanlış zamanlama yapar.
• Adım (step) kullanımı: */10 (her 10 dakikada bir), 1-5 (1’den 5’e), 1,15,30 (liste) şeklinde kombinasyonlar yapılabilir.
• Zaman dilimi farkı: Sunucunuzun timezone’ı ile iş beklentileriniz aynı mı? Özellikle yurtdışı veri merkezlerindeki sunucularda yerel saat farkını hesaba katın.

Eğer cron söz dizimini ilerde systemd timer’larla kıyaslamak isterseniz, cron mu systemd timer mı tercih edilmeli? başlıklı rehberimizde iki yaklaşımın artılarını ve eksilerini detaylı anlattık.

Yedekleme işleri için güvenli cron stratejisi

Yedekleme, cron kullanımının en kritik alanlarından biri. Hata kaldırmaz, geri dönüşü pahalıdır. DCHost tarafında gözlemlediğimiz en yaygın problem, cron’a bir mysqldump satırı yazıp “yedeklemeyi hallettik” sanmak. Aslında işin içinde saklama stratejisi, şifreleme, performans ve geri dönüş testleri var.

1. Yedekleme script’ini ayrı tutun, crontab’e minimum yazın

İyi pratik: Crontab satırı olabildiğince sade olsun, asıl mantık bir shell/script dosyasında dursun.

# /usr/local/bin/backup-daily.sh
#!/usr/bin/env bash
set -euo pipefail

TIMESTAMP=$(date +"%Y%m%d-%H%M%S")
BACKUP_DIR="/var/backups/mysql"
DB_NAME="uygulama_db"

mkdir -p "${BACKUP_DIR}" 
/usr/bin/mysqldump --single-transaction "${DB_NAME}" 
  | gzip > "${BACKUP_DIR}/${DB_NAME}-${TIMESTAMP}.sql.gz"

# 7 günden eski yedekleri sil
find "${BACKUP_DIR}" -type f -mtime +7 -delete

Crontab satırı ise çok daha temiz kalır:

0 2 * * * /usr/bin/flock -n /var/lock/backup-daily.lock 
  /usr/local/bin/backup-daily.sh >> /var/log/backup-daily.log 2>&1

Burada birkaç en iyi uygulamayı bir arada görüyorsunuz:

• flock: Aynı iş bir önceki çalışması bitmeden tekrar başlamasın diye kilitleme (lock) mekanizması.
• Log yönlendirme: Çıktıyı bir log dosyasına yazıp hata ayıklamayı kolaylaştırma.
• set -euo pipefail: Script hata aldığında sessizce devam etmesin, job başarısız olsun.

2. 3-2-1 yedek stratejisini cron ile hayata geçirmek

Tek sunucuda tek kopya yedek, günün sonunda gerçek anlamda “yedekleme” sayılmaz. Sağlam bir yaklaşım için 3-2-1 stratejisini öneriyoruz: 3 kopya, 2 farklı ortam, 1 tanesi farklı lokasyonda. Bunu cron ile otomatikleştirirken şu akışı düşünebilirsiniz:

1. Yerel sunucuda günlük/veritabanı yedeği (disk üzerinde).
2. Aynı veri merkezinde farklı disk/volume üzerine ikinci kopya.
3. Object storage veya farklı lokasyona üçüncü kopya (off-site).

Bu stratejinin neden işe yaradığını ve farklı hosting senaryolarında nasıl uygulanacağını, 3-2-1 yedekleme stratejisi rehberimizde ayrıntılı şekilde anlattık. Cron tarafında ise her adımı ayrı job olarak, mantıklı bir sırayla çalıştırmak en doğrusudur.

3. Uzak (object storage) yedekleri cron ile senkronize etmek

Özellikle DCHost üzerindeki VPS ve dedicated sunucularda, veriyi object storage’a aktarmak artık çok yaygın bir pratik. Bunun için sık kullanılan araçlardan bazıları rclone ve restic. Örnek bir günlük senkronizasyon job’ı:

# Her gece 03:30'da yerel backup klasörünü uzak depoya senkronize et
30 3 * * * /usr/bin/flock -n /var/lock/rclone-backup.lock 
  /usr/bin/rclone sync /var/backups s3:projeyedekleri/$(hostname) 
  --log-file=/var/log/rclone-backup.log --log-level=INFO

rclone ve restic ile object storage’a otomatik yedek almayı adım adım görmek isterseniz, object storage’a otomatik yedek alma rehberimizi mutlaka inceleyin; crontab tarafında dikkat etmeniz gereken ince detayları da orada topladık.

4. Performans ve trafik saatlerini hesaba katmak

Yedekleme büyük I/O ve CPU tüketebilir. Özellikle yoğun erişim alan sitelerde, cron job’larınızı şu şekilde planlamayı öneriyoruz:

• Yoğun trafiğin en düşük olduğu zaman dilimini belirleyin (örneğin 02:00–05:00 arası).
• Veritabanı yedekleri, dosya senkronizasyonu, log sıkıştırma gibi işlerin çakışmamasına dikkat edin.
• Gerekirse nice ve ionice kullanarak yedek işlerine düşük öncelik verin.

0 2 * * * /usr/bin/flock -n /var/lock/mysql-backup.lock 
  /usr/bin/nice -n 10 /usr/bin/ionice -c2 -n7 
  /usr/local/bin/backup-daily.sh >> /var/log/backup-daily.log 2>&1

Raporlama ve log işleri: Cron ile görünürlük kazanmak

Yedek kadar kritik ama çoğu zaman ihmal edilen bir diğer alan, raporlama ve log bakımı. Cron, hem iş raporları üretmek hem de log’ların kontrolden çıkmasını engellemek için harika bir araçtır.

1. Haftalık/aylık raporları e-posta ile göndermek

Örneğin e-ticaret siteniz için haftalık sipariş ve ciro raporu üretmek istiyorsunuz. PHP/Laravel, Node.js veya Python ile bir CLI script yazıp bunu cron’a bağlamak çok yaygın bir yöntem.

# Laravel artisan schedule:run örneği
*/5 * * * * /usr/bin/php /var/www/app/artisan schedule:run 
  >> /var/log/artisan-schedule.log 2>&1

Veya doğrudan rapor üreten bir script:

0 7 * * 1 /usr/bin/python3 /opt/scripts/weekly_report.py 
  --output /var/reports/weekly-$(date +"%Y%m%d").pdf 
  >> /var/log/weekly-report.log 2>&1

Cron içinden e-posta göndermek için ortamda MTA (Postfix/Exim vb.) yapılandırılmışsa, komut çıktıları doğrudan mail olarak gönderilebilir. Bunun için MAILTO değişkeni kullanılabilir.

[email protected]
0 7 * * 1 /opt/scripts/weekly_report.sh

Bu yaklaşımı özellikle yöneticilere veya ekip arkadaşlarına düzenli operasyon raporu atmak için kullanabilirsiniz.

2. Log temizliği ve disk doluluğunu kontrol etmek

Log dosyaları, önlem alınmazsa aylar içinde diski doldurabilir. DCHost ortamlarında sonradan karşılaştığımız “disk dolu, site çalışmıyor” vakalarının önemli bir kısmında problem, log ve cache klasörlerinin kontrolsüz büyümesiydi.

Log temizliği için iki temel yaklaşım var:

• logrotate kullanmak: Çoğu dağıtımda varsayılan; döndürme, sıkıştırma, saklama süresi yönetimi için ideal.
• Kendi basit temizlik script’iniz: Belirli klasörlerde eski dosyaları silmek için.

# /var/log/app klasöründe 14 günden eski log'ları sil
30 4 * * * find /var/log/app -type f -mtime +14 -delete

Disk alanı ile ilgili daha derin bir rehbere ihtiyacınız varsa, özellikle logrotate ayarlarının nasıl kurtarıcı olabileceğini VPS disk kullanımı ve logrotate ayarları rehberimizde adım adım anlattık.

Bakım ve temizlik işleri: Sunucunun günlük ev işleri

Cron, sadece yedek ve rapor için değil, günlük/haftalık bakım işlerini otomatikleştirmek için de ideal. Ancak burada “fazla temizlik” de riskli olabilir; yanlış bir rm -rf komutu tüm uygulamayı silebilir. Bu yüzden bakım job’larını tasarlarken özellikle dikkatli olmak gerekiyor.

1. Cache ve geçici dosya temizleme

Birçok framework (Laravel, Symfony, WordPress eklentileri vb.) cache klasörlerinde büyük dosyalar biriktirir. Bunların bir kısmı otomatik temizlenir, bir kısmı ise siz temizlemezseniz kalıcı olur.

# 3 günden eski temp dosyalarını temizle
0 * * * * find /tmp/myapp -type f -mtime +3 -delete

WordPress gibi CMS’lerde cron tarafını optimize etmek istiyorsanız, uygulama içi wp-cron yerine gerçek sistem cron kullanmak büyük fark yaratır. Bu geçişi adım adım anlattığımız WordPress’te wp-cron devre dışı bırakma ve gerçek cron job kurulumu rehberine mutlaka göz atın.

2. Veritabanı bakım görevleri

Veritabanı tarafında da optimize, analyze, index bakım işlerini cron’a bağlamak yaygın. Ancak bu işler trafik yoğunluğuna duyarlı olduğundan, dikkatli zamanlanmalı.

# Her gece 04:00'te tablo istatistiklerini güncelle
0 4 * * * /usr/bin/mysqlcheck --optimize --all-databases 
  >> /var/log/mysql-maintenance.log 2>&1

Büyük e-ticaret veritabanlarında index optimizasyonu ve sorgu ayarlamaları için daha gelişmiş bir rehber arıyorsanız, WooCommerce ve büyük katalog siteleri için MySQL indeksleme ve sorgu optimizasyonu rehberimizi inceleyebilirsiniz.

3. Sertifika yenileme ve sağlık kontrolleri

Let’s Encrypt, özel script’ler veya ACME istemcileriyle sertifika yenileme işlemlerini de cron’a bağlamak çok yaygın. Örneğin:

# Her gün 03:00'te Let's Encrypt yenileme komutunu çalıştır
0 3 * * * /usr/bin/certbot renew --quiet 
  >> /var/log/letsencrypt-renew.log 2>&1

Ayrıca basit sağlık kontrolleri (disk doluluk oranı, servislerin ayakta olup olmadığı vb.) için ufak script’ler yazıp bunları cron ile tetikleyerek, problem çıkmadan önce e-posta uyarısı alabilirsiniz.

Güvenlik, ortam değişkenleri ve hata ayıklama

Crontab satırları genelde kısa olduğundan, iş başta “çalışıyor gibi” görünür. Fakat ortam değişkenleri, PATH, kullanıcı yetkileri ve loglama göz ardı edildiğinde; işin gerçekten doğru çalışıp çalışmadığını anlamak zorlaşır.

1. Ortam değişkenlerini net tanımlayın

Cron job’ları, interaktif shell ortamınızdan farklı bir ortamda çalışır. Örneğin:

• PATH değişkeniniz daha dar olabilir, bu yüzden komutlar bulunamayabilir.
• LANG / LC_ALL gibi locale ayarları farklı olabilir.
• Pyenv, nvm gibi araçlarla tanımladığınız versiyonlar cron ortamında geçerli olmayabilir.

Bu yüzden crontab’in başına ortam değişkenlerini açıkça eklemek iyi bir alışkanlıktır:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=en_US.UTF-8

Özellikle python, php, node gibi yorumlayıcılar için tam yolu (/usr/bin/python3 gibi) yazmak hata riskini azaltır.

2. Kullanıcı ve yetki yönetimi

Root crontab’ine her şeyi yazmak kısa vadede pratik görünebilir ama güvenlik açısından risklidir. Temel prensip:

• Uygulama işleri, ilgili uygulama kullanıcısının (www-data, deploy vb.) crontab’inde olsun.
• Sistem işleri (apt update, log temizliği vb.) root veya özel sistem kullanıcıları altında kalsın.
• Gerekmedikçe sudo kullanmayın; ihtiyaç varsa script içinde rol ayrımını net yapın.

3. Loglama ve hata ayıklama stratejisi

Cron job’ları başarısız olduğunda, çoğu zaman tek ipucunuz log’lardır. Bu yüzden her job için açık bir log stratejiniz olsun:

• Standart çıktıyı ve hatayı ayrı dosyalara yönlendirmek isteyebilirsiniz: > stdout.log 2> stderr.log
• Veya ikisini tek dosyada toplamak için >> job.log 2>&1 kullanabilirsiniz.
• Hata ayıklarken script’i önce elle çalıştırın, ardından bash -x script.sh ile satır satır ne yaptığını görün.

Cron log’ları dağıtıma göre genellikle /var/log/cron, /var/log/syslog veya /var/log/messages içinde tutulur. Hata aldığınızda ilk bakmanız gereken yer burası olmalı.

4. İzleme ve alarmlar ile cron’u görünür kılmak

Büyük resimde, “cron job çalıştı mı?” sorusunu manuel log takibiyle cevaplamak sürdürülebilir değil. Özellikle kritik yedek ve bakım işlerinde, izleme ve alarm sistemleriyle entegre olmak çok işe yarar. DCHost müşterilerimiz için önerdiğimiz yollardan biri, cron job’larının çıktılarını Prometheus, Grafana ve benzeri araçlarla takip etmek.

VPS üzerinde temel izleme ve alarm kurulumu için Prometheus, Grafana ve Uptime Kuma ile VPS izleme rehberimizi inceleyebilir, cron job’larınızı bu ekosisteme dahil ederek başarısız denemeleri otomatik bildirimle yakalayabilirsiniz.

Cron mu systemd timer mı? Ne zaman hangisini seçmeli?

Modern Linux dağıtımlarında (özellikle systemd kullananlarda) artık birçok sistem işi cron yerine systemd timer ile yapılıyor. İkisi de zamanlanmış görev çalıştırıyor; ancak bazı önemli farklar var:

• systemd timer: Servislerle doğal bütünleşme, durum takibi, log entegrasyonu (journal), esnek zaman tanımları (takvim ifadeleri) ve bağımlılık yönetimi sunar.
• cron: Çok hafif, kurulumu basit, neredeyse tüm Unix sistemlerde aynı mantıkla çalışır.

Genel bir kural olarak:

• Sadece bir komut/script çalıştıracaksanız ve karmaşık bağımlılıklar yoksa, cron genelde yeterlidir.
• Servis restart/healthcheck gibi systemd ile sıkı bağlı işler, yoğun log ve durum takibi gerektiren görevler için systemd timer daha uygundur.

Bu konuyu derinlemesine anlattığımız cron mu systemd timer mı, ne zaman hangisini seçmeli? yazımızda, gerçek senaryolar üzerinden hangi durumda hangi yaklaşımı önerdiğimizi bulabilirsiniz. Özellikle büyük ölçekte DCHost VPS kümeleri yönetiyorsanız, bu ayrım ciddi anlamda işinizi kolaylaştırır.

DCHost altyapısında crontab planlarken pratik öneriler

Cron job’larının nasıl ve nereden yönetileceği, kullandığınız hosting modeline göre de değişiyor. DCHost’ta paylaşımlı hosting, VPS, dedicated ve colocation tarafında sık gördüğümüz senaryolara göre bazı pratik öneriler:

1. Paylaşımlı hosting ve kontrol panelli ortamlar

cPanel veya DirectAdmin gibi panellerde, cron job’lar genelde web arayüzü üzerinden yönetilir. Bu, özellikle teknik olmayan kullanıcılar için büyük kolaylık sağlar. Ancak, yine de yukarıda bahsettiğimiz en iyi uygulamaları (tam yol kullanmak, log yönlendirmek, flock ile kilitlemek) paneldeki alanlara da yansıtmanız gerekir.

cPanel/DirectAdmin üzerinde cron job tanımlamayı adım adım anlattığımız otomatik görevler planlama rehberimize göz atarak, panel arayüzündeki ayarları bu makaledeki prensiplerle birleştirebilirsiniz.

2. DCHost Linux VPS ve dedicated sunucularda crontab yaklaşımı

VPS veya dedicated sunucularda root erişiminiz olduğu için, cron yapısını daha esnek tasarlayabilirsiniz. Bizim önerdiğimiz yaklaşım:

• /etc/cron.d/ altında proje bazlı dosyalar oluşturun (örn: project1, project2).
• Her dosyada ilgili kullanıcıyı açıkça yazın: */5 * * * * www-data /usr/local/bin/job.sh
• Uygulama kodunuzun içinde cron.php tarzı bir uç nokta yerine, CLI script kullanın.
• Önemli job’ları version control altında tuttuğunuz scripts/ klasörüne alın.

Böylece cron yapılandırmanız da kodunuz gibi izlenebilir ve taşınabilir olur. DCHost üzerindeki projelerinizde, birden fazla VPS veya dedicated sunucu arasında benzer cron yapılandırmalarını Ansible/Terraform gibi altyapı araçlarıyla dağıtmanız da kolaylaşır.

3. Colocation veya karma mimarilerde cron koordinasyonu

Colocation veya karma (on-prem + DCHost) mimarilerde, tek bir cron tablosu yerine çok sayıda sunucuda dağılmış job set’leriyle uğraşırsınız. Bu durumda:

• Kritik job’lar için merkezi bir izleme/alerting kurun (örneğin her job sonunda “success” metriği yazdırmak).
• Yedekleme ve rapor işlerinin aynı anda aynı kaynakları zorlamamasına dikkat edin (örneğin aynı NAS’a aynı anda 5 sunucudan büyük yedek atmak gibi).
• Gerekirse bazı ağır işleri queue/kuyruk sistemlerine kaydırıp cron’u sadece tetikleyici olarak kullanın.

Sonuç: Sağlam bir cron stratejisi ile altyapıyı güvence altına almak

Linux crontab, doğru kullanıldığında yedekleme, raporlama ve bakım işlerinin omurgasını güvenle taşıyabilen, son derece güçlü ama aynı zamanda sade bir araç. Yanlış kullanıldığında ise sessizce başarısız olan job’lar, eksik yedekler ve kimsenin fark etmediği hatalar anlamına gelebiliyor. Bu rehberde; zamanlama söz diziminden flock ile kilitlemeye, loglama ve hata ayıklamadan, DCHost altyapısında pratik kullanıma kadar geniş bir çerçevede en iyi uygulamaları toplamaya çalıştık.

Şimdi yapabileceğiniz somut adımlar:

• Mevcut cron job’larınızı gözden geçirip, her biri için “log var mı, kilitleme var mı, sorumlu kullanıcı doğru mu?” sorularını sorun.
• Yedekleme tarafında 3-2-1 stratejisine ne kadar yakın olduğunuzu değerlendirin ve eksik halkaları cron ile tamamlayın.
• Kritik job’larınız için izleme ve alarm mekanizmalarını devreye alın.

Eğer DCHost üzerinde paylaşımlı hosting, Linux VPS, dedicated sunucu veya colocation hizmeti kullanıyorsanız ve cron mimarinizi yeniden ele almak istiyorsanız, altyapı ekibimizle birlikte mevcut durumu analiz edip size özel bir plan çıkarabiliriz. Sağlam bir cron stratejisi kurulduğunda, yedek, rapor ve bakım işlerinin “oldu mu, olmadı mı?” stresinden kurtulup, uygulamanızın asıl değer yarattığı alanlara odaklanmak çok daha kolay hale geliyor.