Cron Job ile Otomatik Veritabanı Yedekleme MySQL, PostgreSQL, MongoDB

Veritabanı yedekleme, üretim ortamlarında çalışan sunucu sistemlerinin en hayati güvenlik kalkanıdır. Donanım arızaları, yanlışlıkla çalıştırılan yıkıcı SQL sorguları, başarısız yazılım dağıtımları veya fidye yazılımı saldırıları karşısında elinizdeki en güncel ve sağlam yedek, felaketten kurtulmanın tek garantisidir. Ancak bu süreci manuel yürütmek insan hatasına ve unutkanlığa davetiye çıkarır. Bir cron job aracılığıyla kurulan otomatik yedekleme mekanizması, gecenin en sakin saatinde verinizi sessizce arşivler ve güvenli depolama alanlarına aktarır.

Bu rehberde, Linux işletim sistemleri üzerinde çalışan popüler ilişkisel ve NoSQL veritabanlarının (MySQL, MariaDB, PostgreSQL ve MongoDB) otomatik yedekleme mimarisini sıfırdan kuracağız. Parola güvenliği için yapılandırma dosyalarının hazırlanmasından tablo kilitlenmelerini önlemeye, disk dolmasını engelleyen rotasyon stratejilerinden AWS S3 bulut senkronizasyonuna kadar tüm adımları gerçek kod örnekleriyle inceleyeceğiz.

Hedef kitle: Kendi sunucusunu yöneten sistem yöneticileri, backend geliştiricileri ve DevOps mühendisleridir. Genel sistem görevleri için ayrıca Linux cron job kılavuzumuza göz atabilirsiniz.

Veritabanı Yedekleme Stratejileri: Tam Yedek, Rotasyon ve Güvenlik

Üretimde güvenilir yedek; gece çalışan bir dump, en az bir uzak kopya (ör. S3/R2), yaşa göre rotasyon ve periyodik geri yükleme testinden oluşur. Yalnızca yerel diske yazılan, hiç restore edilmemiş arşiv felaket anında işe yaramayabilir.

Rastgele zamanlanmış bir yedekleme scripti kurmak tek başına yeterli değildir. Sağlam bir altyapı, sektör standardı olan 3-2-1 Yedekleme Kuralı üzerine inşa edilmelidir. Bu kurala göre verilerinizin en az 3 farklı kopyası bulunmalı, bu kopyalar 2 farklı depolama ortamında (örneğin yerel sunucu diski ve harici NAS/ağ depolama) saklanmalı ve en az 1 kopya mutlaka farklı bir coğrafi lokasyonda (AWS S3, Cloudflare R2 vb.) barındırılmalıdır. Sunucunuzun veri merkezi düzeyinde yangın veya ağ kesintisi yaşaması durumunda yerel kopyaların da erişilemez hale geleceği unutulmamalıdır.

İkinci temel unsur yedekleme türüdür. Mantıksal yedekler (Logical Backup; mysqldump, pg_dump gibi araçlarla alınan SQL çıktıları) veritabanı şemasını ve verilerini metin veya özel formatlı arşiv olarak çıkarır. Bu yöntem taşınabilirlik ve sürüm yükseltmeleri açısından idealdir. Fiziksel yedekler ise doğrudan veri bloklarını kopyalar; çok büyük terabaytlık veritabanlarında kurtarma süresini (RTO) kısaltır ancak daha karmaşık araçlar gerektirir.

Üçüncü ve en sık ihlal edilen konu parola güvenliğidir. Crontab satırlarına veya betik içerisine -p'GizliParola' şeklinde açık metin şifre yazmak ciddi bir zafiyettir. Sunucuda bulunan diğer kullanıcılar ps aux komutuyla çalışan işlemleri listelediklerinde veritabanı parolanızı açıkça görebilir. Bu sebeple kimlik doğrulama her zaman yetkileri kısıtlanmış dosyalarda tutulmalıdır. Güvenlik prensipleri hakkında daha fazla bilgi için cron job güvenliği rehberimizi inceleyebilirsiniz.

Adım Adım Kurulum: MySQL ve MariaDB Yedekleme Otomasyonu

MySQL/MariaDB için pratik yol: okuma yetkili backup_user, chmod 0600 ~/.my.cnf, mysqldump --single-transaction --quick, çıktıyı .tmp üzerinden gzip ile yazmak ve crontab'ta gece penceresine almak. Parolayı komut satırına yazmayın.

MySQL ve MariaDB sunucularında güvenli ve kesintisiz yedekleme otomasyonu kurmak için aşağıdaki adımları izleyin:

1. Yedekleme işlemi için yalnızca gerekli okuma ve kilit yetkilerine sahip özel bir veritabanı kullanıcısı (örneğin backup_user) tanımlayın.
2. Cron çalıştıran kullanıcının ev dizininde parola ifşasını önleyen ~/.my.cnf dosyasını oluşturun ve erişim izinlerini 0600 olarak kilitleyin.
3. Canlı tabloları kilitlemeyen ve RAM tüketimini optimize eden mysqldump komut bayraklarını belirleyin.
4. Yedekleme, gzip sıkıştırma, bütünlük denetimi ve eski dosyaları silme işlemlerini yürüten kabuk betiğini (shell script) yazıp çalıştırılabilir yapın.
5. crontab -e komutuyla görevi sunucu trafiğinin en düşük olduğu gece saatlerine zamanlayın.

mysqldump Parametreleri ve ~/.my.cnf Yapılandırması

MySQL veritabanını dışa aktarırken kullanılan parametreler sistem sağlığını doğrudan belirler. Canlı bir e-ticaret veya kurumsal uygulamada varsayılan ayarlarla dump almak, tablolar üzerinde kilit (lock) oluşturarak gelen ziyaretçi isteklerinin kuyrukta beklemesine ve sitenin donmasına neden olabilir. Bu durumu önlemek için InnoDB tablolarında --single-transaction bayrağı zorunludur. Bu bayrak, işlemi başlatırken bir tutarlı okuma noktası (snapshot) oluşturur ve kilit atmadan export alır.

Diğer kritik parametreler şunlardır: --quick parametresi sonuç kümesini istemci belleğine tamamen yüklemeden doğrudan satır satır diskten akıtır; böylece sunucunun RAM yetersizliğinden çökmesini (OOM Killer) engeller. --routines, --triggers ve --events bayrakları ise saklı yordamları, tetikleyicileri ve zamanlanmış veritabanı olaylarını eksiksiz yedekler.

Parolanın komut satırında ifşa olmasını engellemek için yedeklemeyi çalıştıran kullanıcının ev dizininde .my.cnf dosyası oluşturulmalıdır:

# /root/.my.cnf veya /home/kullanici/.my.cnf
[client]
user = backup_user
password = "GucluParolanizBuraya"
host = localhost

Bu dosyanın izinleri kesinlikle sadece dosya sahibine açık olmalıdır. Başka kullanıcıların okumaması için izinleri sınırlandırın:

chmod 0600 ~/.my.cnf

Bu yapılandırma sonrasında mysqldump komutunda kullanıcı adı ve şifre girmenize gerek kalmaz; araç otomatik olarak .my.cnf dosyasındaki bilgileri kullanır.

Adım Adım Kurulum: PostgreSQL (pg_dump) ve ~/.pgpass Güvenlik İzinleri

PostgreSQL'de tercih: pg_dump -Fc (custom format), kimlik bilgisi ~/.pgpass içinde 0600 izinle, geri yüklemede pg_restore -j ile paralellik. Düz SQL dump büyük DB'de hem yavaş hem seçici restore için uygunsuzdur.

PostgreSQL veritabanlarında yedekleme standardı pg_dump aracıdır. PostgreSQL mimarisi Multi-Version Concurrency Control (MVCC) esasına dayandığı için, pg_dump okuma ve yazma işlemlerini engellemeden veritabanının anlık bir fotoğrafını alır. Ancak burada yapılan en büyük hata, doğrudan düz SQL metni üretmektir.

PostgreSQL için en esnek ve performanslı format Custom formattır (-Fc). Custom format hem verileri varsayılan olarak zlib ile sıkıştırır hem de daha sonra pg_restore aracıyla geri yükleme yapılırken çok çekirdekli paralel işlem (-j 4) yapılmasına imkan tanır. Ayrıca bu format sayesinde tüm veritabanı yerine tek bir tabloyu veya sadece şemayı ayıklayarak geri yükleyebilirsiniz.

Parola güvenliği için PostgreSQL ~/.pgpass dosyasını kullanır. Bu dosyanın formatı her satırda beş alandan oluşur: hostname:port:database:username:password.

# ~/.pgpass içeriği
localhost:5432:production_db:pgbackup:GucluPostgresSifresi123
localhost:5432:*:pgbackup:GucluPostgresSifresi123

Adım Adım Kurulum: MongoDB (mongodump --archive --gzip)

MongoDB'de modern yaklaşım tek dosyalık arşivdir: mongodump --archive=... --gzip (veya config URI ile). Klasör ağacı dump'ı I/O ve taşıma maliyetini yükseltir; geri yüklemede mongorestore --archive --gzip kullanılır.

NoSQL veritabanı olan MongoDB'de yedekleme işlemi için MongoDB Database Tools paketiyle birlikte gelen mongodump kullanılır. Eski sürümlerde mongodump çıktıyı disk üzerinde yüzlerce BSON ve JSON dosyası içeren hiyerarşik bir klasör yapısına yazardı. Bu yaklaşım hem dosya sistemi girdi/çıktı (I/O) yükünü artırır hem de transferi zorlaştırır.

Modern MongoDB yedekleme otomasyonunda --archive ve --gzip bayrakları birlikte kullanılır. --archive parametresi tüm koleksiyonları ve indeks tanımlarını tek bir ikili akış haline getirirken, --gzip bu akışı anında sıkıştırır. Böylece tek parça, kompakt bir arşiv dosyası elde edilir.

# MongoDB tek dosya sıkıştırılmış arşiv komutu
# ~/.mongodump.yml dosyasındaki uri alanı:
# uri: "mongodb://backup_user:GucluMongoParolasi@127.0.0.1:27017/production?authSource=admin"
chmod 0600 ~/.mongodump.yml
mongodump --config="$HOME/.mongodump.yml" \
    --archive="/yedekler/mongo/prod_$(date +\%Y\%m\%d).dump.gz" --gzip

Geri yükleme işlemi gerektiğinde ise mongorestore --archive=dosya.dump.gz --gzip --nsInclude="production.*" komutuyla tek hamlede veriler kurtarılabilir.

Yedek Sıkıştırma, Tarih Damgası ve Eski Dosyaları Temizleme Rotasyonu

Diski doldurmamak için üç kural yeterlidir: dump'ı sıkıştırın, dosya adına tarih damgası koyun, saklama süresini aşan arşivleri find ... -mtime +N -delete ile silin. Yazmayı her zaman .tmp ile bitirip doğruladıktan sonra yeniden adlandırın.

Veritabanı yedekleme sistemlerinin karşılaştığı en yaygın felaketlerden biri, yedekleme dosyalarının sunucunun disk alanını fark edilmeden doldurmasıdır. Disk yüzde 100 doluluğa ulaştığında yalnızca yedekleme durmakla kalmaz; veritabanı motoru yeni işlem kaydedemediği için tüm web uygulamanız çöker.

Bu sorunu çözmek için dört temel ilke uygulanmalıdır:

• Yüksek Sıkıştırma: SQL dump çıktıları düz metin olduğundan gzip ile sıkıştırıldığında boyutları içeriğe bağlı olarak küçülür.
• Tarih Damgalı Adlandırma: Dosya adlarında $(date +%Y%m%d_%H%M%S) biçimi kullanılmalıdır. Crontab dosyası içinde yüzde (%) karakteri özel anlam taşıdığından (yeni satır sinyali üretir), doğrudan crontab satırında yazıldığında mutlaka ters eğik çizgi ile kaçışlanmalıdır: \%Y\%m\%d.
• Otomatik Temizleme (Rotasyon): Yedekleme scriptinin sonuna Linux find komutu eklenerek saklama süresi dolan eski dosyalar silinmelidir. Örneğin find /yedekler -type f -name "*.sql.gz" -mtime +14 -delete komutu son değişikliğinin üzerinden en az 15 tam gün geçmiş olan tüm sıkıştırılmış yedekleri otomatik olarak diskten kaldırır.
• Atomik Yazma (.tmp yöntemi): Dump işlemi doğrudan hedef dosyaya yazılırken sunucu çökerse veya disk dolarsa yarım kalmış bozuk bir dosya oluşur. Script içinde yedek önce dosya.sql.gz.tmp adıyla yazılmalı, bütünlük kontrolü (gzip -t) başarılı olduğunda mv komutu ile asıl adına dönüştürülmelidir.

Eski dosyaların log kayıtlarıyla takibi için cron log temizleme ve cron job log rehberlerimize başvurabilirsiniz.

Gerçek Kod Örnekleri

Aşağıdaki betikler üretimde kopyalanabilir: MySQL için single-transaction + gzip bütünlük testi + 14 gün rotasyon; PostgreSQL için -Fc dump ve S3 kopyası. İkisinde de set -euo pipefail ve .tmp atomik yazım vardır.

Aşağıda üretim ortamında güvenle kullanabileceğiniz iki adet kapsamlı ve hata kontrollü kabuk betiği yer almaktadır.

Bash: MySQL Veritabanı Yedekleme ve Rotasyon Betiği

Aşağıdaki scripti /usr/local/bin/mysql-backup.sh olarak kaydedin ve chmod +x /usr/local/bin/mysql-backup.sh iznini verin.

#!/bin/bash
# /usr/local/bin/mysql-backup.sh
# Hata anında betiği durdur
set -euo pipefail

# Yapılandırma
DB_NAME="production_db"
YEDEK_DIR="/yedekler/mysql"
TARIH=$(date +%Y%m%d_%H%M%S)
HEDEF_DOSYA="${YEDEK_DIR}/${DB_NAME}_${TARIH}.sql.gz"
GECICI_DOSYA="${HEDEF_DOSYA}.tmp"
SAKLAMA_GUNU=14

mkdir -p "$YEDEK_DIR"

echo "[$(date '+%Y-%m-%d %H:%M:%S')] MySQL yedekleme baslatildi: $DB_NAME"

# ~/.my.cnf uzerinden yetkilenerek single-transaction ile gecici dosyaya yaz
mysqldump --single-transaction \
          --quick \
          --routines \
          --triggers \
          --events \
          "$DB_NAME" | gzip -9 > "$GECICI_DOSYA"

# Gzip arsiv butunlugunu test et
if gzip -t "$GECICI_DOSYA" 2>/dev/null; then
    mv "$GECICI_DOSYA" "$HEDEF_DOSYA"
    DOSYA_BOYUTU=$(du -h "$HEDEF_DOSYA" | cut -f1)
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Yedek basariyla olusturuldu: $HEDEF_DOSYA ($DOSYA_BOYUTU)"
else
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] HATA: Arsiv butunluk testi basarisiz oldu!" >&2
    rm -f "$GECICI_DOSYA"
    exit 1
fi

# 14 gunden eski yedekleri sil
find "$YEDEK_DIR" -type f -name "${DB_NAME}_*.sql.gz" -mtime +"$SAKLAMA_GUNU" -delete
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $SAKLAMA_GUNU gunden eski yedekler temizlendi."

Bu betiği her gece saat 02:30'da çalıştırmak için crontab sözdizimi kurallarına uygun olarak crontab'a şu satırı ekleyin:

30 2 * * * /usr/local/bin/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1

Bash: PostgreSQL pg_dump Alıp AWS S3'e Senkronize Eden Betik

Aşağıdaki script PostgreSQL yedeğini custom formatta alır ve yerel kopyalamanın ardından AWS CLI kullanarak S3 bucket'ına yükler.

#!/bin/bash
# /usr/local/bin/pg-backup-s3.sh
set -euo pipefail

DB_NAME="production_app"
PG_USER="pgbackup"
YEDEK_DIR="/yedekler/postgres"
S3_BUCKET="s3://sirket-veritabani-yedekleri/postgres"
TARIH=$(date +%Y%m%d_%H%M%S)
DOSYA_ADI="${DB_NAME}_${TARIH}.dump"
TAM_YOL="${YEDEK_DIR}/${DOSYA_ADI}"

mkdir -p "$YEDEK_DIR"

echo "[$(date '+%Y-%m-%d %H:%M:%S')] PostgreSQL yedekleme basladi: $DB_NAME"

# ~/.pgpass dosyasini kullanarak custom format dump al
pg_dump -U "$PG_USER" -h localhost -Fc "$DB_NAME" > "${TAM_YOL}.tmp"
mv "${TAM_YOL}.tmp" "$TAM_YOL"

echo "[$(date '+%Y-%m-%d %H:%M:%S')] Yerel dump alindi. S3 yuklemesi basliyor..."

# AWS CLI ile S3'e kopyala
aws s3 cp "$TAM_YOL" "${S3_BUCKET}/${DOSYA_ADI}" --quiet

echo "[$(date '+%Y-%m-%d %H:%M:%S')] S3 yuklemesi tamamlandi."

# Yerel diskte 7 gunden eski dosyalari temizle
find "$YEDEK_DIR" -type f -name "*.dump" -mtime +7 -delete

Senaryo: Staging'de geri yükleme smoke testi (haftalık)

Dump dosyasının boyutu sıfırdan büyük olması yedeğin okunabilir olduğunu kanıtlamaz. Haftada bir kez, üretimden ayrı bir staging PostgreSQL örneğinde son gece alınan custom dump'ı geri yükleyip kritik tabloda satır sayısı doğrulayın. Bu test RTO/RPO varsayımlarını gerçek komutlarla kanıtlar; yalnızca ls -lh ile yetinmek yedek illüzyonu yaratır.

Ne zaman kullanılır: yeni major sürüm yükseltmesinden önce, şema migration sonrası ve her ayın ilk Pazar gecesi otomatik cron olarak. Neden ayrıdır: üretim üzerine restore etmek yıkıcıdır; staging boş bir veritabanı (production_restore_test) hedeflenir.

#!/bin/bash
# /usr/local/bin/pg-restore-smoke.sh — haftalik: 15 4 * * 0
set -euo pipefail
LATEST=$(ls -1t /yedekler/postgres/production_app_*.dump | head -1)
TEST_DB="production_restore_test"
dropdb --if-exists "$TEST_DB"
createdb "$TEST_DB"
pg_restore -d "$TEST_DB" -j 2 --no-owner --no-acl "$LATEST"
# Kritik tablo satır sayisi (ornek); 0 ise smoke basarisiz
ROWS=$(psql -d "$TEST_DB" -Atc "SELECT count(*) FROM orders;")
echo "[$(date -Is)] restore_smoke ok file=$LATEST orders=$ROWS"
# Esik: beklenen minimum (uygulamaniza gore ayarlayin)
if [ "$ROWS" -lt 1 ]; then
  echo "HATA: orders bos; yedek veya restore kusurlu" >&2
  exit 1
fi

MySQL tarafında eşdeğer akış: staging'de boş şema oluşturup gunzip -c dosya.sql.gz | mysql staging_db, ardından SELECT COUNT(*). MongoDB'de mongorestore --archive=... --gzip --nsFrom='production.*' --nsTo='restore_test.*' ile ayrı namespace'e açın. Smoke betiği başarısız olursa yedek cron'unu "başarılı" saymayın; e-posta veya monitoring alarmı bağlayın.

Sık Karşılaşılan Hatalar ve Çözümleri

Aşağıdaki mesajlar dump araçlarından gelir; cron tetiklenmesini doğrulamak ayrı bir adımdır (bir sonraki bölüm). Veritabanı yedekleme süreçlerinde sistem yöneticilerinin karşısına en sık çıkan hata mesajları, kök nedenleri ve çözüm yolları:

mysqldump: [Warning] Using a password on the command line interface can be insecure

Neden: Parolanın mysqldump -p'parola' şeklinde doğrudan komut satırı argümanı olarak verilmesi. Linux çekirdeği komut satırı argümanlarını süreç tablosunda (process table) sakladığından diğer yerel kullanıcılar şifreyi görebilir ve MySQL bu güvenlik uyarısını üretir.

Çözüm: Komut satırından şifre parametresini kaldırın. Şifreyi kullanıcının ev dizinindeki ~/.my.cnf dosyasında [client] bölümü altına yazıp dosya izinlerini chmod 0600 ~/.my.cnf yapın.

mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes

Neden: Veritabanı tablolarında çok büyük BLOB, metin veya base64 kodlu ikili dosyalar saklandığında, tek bir satır MySQL sunucusunun veya istemcisinin paket sınırını aşar ve dump yarıda kesilir.

Çözüm: mysqldump komutuna --max_allowed_packet=512M parametresini ekleyerek istemci paket limitini artırın. Gerekirse MySQL sunucu yapılandırmasında (my.cnf) da bu değeri yükseltip servisi yeniden başlatın.

pg_dump: error: connection to server on socket failed: FATAL: password authentication failed

Neden: PostgreSQL kimlik doğrulamasında parolanın bulunamaması veya ~/.pgpass dosyasının izinlerinin gereğinden fazla açık olması. Dosya grup veya diğer kullanıcıların erişimine açıksa PostgreSQL bu dosyayı güvenlik gerekçesiyle yok sayar.

Çözüm: ~/.pgpass dosyasındaki sunucu, port, veritabanı, kullanıcı ve şifre beşlisini kontrol edin. Ardından chmod 0600 ~/.pgpass komutunu çalıştırarak yetkileri kilitleyin.

mysqldump: Got error: 1044: Access denied when using LOCK TABLES

Neden: Yedek alan kullanıcının ilgili veritabanında tabloları kilitleme (LOCK TABLES) ayrıcalığına sahip olmaması.

Çözüm: Eğer InnoDB motoru kullanıyorsanız komuta --single-transaction bayrağını ekleyin. Bu bayrak sayesinde tablolar kilitlenmeden snapshot alınır ve kilit iznine ihtiyaç kalmaz. Tablolar MyISAM ise veritabanı kullanıcısına GRANT LOCK TABLES ON veritabani.* TO 'kullanici'@'localhost'; yetkisi verilmelidir.

No space left on device

Neden: Yedekleme dizininin bulunduğu disk bölümünün (partition) dolması veya eski yedeklerin rotasyonunun yapılmaması.

Çözüm: Betiğinize find ... -delete rotasyon kuralını ekleyin. Sıkıştırma seviyesini gzip -9 yaparak disk tasarrufu sağlayın ve büyük veritabanlarında dump işlemini ayrı bir disk bölümüne yönlendirin. Görevlerinizin çalışmama nedenlerini tespit etmek için cron job çalışmıyor rehberimizdeki adımları izleyin.

Doğrulama ve sorun giderme

Yedek betiği "sessizce" başarısız olduğunda önce cron'un komutu başlatıp başlatmadığını, sonra dump aracının çıkış kodunu ve arşiv bütünlüğünü ayırın. Aşağıdaki tablo belirtiyi komuta bağlar; ardından örnek log satırlarıyla başarı/başarısızlık ayrımını görün.

# Basarili gece yedegi (uygulama logu)
2026-10-28T02:30:01+03:00 CRON[18421]: (root) CMD (/usr/local/bin/mysql-backup.sh)
[2026-10-28 02:30:01] MySQL yedekleme baslatildi: production_db
[2026-10-28 02:31:18] Yedek basariyla olusturuldu: /yedekler/mysql/production_db_20261028_023001.sql.gz (42M)
[2026-10-28 02:31:18] 14 gunden eski yedekler temizlendi.

# Basarisiz ornek: pgpass yok sayildi, cron ciktisi
2026-10-28T02:30:01+03:00 CRON[18455]: (postgres) CMD (/usr/local/bin/pg-backup-s3.sh)
pg_dump: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  password authentication failed for user "pgbackup"
# cozum: chmod 0600 /var/lib/postgresql/.pgpass ve hostname eslesmesi

Yedek cron'u logda görünüp arşiv üretmezse veya smoke restore kırılırsa, tetikleme ile çıktı başarısını ayırın. İşin "hiç çalışmadığı" geceleri yakalamak için ayrı bir cron heartbeat izleme uç noktasına betik sonunda başarılı ping atın; dump logu ile dead-man's switch birbirinin yerine geçmez.

cronjob.com.tr ile HTTP Tabanlı Alternatif Kurulum

Veritabanı sunucuları güvenlik gerekçesiyle doğrudan dış internete açılmamalıdır; bu nedenle mysqldump gibi düşük seviyeli komutlar doğrudan sunucu içindeki crontab ile çalıştırılmalıdır. Ancak modern mikroservis mimarilerinde, CMS altyapılarında veya Docker ortamlarında veritabanı dışa aktarma (export) ve yedekleme görevlerini bir HTTP uç noktası (endpoint) üzerinden tetiklemek oldukça yaygındır.

Eğer web uygulamanızda güvenli bir arka plan yedekleme URL'i (örneğin https://api.siteniz.com/internal/trigger-backup) bulunuyorsa, bu işlemi tetiklemek ve denetlemek için cronjob.com.tr platformunu kullanabilirsiniz.

1. Web uygulamanızdaki yedekleme uç noktasını gizli bir başlık anahtarıyla (token) koruyun: X-Backup-Token: GizliGuvenlikAnahtari123. Token eşleşmezse HTTP 403 döndürün.
2. cronjob.com.tr panelinde ücretsiz hesap açın (kredi kartı istenmez).
3. Yeni görev oluştururken istek metodunu POST veya GET olarak belirleyin, URL alanına yedekleme endpoint'inizi girin.
4. Headers bölümüne X-Backup-Token başlığını ve gizli anahtarınızı ekleyin.
5. Zamanlama alanında hazır aralıklardan birini seçin veya 5 alanlı cron ifadesi (örneğin gece 03:00 için 0 3 * * *) tanımlayın. Saat dilimi iş bazında seçilebilir (varsayılan Europe/Istanbul).
6. Yedekleme işlemleri uzun sürebileceğinden yanıt bekleme (timeout) süresine dikkat edin: cronjob.com.tr cron ifadeli işlerde 290 saniyeye kadar yanıt bekler.

cronjob.com.tr, HTTP 200–399 arası durum kodlarını başarılı kabul eder. Yedekleme uç noktanız bağlantı hatası verir veya 500 kodu dönerse, sistem ardışık hata eşiği (varsayılan 3) aşıldığında e-posta ile yöneticiye uyarı iletir; aynı iş için bildirimler arasında en az 60 dakika bulunur. Tüm çalışma logları (yanıt süresi, durum kodu ve ilk ~64 KB yanıt gövdesi) 7 gün boyunca sistemde saklanır.

Sıkça Sorulan Sorular (SSS)

--single-transaction bayrağı ne işe yarar?

InnoDB tablolarını satır veya tablo bazında kilitlemeden, snapshot izolasyon düzeyiyle tutarlı yedek almayı sağlar. Canlı web sitelerinde okuma ve yazma işlemlerinin kesintiye uğramasını önler.

Yedek dosyalarının diski doldurmasını nasıl engellerim?

Yedekleme betiğinize find komutu ekleyerek belirli bir günden eski arşivleri silebilirsiniz. Örneğin find /yedekler -type f -name "*.sql.gz" -mtime +14 -delete komutu son değişikliğinin üzerinden en az 15 tam gün geçmiş dosyaları temizler.

Yedekleme sırasında sunucu çökerse ne olur?

İşlem yarıda kalırsa diskte eksik veya bozuk bir dump dosyası oluşur. Bu durumu önlemek için yedek önce .tmp uzantısıyla yazılmalı, işlem ve bütünlük doğrulaması hatasız tamamlandığında dosya asıl adına taşınmalıdır.

MongoDB için hangi araç kullanılmalıdır?

MongoDB Database Tools paketiyle gelen mongodump komutu kullanılmalıdır. Veritabanı boyutuna bağlı olarak --archive parametresiyle tek bir akış oluşturulup --gzip ile sıkıştırılması önerilir.

pg_dump -Fc çıktısını geri yüklemeden nasıl doğrularım?

pg_restore -l dosya.dump yalnızca arşivin içindekiler listesini gösterir, veriyi doğrulamaz; boş veya hatalı arşivde komut hata verir. Asıl test: yedeği ayrı bir staging veritabanına şema + veriyle geri yükleyip (pg_restore -d staging_db ...) kritik tabloların satır sayılarını yedek anındaki değerlerle karşılaştırmaktır.

Yedek dosyası oluşuyor ama geri yükleme neden başarısız olur?

Sık nedenler: yarım kalmış .tmp dosyasının asıl adla karışması, gzip bozulması, MySQL'de max_allowed_packet aşımı, PostgreSQL'de major sürüm uyumsuzluğu veya hedefte eksik rol/uzantı. Önce gzip -t veya pg_restore -l, sonra ayrı staging örneğinde tam restore deneyin.

Sonuç

Güvenilir bir veritabanı yedekleme altyapısı; doğru araçların seçilmesi, şifrelerin güvenli yapılandırma dosyalarında saklanması, canlı sistemlerde kilitlenmeyi önleyen parametrelerin kullanılması ve otomatik disk rotasyonunun uygulanmasıyla mümkündür. MySQL, PostgreSQL ve MongoDB için hazırladığınız shell scriptlerini cron job ile zamanlayarak olası veri kayıplarının önüne geçebilirsiniz.

İlgili Rehberler