Teknoloji

cPanel ve DirectAdmin’de Otomatik Görevler Planlama: Cron Job ile Yedek, Rapor ve Bakım İşleri

İçindekiler

Cron job ile tekrar eden işleri akıllıca devretmek

Web siteniz büyüdükçe yapılması gereken işler de artıyor: dosya ve veritabanı yedekleri, log temizliği, rapor üretimi, önbellek temizleme, WordPress veya Laravel görevlerinin tetiklenmesi… Bunların hepsini elle yapmak kısa sürede imkânsız hale geliyor. İşte bu noktada cron job devreye giriyor ve sunucunuza “şu işi şu saatte, her gün/hafta/ay kendin yap” deme şansı veriyor.

DCHost altyapısında hem paylaşımlı hosting paketlerinde hem de VPS/dedicated sunucularda en sık gördüğümüz ihtiyaçlardan biri, bu tekrarlı görevlerin cPanel ve DirectAdmin üzerinden doğru şekilde planlanması. Yanlış ayarlanan bir cron job hem performansı etkileyebiliyor hem de yedeklerin eksik veya bozuk olmasına neden olabiliyor. Bu yazıda, pratik örneklerle cPanel ve DirectAdmin’de cron job kullanımını, özellikle yedekleme, rapor ve bakım görevlerini adım adım anlatacağız.

Eğer daha önce cron kullanmadıysanız, gözünüz korkmasın. Mantığı bir kez oturttuktan sonra, birkaç satırlık komutlarla web sitenizin arka plandaki rutinlerini tamamen otomatize edebilirsiniz. Ayrıca yazı içinde, DCHost ekibi olarak günlük hayatta kullandığımız örnek senaryolardan ve dikkat edilmesi gereken güvenlik/performans noktalarından da bahsedeceğim.

Cron job nedir ve temel mantığı nasıl çalışır?

Cron, Linux/Unix tabanlı sistemlerde zamanlanmış görevleri çalıştıran bir servistir. Kullanıcı bazında crontab dosyaları vardır ve bu dosyalarda “hangi komutun, ne zaman” çalışacağını tanımlarsınız. cPanel ve DirectAdmin, bu işi komut satırına inmeden, web arayüzü üzerinden yapmanızı sağlar.

Bir cron satırı kabaca şöyle görünür:

*/5 * * * * /usr/bin/php /home/kullanici/public_html/script.php >/dev/null 2>&1

Bu satır şu anlama gelir: “Her 5 dakikada bir, belirtilen PHP komutunu çalıştır ve çıktı üretme.” Baştaki beş alan zamanlamayı, sondaki kısım ise çalışacak komutu ifade eder.

  • Dakika: 0–59
  • Saat: 0–23
  • Ayın günü: 1–31
  • Ay: 1–12
  • Haftanın günü: 0–7 (0 ve 7 Pazar)

Örneğin:

  • 0 3 * * * → Her gün saat 03:00’de
  • 0 2 * * 1 → Her Pazartesi 02:00’de
  • */15 * * * * → Her 15 dakikada bir

VPS veya dedicated sunucu tarafında, cron alternatifi olarak systemd timer gibi daha modern mekanizmalar da kullanmak mümkün. Bu konuyu daha derine inmek isterseniz, cron mu systemd timer mı rehberimizde iki yaklaşımı teknik açıdan karşılaştırıyoruz.

cPanel’de cron job arayüzü ve pratik kullanım

cPanel’de cron job oluşturmak için genellikle “Cron Jobs” menüsünü kullanırsınız. Arayüz, komut satırında yazmanız gereken crontab satırını sizin yerinize oluşturur.

cPanel’de zamanlama alanlarını doğru doldurmak

cPanel, işinizi kolaylaştırmak için bazı hazır zamanlama seçenekleri sunar:

  • Once Per Minute
  • Once Per Hour
  • Once Per Day
  • Once Per Week
  • Once Per Month

Bu hazır seçenekler, arka planda ilgili alanlara * veya */5 gibi ifadeleri yazar. Fakat zamanla, örneğin “Her gece 02:30’da MySQL yedeği al, her Pazar 04:00’te logları temizle” gibi daha özel planlar isteyeceksiniz. O noktada manuel alan girişi işinize çok yarar.

cPanel’de PHP scriptlerini cron ile çalıştırmak

En sık yapılan hatalardan biri, php komutunun tam yolunu yazmamak. Birçok paylaşımlı hosting ortamında tam yol genellikle /usr/bin/php veya cPanel’in çoklu PHP altyapısında ilgili sürümün yolu olur (örneğin /opt/cpanel/ea-php82/root/usr/bin/php gibi). En güvenli yol, cPanel → PHP Selector/Versiyon bölümünden veya destek ekibimizden doğru yolu teyit etmektir.

Örnek bir cron satırı:

*/10 * * * * /usr/bin/php -q /home/kullanici/public_html/cron/tetikleyici.php >/dev/null 2>&1

Burada:

  • */10 * * * *: Her 10 dakikada bir
  • /usr/bin/php -q: PHP yorumlayıcıyı sessiz modda çalıştır
  • /home/kullanici/public_html/cron/tetikleyici.php: Çalışacak PHP dosyası
  • >/dev/null 2>&1: Çıktıyı ve hatayı çöpe at, e-posta yollama

E-posta bildirimlerini yönetmek

cPanel’de her cron job varsayılan olarak çıktısını e-posta ile gönderebilir. Bu, özellikle ilk kurulum aşamasında hata yakalamak için çok faydalıdır. Fakat yedekleme veya sık çalışan görevler için sürekli e-posta yağmuru istemiyorsanız, komutun sonuna mutlaka şu kısmı ekleyin:

>/dev/null 2>&1

İlk günlerde bu yönlendirmeyi kaldırıp, scriptinizin doğru çalıştığından emin olduktan sonra eklemek genellikle en sağlıklı yaklaşım.

DirectAdmin’de cron job arayüzü

DirectAdmin tarafında mantık tamamen aynıdır; sadece arayüzün yerleşimi farklıdır. Kullanıcı panelinde genellikle “Advanced Features → Cron Jobs” menüsünden erişilir.

DirectAdmin cron ekranında, zamanlama alanları ve komut alanı net şekilde ayrılmıştır. Örneğin, günlük 03:15 yedeği için şu değerleri girebilirsiniz:

  • Minute: 15
  • Hour: 3
  • Day of Month: *
  • Month: *
  • Day of Week: *
  • Command: (çıktıdaki komut)

Komut kısmında yine /usr/bin/php veya sunucunuzda kullanılan doğru PHP yolu ile scriptinizi çalıştırabilirsiniz:

/usr/bin/php -q /home/kullanici/domains/site.com/public_html/cron/gece-yedek.php >/dev/null 2>&1

DirectAdmin’de de, cron çıktılarının e-posta ile gönderilmesi veya sessiz çalışması tamamen komutun sonundaki yönlendirmeye bağlıdır; cPanel ile aynı mantık geçerlidir.

Yedekleme işlerini cron job ile otomatikleştirmek

Cron job kullanmanın en büyük kazancı, yedekleme süreçlerini insan hatasından kurtarmak. DCHost tarafında yaşanan birçok kurtarma senaryosunda gördük ki, elle alınan yedekler çoğu zaman eksik veya güncel değil. Otomatik yedekler ise, doğru planlanmışsa hayat kurtarıyor.

Yedekleme stratejisine yaklaşımınızı planlarken, mutlaka 3-2-1 yedekleme stratejisi rehberimize göz atmanızı tavsiye ederim. Orada genel stratejiyi anlatıyoruz, burada ise cron tarafındaki somut örneklere odaklanacağız.

Home dizini dosya yedeği (tar.gz)

Basit ama etkili bir yöntem, hesabınızın home dizinini sıkıştırıp belirli bir klasöre atmak. Örnek:

0 2 * * * /bin/tar -czf /home/kullanici/backups/home-$(date +%F).tar.gz /home/kullanici/public_html >/dev/null 2>&1

Bu cron satırı her gün saat 02:00’de public_html klasörünüzün sıkıştırılmış yedeğini alır ve /home/kullanici/backups klasörüne home-YYYY-MM-DD.tar.gz formatında kaydeder.

Dikkat edilmesi gereken noktalar:

  • Disk alanı: Yedeklerin hızla şişmesini istemiyorsanız, ek bir cron ile eski yedekleri silmek mantıklı.
  • İzinler: backups klasörünüzün yetkilerini 700 veya 750 tutarak yetkisiz erişimi engelleyin.

MySQL/MariaDB veritabanı yedeği

Veritabanı yedeklerini mysqldump ile almak standart yöntemdir. Cron içinde % karakterinin özel anlamı olduğundan, date kullanırken %F gibi kaçış karakterlerine dikkat etmek gerekir.

30 2 * * * /usr/bin/mysqldump -uDB_KULLANICI -p'SIFRE' DB_ADI | /bin/gzip > /home/kullanici/backups/db-$(date +%F).sql.gz 2>&1

Burada:

  • Her gün 02:30’da ilgili veritabanı yedeği alınır.
  • gzip ile sıkıştırılarak disk alanı tasarrufu sağlanır.

Daha gelişmiş senaryolarda, veritabanı parolasını komut içinde yazmak yerine ~/.my.cnf dosyasında saklayıp komutta parolayı hiç göstermemek güvenlik açısından daha doğrudur.

Eski yedekleri otomatik silmek

Yedek almak kadar, eski yedekleri düzenli olarak temizlemek de önemlidir. Aksi halde disk alanı dolduğunda yeni yedekler başarısız olur.

0 4 * * * /usr/bin/find /home/kullanici/backups -type f -mtime +14 -delete >/dev/null 2>&1

Bu cron satırı, /home/kullanici/backups içindeki 14 günden daha eski dosyaları her gün saat 04:00’te siler. Süreyi kendi yedek saklama politikanıza göre (örneğin +7, +30) değiştirebilirsiniz. Yedek saklama sürelerinin KVKK/GDPR gibi mevzuatlarla da ilişkili olabileceğini unutmayın; detaylı yaklaşım için log saklama süreleri rehberimize göz atabilirsiniz.

Uzak depolamaya (rsync/rclone) otomatik yedek

VPS veya dedicated sunucu kullanıyorsanız, cron ile yedekleri uzak bir depolamaya (örneğin S3 uyumlu bir nesne depolama veya farklı bir sunucu) itmek oldukça yaygın bir pratiktir. Örneğin rclone kullanıyorsanız:

0 3 * * * /usr/bin/rclone sync /home/kullanici/backups remote-yedek:projeler/site-1 --delete-before >/dev/null 2>&1

Bu komut, yerel backups klasörünüzü uzaktaki bir depoya senkronize eder. Böylece 3-2-1 stratejisindeki “farklı ortamda yedek” ayağını da otomatik hale getirmiş olursunuz. Daha gelişmiş şifreleme ve sürümleme senaryoları için S3 uyumlu uzak yedekleme rehberimiz size iyi bir çerçeve sunacaktır.

Rapor, istatistik ve log işlemlerini cron ile otomatize etmek

Yedeklerin yanında, cron job’ları ile raporlama ve log yönetimi tarafını da otomatikleştirebilirsiniz. Özellikle e-ticaret sitelerinde sepet/ödeme adımlarını takip eden scriptleri belirli aralıklarla çalıştırmak, dönüşüm hunisini izlemenize yardımcı olur. Bu konuda sunucu logları ve alarm kuralları ile sepet/ödeme izleme yazımızı mutlaka okumanızı öneririm.

Disk kullanım raporu göndermek

Küçük ama etkili bir örnek: Disk dolmadan önce haberdar olmak için günlük disk kullanım raporu gönderebilirsiniz.

0 8 * * * /usr/bin/du -sh /home/kullanici/public_html | /usr/bin/mail -s "Gunluk disk kullanimi" [email protected]

Bu örnekte cron, her sabah 08:00’de sitenizin disk kullanımını hesaplayıp e-posta ile gönderir. Mail komutunun yolu ve yapılandırması sunucuya göre değişebileceği için, VPS/dedicated ortamında önce test etmeniz, paylaşımlı hosting’de ise destek ekibimizden bilgi almanız faydalı olur.

Eski log dosyalarını sıkıştırma ve silme

Log dosyaları zamanla ciddi boyutlara ulaşır. Onları periyodik olarak sıkıştırmak ve eskilerini silmek sunucunuzu nefes aldırır:

0 1 * * * /usr/bin/find /home/kullanici/logs -type f -name "*.log" -mtime +1 -exec gzip {} ; >/dev/null 2>&1
0 1 * * 0 /usr/bin/find /home/kullanici/logs -type f -name "*.log.gz" -mtime +30 -delete >/dev/null 2>&1

İlk satır, 1 günden eski logları sıkıştırır; ikinci satır ise 30 günden eski sıkıştırılmış logları siler. Bu süreleri, hem yasal zorunluluklara hem de ihtiyaçlarınıza göre ayarlamanız gerekir.

Özel raporlama scriptlerini çalıştırmak

Örneğin, günlük satış raporunu CSV olarak üreten bir PHP scriptiniz olduğunu varsayalım. Bu scripti her gece çalıştırıp sonucu bir klasöre atabilir veya doğrudan e-posta ile gönderebilirsiniz:

15 1 * * * /usr/bin/php -q /home/kullanici/raporlar/gunluk-satis-raporu.php >/home/kullanici/raporlar/logs/gunluk-satis-$(date +%F).log 2>&1

Bu sayede, rapor üretimi tamamen otomatik hale gelir ve sabah ofise geldiğinizde raporunuz hazır olur.

Bakım işleri: önbellek temizleme, uygulama cron’ları ve sağlık kontrolleri

Cron job’lar, sadece yedek ve rapor için değil, uygulama düzeyindeki bakım işlerinde de kritik rol oynar. WordPress, Laravel, Magento gibi sistemler belirli görevleri kendi “pseudo-cron” mekanizmaları ile tetikler; ancak gerçek cron job kullanmak çoğu zaman daha performanslı ve güvenilirdir.

WordPress’te wp-cron yerine gerçek cron kullanmak

WordPress, her sayfa isteğinde wp-cron.php dosyasını çalıştırmaya çalışır. Trafiğiniz arttığında bu ciddi performans sorununa dönüşebilir. Bu yüzden:

  1. wp-config.php içinde DISABLE_WP_CRON sabitini tanımlayıp wp-cron’u devre dışı bırakmak,
  2. Ardından gerçek bir cron job ile wp-cron.php dosyasını belirli aralıklarla tetiklemek

çok daha sağlıklı bir yaklaşımdır.

*/10 * * * * /usr/bin/php -q /home/kullanici/public_html/wp-cron.php >/dev/null 2>&1

Bu konuyu adım adım görmek için, WordPress’te wp-cron devre dışı bırakma ve gerçek cron kurulum rehberimize göz atabilirsiniz.

Laravel ve benzeri framework’lerde schedule:run

Laravel gibi framework’lerde iş zamanlamasını uygulama içinden yönetirsiniz ve tek bir cron satırıyla tüm planlı görevleri tetiklersiniz:

* * * * * /usr/bin/php /home/kullanici/proje/artisan schedule:run >/dev/null 2>&1

Bu cron işi her dakika çalışır, ancak hangi işlerin ne zaman koşacağı tamamen Laravel’in app/Console/Kernel.php içindeki tanımlamalara göre belirlenir. Bu yöntem, çok sayıda farklı işi tek bir cron satırıyla yönetmenize olanak tanır.

Önbellek ve geçici dosyaları temizlemek

Özellikle büyük sitelerde, önbellek ve geçici dosyalar zamanla yüzlerce MB’ye hatta GB’lara ulaşabilir. Bu dosyaları periyodik olarak silmek performansa ve disk alanına olumlu yansır.

0 5 * * * /usr/bin/find /home/kullanici/public_html/storage/framework/cache -type f -mtime +2 -delete >/dev/null 2>&1

Benzer şekilde, WordPress için belirli cache eklentilerinin komut satırı arayüzü varsa, bunları da cron ile tetikleyebilirsiniz. Genel bakım işlerini yıllık bazda planlamak için küçük işletmeler için yıllık web sitesi bakım takvimi rehberimiz size güzel bir iskelet sunar.

Basit sağlık kontrolleri (health check)

Profesyonel izleme sistemleri kadar kapsamlı olmasa da, cron ile temel sağlık kontrolleri yapabilirsiniz. Örneğin sitenize curl ile istek atıp, hata durumunda kısa bir e-posta gönderen küçük bir script çalıştırmak mümkün.

*/5 * * * * /usr/bin/php -q /home/kullanici/monitoring/health-check.php >/dev/null 2>&1

Yoğun trafik alan veya kritik sistemler için elbette gelişmiş izleme/alerting sistemleri öneriyoruz; fakat basit senaryolarda cron tabanlı health check’ler de pek çok sorunu erken aşamada yakalamanıza yardımcı olur.

cPanel ve DirectAdmin’de cron job güvenliği ve en iyi pratikler

Cron job’lar çok güçlü araçlar; dolayısıyla yanlış kullanıldığında da ciddi sorunlara yol açabilir. DCHost tarafında sıkça karşılaştığımız hataları ve önerileri özetleyelim.

1. Tam yol kullanın (binary ve scriptler için)

Cron ortamında PATH değişkeni genellikle sınırlıdır. Bu yüzden:

  • php yerine /usr/bin/php
  • mysqldump yerine /usr/bin/mysqldump
  • tar yerine /bin/tar

gibi tam yolları kullanmanız, “command not found” hatalarını engeller.

2. Scriptleri mümkünse public_html dışına taşıyın

Yedekleme, raporlama, log temizleme gibi scriptlerinizin tarayıcıdan direkt erişilebilir olmaması önemli bir güvenlik tedbiridir. Bunları:

  • /home/kullanici/scripts
  • /home/kullanici/cron

gibi, public_html’in bir üstünde yer alan klasörlere taşıyın ve cron’da o yolları kullanın. Böylece dışarıdan doğrudan URL ile tetiklenemezler.

3. Parola ve hassas bilgileri komut satırına yazmayın

Özellikle mysqldump veya uzak depolama araçlarında, kullanıcı adı/parola bilgilerini direkt komut içinde yazmak hem loglara sızabilir hem de süreç listelerinde (ps) görünebilir. Bunun yerine:

  • MySQL için ~/.my.cnf içinde [client] bölümünde kullanıcı/parola tutmak,
  • Uzak depolama araçları için konfigürasyon dosyası veya environment değişkenleri kullanmak,

daha güvenli bir yaklaşımdır.

4. Çalışma sıklığını abartmayın

Her şeyi “her dakika” çalıştırmak cazip gelebilir ama bu hem hesabınızın kaynak limitlerini zorlar hem de veritabanı/sunucu üzerinde gereksiz yük oluşturur. Önerimiz:

  • Kritik uygulama cron’ları: 1–5 dakikada bir
  • Yedekleme işleri: Günlük/haftalık (yoğunluğa göre)
  • Temizlik işleri: Günlük/haftalık

Daha ileri düzey iş yükleriniz varsa, cron yapılandırmasını DCHost teknik ekibimizle birlikte gözden geçirmek iyi bir yatırım olur.

5. Önce manuel test, sonra cron’a ekleme

Her yeni komutu önce SSH veya terminal üzerinden elle çalıştırın. Çalıştığından emin olmadan cron’a eklemeyin. Örneğin:

/usr/bin/php -q /home/kullanici/cron/yedek.php

Komut hatasız çalışıyor, log veya çıktı beklentiniz doğruysa ancak o zaman ilgili satırı cron’a ekleyin. Bu basit alışkanlık, birçok “cron çalışıyor ama hiçbir şey olmuyor” vakasını en baştan engeller.

DCHost altyapısında cron job senaryolarını projeye göre kurgulamak

DCHost’ta ister paylaşımlı hosting, ister NVMe VPS, ister dedicated sunucu veya colocation kullanın; cron job stratejisini projeye göre şekillendirmek uzun vadede size ciddi rahatlık sağlar.

Küçük kurumsal/site-vitrin projeleri

Basit içerik siteleri için genellikle şu akış yeterli olur:

  • Günlük dosya ve veritabanı yedeği (gece saatlerinde)
  • Haftalık log temizliği ve sıkıştırma
  • WordPress kullanıyorsanız gerçek cron ile wp-cron.php tetikleme

Bu tip projelerde fazla karmaşaya girmeden, cPanel/DirectAdmin arayüzünden birkaç satırlık cron eklemek tüm bakım rutininizi otomatikleştirir. Yıllık planlama açısından yıllık bakım takvimi rehberimiz de yol gösterici olacaktır.

E-ticaret ve yüksek trafikli WordPress/Laravel projeleri

Daha yoğun projelerde ise genellikle şu yapı öne çıkıyor:

  • Uygulama görevleri için dakikalık/5 dakikalık cron’lar (sipariş durumu, stok güncelleme vb.)
  • Gece saatlerinde incremental veya tam yedekler
  • Ayrı cron job’larla veritabanı yedeği ve dosya yedeğinin ayrılması
  • Uzak depoya (S3 uyumlu storage veya ikinci sunucuya) otomatik replikasyon

WordPress ağırlıklı projeler için WordPress yedekleme stratejileri rehberimizde paylaşımlı hosting ve VPS’te otomatik yedek planlarını detaylıca anlattık. Bu rehberle birlikte elinizdeki cron örneklerini birleştirirseniz, oldukça sağlam bir otomasyon iskeleti kurabilirsiniz.

VPS, dedicated ve colocation senaryoları

Kendi VPS’iniz, dedicated sunucunuz veya DCHost veri merkezinde barındırdığınız fiziksel sunucunuz (colocation) varsa, cron konusunda neredeyse sınırsız özgürlüğe sahipsiniz:

  • Sunucu bazlı cron’lar ile sistem güncellemeleri ve paket yükseltmelerini planlamak
  • Logları merkezi bir sisteme (örneğin Loki, Elasticsearch vb.) periyodik olarak göndermek
  • Yedekleri farklı veri merkezlerine replike etmek

Daha kompleks ortamlarda, cron ile systemd timer, izleme/alerting ve yedekleme çözümlerini bir arada ele almak en doğrusu. Burada size özel mimari önerisi isterseniz, DCHost teknik ekibi olarak proje detaylarınıza göre birlikte bir plan çıkarmaktan memnun oluruz.

Sonuç: Cron job ile “unut gitsin” konforuna geçmek

cPanel ve DirectAdmin’de cron job kullanmak, ilk bakışta birkaç karmaşık alan ve komut gibi görünebilir. Ancak mantığı kavradığınızda, aslında yaptığınız tek şey şu: “Bu komutu, şu sıklıkla, şu saatte çalıştır.” Geriye kalan her şeyi sunucu sizin yerinize yapıyor. Yedeklerinizin her gece otomatik alınması, loglarınızın temizlenmesi, WordPress veya Laravel görevlerinizin dakikası şaşmadan işlemesi, hepsi birkaç satırlık doğru yazılmış cron satırlarına bakıyor.

Bu yazıda, DCHost altyapısında sıkça kullandığımız yedek, rapor ve bakım cron örneklerini hem cPanel hem de DirectAdmin tarafında nasıl planlayabileceğinizi anlattık. Bir sonraki adım, kendi sitenizin ihtiyaçlarını netleştirip, buradaki örnekleri kendinize uyarlamak. İsterseniz, mevcut hosting paketinize veya VPS/dedicated/colocation altyapınıza en uygun cron stratejisini, DCHost destek ekibimizle birlikte tasarlayabilir, 7/24 izlenen bir yapıda gönül rahatlığıyla yayın yapabilirsiniz.

Özetle: Tekrarlı işleri insanlara bırakmak hata riskini büyütür, cron job ise tam tersine işleri sessiz ve düzenli şekilde rayına oturtur. Doğru kurduğunuzda, siz projelerinizi büyütmeye odaklanırken, sunucunuz arka planda sizin için çalışmaya devam eder.

Sıkça Sorulan Sorular

Cron job, Linux tabanlı sistemlerde belirli zaman aralıklarında otomatik çalıştırılan komut veya script’lere verilen isimdir. cPanel ve DirectAdmin, terminale inmeden bu işleri tanımlayabilmeniz için grafik bir arayüz sunar. Siz, neyin ne zaman çalışacağını belirlersiniz; panel de arka planda ilgili crontab satırını oluşturur. Örneğin her gece 02:00’de dosya yedeği almak, her 10 dakikada bir WordPress wp-cron’u tetiklemek veya haftada bir eski log dosyalarını silmek gibi işler cron ile otomatize edilir. Böylece manuel müdahaleye ihtiyaç kalmadan, sunucunuz sizin yerinize düzenli bakım yapar.

En kritik olanlar, kesinlikle veritabanı ve dosya yedekleridir. Bunların elle alınması, özellikle yoğun dönemlerde unutulmaya çok açıktır. Günlük tam veya incremental yedekler, haftalık/aylık arşivler mutlaka cron ile planlanmalıdır. Bunun yanında log sıkıştırma ve temizlik, geçici dosyaların silinmesi, WordPress/Laravel gibi uygulamaların kendi cron görevlerinin tetiklenmesi ve disk kullanım raporlarının gönderilmesi de otomatikleştirilmesi gereken işler arasındadır. DCHost tarafında, bu tür görevleri düzgün planlayan kullanıcıların, olası sorunlarda hem kurtarma sürecini hem de kök sebep analizini çok daha hızlı yaptığını pratikte görüyoruz.

Evet, özellikle çok sık çalışan ve ağır işlemler yapan cron job’lar performansı olumsuz etkileyebilir. Örneğin her dakikada bir tam veritabanı yedeği almaya çalışan bir cron, hem CPU’yu hem de disk I/O’yu gereksiz yorar. Benzer şekilde, yanlış yazılmış bir script’in her çalıştığında hata verip yoğun log üretmesi de disk alanını ve inode sayısını hızla tüketebilir. Bu nedenle cron görevlerini tanımlarken çalışma sıklığını makul tutmak, önce komutları manuel test etmek ve gerekiyorsa çıktıları /dev/null’a yönlendirmek önemli. Tereddüt ettiğiniz senaryolarda DCHost teknik ekibinden konfigürasyonu birlikte gözden geçirmelerini istemek iyi bir yaklaşımdır.

WordPress varsayılan olarak her sayfa isteğinde wp-cron.php’yi tetiklemeye çalışır. Trafik arttıkça bu, gereksiz PHP süreçleri ve ek sorgular anlamına gelir; özellikle yoğun e-ticaret sitelerinde hissedilir yavaşlamalara yol açabilir. Gerçek cron job kullanarak, wp-cron’u sadece belirli aralıklarla (örneğin her 5 veya 10 dakikada bir) çalıştırırsınız. Böylece görevler düzenli işler ama her sayfa isteği için ekstra yük oluşmaz. Ayrıca cron çıktısını ve hatalarını log’a yönlendirerek sorunları daha kolay teşhis edebilirsiniz. Adım adım kurulum için, DCHost blogumuzdaki WordPress’te wp-cron devre dışı bırakma rehberine göz atmanız faydalı olacaktır.