Linux Crontab ile Yedek, Rapor ve Bakım Planlama

Linux crontab ile otomasyonun omurgasını kurmak

Linux projelerinde tekrarlayan işleri belirlemek, otomasyon planının ilk adımıdır: “Hangi işleri otomatikleştirdik ve hangileri hâlâ elle yapılıyor?” Yedek alma, log temizleme, rapor üretme, disk kontrolü ve sertifika yenileme gibi işler elle yürütülebilir; ancak görev sayısı arttıkça manuel süreçler hata riskini ve zaman maliyetini artırır. Linux crontab, bu işleri zamanlamak için temel araçlardan biridir. Güvenilir bir otomasyon için zamanlamanın yanında doğru yetkiler, hata denetimi ve izleme de gerekir.

Bu rehberde, yedekleme, raporlama ve bakım görevlerini planlamak için pratik 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 bile her görevi bu hesapla çalıştırmak zorunda değilsiniz; görevin ihtiyaç duyduğu en düşük yetkileri sağlayan hesabı seçin ve gerektiğinde ayrı bir görev kullanıcısı kullanın.

Cron zamanlama söz dizimini doğru anlamak

Kullanıcı crontab’inde satırın temel yapısı şöyledir. /etc/crontab ve /etc/cron.d/ dosyalarında ise beş zaman alanından sonra, komuttan önce çalıştıracak kullanıcı adı da yazılır:

* * * * * 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ı: Her iki alan da * yerine belirli günlerle sınırlandırılmışsa, yaygın cron uygulamalarında ikisinden birinin eşleşmesi yeterlidir. Çoğu kişi “ve” gibi davranacağını varsayıp yanlış zamanlama yapar.
• Adım, aralık ve liste kullanımı: Dakika alanında */10 her 10 dakikayı, 1-5 1–5. dakikaları, 1,15,30 ise belirtilen dakikaları seçer.
• 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. Cron’a bir mysqldump satırı yazmak, tek başına eksiksiz bir yedekleme planı oluşturmaz. 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. Aşağıdaki örnekten önce yalnızca bu yedekler için ayrılmış dizini oluşturup erişimini yetkili hesaplarla sınırlayın. Görev hesabının veritabanı kimlik doğrulamasını, script’i çalıştırma ve yedek, kilit, log yollarına yazma izinlerini hazırlayın. Yeni yedek dosyalarının izinlerini de sınırlandırın. Başarısız çalışmadan kalan çıktıları geçerli yedek saymayın; uzak kopyalama ve eski yedekleri silme adımlarını başarılı yedek üretimine bağlayın.

Örnekteki mysqldump –single-transaction seçeneği, tüm tablo motorları için tutarlılık garantisi değildir. MySQL 8.0 belgesine göre tutarlı anlık görüntü InnoDB tablolarıyla sınırlıdır; MyISAM ve MEMORY gibi işlemsel olmayan tablolar yedek sırasında değişebilir. Örneği InnoDB tabloları için değerlendirin; karma motorlu veritabanlarında diğer tabloların tutarlılığını sağlayacak ayrı bir yöntem planlayın. Yedek sürerken ilgili tablolarda ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE ve TRUNCATE TABLE işlemlerini engelleyecek şekilde dağıtım ve bakım süreçlerini koordine edin; bu işlemler hatalı içerik veya başarısız yedek üretebilir. Kullandığınız MySQL sürümünün yetki ve GTID gereksinimlerini de kontrol edin.

Bu script şifreleme veya uzak kopyalama yapmaz; sıkıştırma şifreleme yerine geçmez. Saklama ve aktarım için şifreleme ile anahtar erişimini ayrıca planlayın. Yedeklerin kullanılabilirliğini düzenli olarak ayrı bir ortamda geri yükleme yaparak denetleyin; dosyanın oluşması veya komutun başarılı bitmesi tek başına yeterli değildir.

#!/usr/bin/env bash
# /usr/local/bin/backup-daily.sh
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"

# Son değişikliğinin üzerinden en az 8 tam gün geçmiş dosyaları 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ı kilit dosyasını kullanan çağrılar arasında çakışmayı önler. Örnekteki -n seçeneği, kilit alınamazsa beklemek yerine çağrının çalıştırılmadan çıkmasına yol açar; bu nedenle atlanan çalışmaları da izleyin. Aynı işi farklı yollardan tetikliyorsanız ortak kilit kullanın.
• Log yönlendirme: Çıktıyı bir log dosyasına yazıp hata ayıklamayı kolaylaştırır. Bu dosyalar için de erişim sınırı ve log döndürme politikası belirleyin.
• set -euo pipefail: Birçok komut, tanımsız değişken ve boru hattı hatasında script’in durmasına yardımcı olur; tek başına tüm hataların yakalanacağını veya yedeğin geçerli olduğunu garanti etmez.

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

Tek sunucudaki tek yedek kopyası, sunucunun tümüyle kaybına karşı yeterli koruma sağlamaz. Sağlam bir yaklaşım için 3-2-1 stratejisini öneriyoruz: canlı veri dâhil toplam 3 kopya, 2 farklı ortam, en az 1 kopya farklı lokasyonda. Ayrı disk veya volume kullanımı, tek başına farklı ortam şartının sağlandığını göstermez. Aşağıdaki üç yedek adımını birlikte uygularsanız canlı veriyle toplam dört kopya oluşur; bu, üç kopyalık asgari hedefi aşar:

1. Yerel sunucuda günlük/veritabanı yedeği (disk üzerinde).
2. Aynı veri merkezinde farklı disk/volume üzerine ikinci kopya.
3. Farklı lokasyondaki bir depoya üçüncü yedek kopya (off-site); object storage seçiliyorsa verinin tutulduğu lokasyonu doğrulayın.

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. Birbirine bağımlı adımları, önceki adımın başarısını denetleyen bir script içinde sıralayın. Ayrı cron görevlerini farklı saatlere koymak, önceki işin tamamlandığını veya başarılı olduğunu garanti etmez.

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

Bir VPS veya dedicated sunucu için veriyi farklı lokasyondaki object storage’a aktarmak, uzak kopya oluşturma seçeneklerinden biridir. Bunun için sık kullanılan araçlardan bazıları rclone ve restic. Aşağıdaki rclone sync örneği bağımsız sürüm geçmişi oluşturan bir arşiv değil, kaynak dizini uzak hedefe aynalayan bir iştir: yerelde silinen dosyalar sonraki başarılı eşitlemede uzaktan da silinebilir. Yerel saklama temizliği bu nedenle uzak geçmişi de kısaltabilir. Önce görev hesabında rclone config ile s3 adlı bağlantıyı, gerçek sağlayıcıyı, gerekiyorsa uç noktayı ve gerekli kimlik bilgilerini hazırlayın; hedef bucket ve dizini doğrulayın. Aynı kaynak/hedef üzerinde --dry-run ile değişiklikleri inceleyin. Uzakta kaynakta bulunmayan dosyalar da tutulacaksa rclone copy ve ayrı bir uzak saklama politikası değerlendirin; bu seçenek tek başına değişmezlik veya sürüm geçmişi sağlamaz. Bu ayrı saatli eşitlemeyi ancak yerel yedeğin tamamlanıp doğrulandığı denetleniyorsa kullanın; saat farkı bu bağımlılığı kurmaz. Örnek günlük aynalama kaydı:

# 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. Aşağıdaki düşük öncelikli cron kaydı, önceki günlük yedek kaydının alternatifidir; ikisini birlikte eklemeyin. Ö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ğlayabilirsiniz. Aşağıdaki Laravel kaydı raporu kendisi üretmez veya göndermez; her dakika uygulamanın zamanlayıcısını çağırır. Rapor görevini, haftalık ya da aylık çalışma zamanını ve e-posta gönderimini uygulamada ayrıca tanımlayın. PHP ve uygulama yollarını, görev hesabının izinlerini ve uygulamanın ihtiyaç duyduğu çalışma dizinini doğrulayın.

# Laravel artisan schedule:run örneği
* * * * * /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.

MAILTO=raporlar@example.com
0 7 * * 1 /opt/scripts/weekly_report.sh

Bu yaklaşımı yöneticilere veya ekip arkadaşlarına düzenli operasyon raporu göndermek için kullanabilirsiniz; ancak cron’un çıktı e-postası ile uygulamanın hazırladığı rapor e-postası farklıdır. Yukarıdaki PDF örneği dosya üretimini gösterir, dosyayı otomatik olarak e-postaya eklemez. Ekli rapor göndermek için script içinde ayrıca gönderim adımı gerekir. Çıktıyı tamamen log dosyasına yönlendirdiğiniz işlerde cron’un e-postasına hata bildirimi olarak güvenmeyin; gönderim ve alarm yolunu ayrıca doğrulayın.

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

Log dosyaları, önlem alınmazsa aylar içinde diski doldurabilir.

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. Aşağıdaki örnek dosya adına göre filtreleme yapmaz; hedef klasörde yalnızca silinmesi güvenli, artık yazılmayan arşiv log’ları bulunmalıdır. Zamanlamadan önce silinecek dosya listesini inceleyin; aktif log’lar için logrotate kullanın.

# /var/log/app içinde en az 15 tam gündür değiştirilmemiş dosyaları 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

Framework’ler ve CMS eklentileri (Laravel, Symfony, WordPress eklentileri vb.) cache klasörlerinde dosya biriktirebilir. Bunların bir kısmı otomatik temizlenir, bir kısmı ise ayrıca temizlik gerektirir. Aşağıdaki örneği yalnızca uygulamanın artık kullanmadığı geçici dosyalar için uygulayın: dosyanın eski olması, kullanımda olmadığı anlamına gelmez. Hedef klasörü ve silinecek dosyaları önce kontrol edin.

# En az 4 tam gündür değiştirilmemiş geçici dosyaları 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 bir seçenek olabilir. 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 ve index bakım işlerini cron’a bağlayabilirsiniz. Ancak bakım türünü ve sıklığını gerçek ihtiyaca göre seçin. Aşağıdaki tüm veritabanlarını kapsayan gece zamanlaması genel bir öneri değildir; üretimde kullanmadan önce işlemin süresini, yük ve kilitlenme etkilerini değerlendirin ve geri yüklenebilir bir yedeğiniz olduğundan emin olun. MySQL 8.4 belgesinde --optimize, OPTIMIZE TABLE işlemini seçer; --analyze ayrı bir analiz seçeneğidir. --all-databases kapsamı varsayılan olarak INFORMATION_SCHEMA ve performance_schema dışındaki veritabanlarıdır. Örneği yalnız sürümünüzün ve tablo motorlarının desteklediği bakım türünü belirledikten sonra uyarlayın; yalnızca istatistik güncelleme işi olarak değerlendirmeyin.

# Örnek saat 04:00: tüm kapsanan tablolara OPTIMIZE TABLE uygular
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 sertifikalarının yenilenmesini ACME istemcileriyle cron’a bağlayabilirsiniz. Önce mevcut cron ve timer kayıtlarını kontrol edin; aynı yenileme işini ikinci kez zamanlamayın. Aşağıdaki örnek, Certbot’un belirtilen yolda kurulu ve yenileme yapılandırmasının hazır olduğunu, görev kullanıcısının gerekli dosyalara erişebildiğini ve log dosyasına yazabildiğini varsayar:

# 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, bir eşik aşımı veya servis kesintisi tespit edildiğinde 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. Örnekteki shell yolunun mevcut olduğundan emin olun ve sunucuda kurulu bir locale seçin:

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 için yalnızca gereken yetkilere sahip bir hesap seçin; ilgili uygulama kullanıcısı (www-data, deploy vb.) veya ayrı bir görev kullanıcısı uygun olabilir. Web servisinin hesabını otomatik olarak tercih etmeyin.
• Sistem işleri (apt update, log temizliği vb.) için gereken yetkiyi ayrı değerlendirin; root yalnızca gerekli olduğunda kullanılsın, diğer işler uygun yetkili özel hesaplarda çalışsı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. Bu örnek her çalışmada önceki dosya içeriğinin üzerine yazar.
• Veya ikisini tek dosyada toplamak için >> job.log 2>&1 kullanabilirsiniz.
• Hata ayıklarken script’i önce elle çalıştırın; Bash script’lerinde bash -x script.sh ile çalıştırılan komutları izleyebilirsiniz. Bu işlem script’i yeniden çalıştırır ve genişletilmiş komutlarda parola veya token gösterebilir; yan etkileri ve iz çıktısının erişim izinlerini gözetin.

Cron log’ları dağıtıma göre genellikle /var/log/cron, /var/log/syslog veya /var/log/messages içinde tutulur. Hata araştırırken bu kayıtları, görevin kendi çıktı ve hata log’larıyla birlikte inceleyin.

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

Görev sayısı arttıkça, “cron job çalıştı mı?” sorusunu yalnızca manuel log takibiyle cevaplamak zorlaşabilir. Özellikle kritik yedek ve bakım işlerinde başarı durumu, süre ve son başarılı çalışma zamanı gibi ölçümleri izleme ve alarm sistemlerine aktarmak yararlıdır. Prometheus ve Grafana gibi araçlarla izleme için yalnızca komut çıktısını saklamak değil, bu ölçümleri toplamak ve alarm koşullarını tanımlamak gerekir.

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?

systemd kullanan Linux sistemlerinde systemd timer, cron’a alternatif bir zamanlama seçeneğidir. İkisi de zamanlanmış görev çalıştırabilir; seçimde aşağıdaki yönetim farklarını değerlendirin:

• 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, örnek senaryolar üzerinden hangi durumda hangi yaklaşımı seçebileceğinizi bulabilirsiniz. Özellikle çok sayıda sunucu yönetiyorsanız, bu ayrım görevlerin yönetimini kolaylaştırabilir.

Hosting modeline göre crontab planlama önerileri

Cron job’larının nasıl ve nereden yönetileceği, kullandığınız hosting modeline göre de değişiyor. Paylaşımlı hosting, VPS, dedicated ve colocation modellerinde cron planlaması için bazı pratik öneriler:

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

cPanel veya DirectAdmin gibi panellerde cron yönetimi web arayüzünden yapılabilir; seçtiğiniz planda bu özelliğin açık olduğunu, izin verilen çalışma sıklığını ve kaynak sınırlarını doğrulayın. Tam komut yollarını ve yazılabilir log konumlarını belirleyin. Kilitleme için flock kullanmayı planlıyorsanız aracın hesabınızdan çalıştırılabildiğini kontrol edin; root yetkisi gerektiren örnek yolları panel ortamına doğrudan taşımayın.

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. Linux VPS ve dedicated sunucularda crontab yaklaşımı

VPS veya dedicated sunucularda root erişiminiz varsa, 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.

Cron yapılandırma dosyalarını da sürüm kontrolüne alarak değişiklikleri izleyebilirsiniz. Birden fazla VPS veya dedicated sunucuya dağıtım yaparken, her sunucudaki kullanıcı, dosya yolu ve bağımlılıkların yapılandırmayla uyumlu olduğunu doğrulayın.

3. Colocation veya karma mimarilerde cron koordinasyonu

Colocation veya karma (on-prem + barındırma sağlayıcısı) mimarilerde, çok sayıda sunucuya dağılmış job set’lerini yönetmeniz gerekebilir. Bu durumda:

• Kritik job’lar için merkezi bir izleme/alerting kurun; başarı metriğini yalnızca iş başarıyla tamamlandığında kaydedin. Hata durumları ve beklenen sürede gelmeyen başarı sinyalleri için alarm tanımlayın.
• 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ç: İzlenebilir ve sürdürülebilir bir cron stratejisi

Linux crontab, yedekleme, raporlama ve bakım işlerini zamanlamak için sade bir araçtır. Güvenilir sonuçlar ise görevlerin doğru tasarlanmasına, uygun yetkilere, geçerli yedeklere ve hata takibine bağlıdır. Bu rehberde zamanlama söz dizimi, flock ile kilitleme, loglama, hata ayıklama ve hosting modeline göre planlama ilkelerini bir araya getirdik. Örnekleri kendi ortamınıza uyarlarken önkoşulları ve birbirine bağımlı adımları birlikte değerlendirin.

Ş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; eksik kopya ve depolama hedeflerini planlayıp yedekleme ve aktarım işlerini cron ile zamanlayın.
• Kritik job’larınız için izleme ve alarm mekanizmalarını devreye alın.

Cron mimarinizi yeniden ele alırken, seçtiğiniz hizmet planındaki cron erişimini ve yetki sınırlarını belirleyip mevcut görevler, çalışma süreleri ve kaynak ihtiyaçları üzerinden bir plan oluşturun. Zamanlama kadar son başarılı çalışma zamanını, hata bildirimlerini ve geri yükleme sonuçlarını da takip edin. Böylece otomasyonun yalnızca tanımlı olduğunu değil, beklenen işi yerine getirdiğini de değerlendirebilirsiniz.