Paylaşımlı Hostingte Otomatik Yedekleme Nasıl Kurulur? cPanel Cron

cPanel otomatik yedekleme kurmak isteyen çoğu kişi aynı duvara çarpar: internetteki rehberler ya root gerektiren sunucu komutları verir ya da panelde "Tam Yedekleme" düğmesini gösterip biter. İkisi de işe yaramaz — birincisi paylaşımlı hostingte çalıştıramazsınız, ikincisi otomatik değildir, her seferinde sizin tıklamanızı bekler. Oysa paylaşımlı hosting hesabınızda otomatik yedekleme kurmak fazlasıyla mümkündür; gereken tek şey cPanel'in Cron İşleri ekranı ve doğru yazılmış birkaç satır komuttur.

Bu yazıda SSH erişiminiz olmadan, yalnızca panel üzerinden çalışan uçtan uca bir otomatik yedekleme düzeni kuruyoruz: veritabanı dökümü alma, dosyaları arşivleme, yedeği ayrı bir FTP hesabına gönderme, eski yedekleri temizleme ve tüm bunları disk kotanızı doldurmadan yapma. Her adımın yanında neden öyle yapıldığını da yazdım, çünkü paylaşımlı hostingte yedekleme kurulumunu bozan şey genelde komutun kendisi değil, kotanın dolması ya da yedeğin aynı hesapta kalmasıdır.

Paylaşımlı Hostingte Otomatik Yedeklemenin Gerçek Sınırları#

Paylaşımlı hostingte yedekleme kurarken üç sınırla çalışırsınız ve bunları bilmeden kurduğunuz her düzen bir yerde tıkanır.

Birinci sınır: disk kotası. Yedek, hesabınızın içinde oluşturulur ve kotanızdan yer yer. 4 GB'lık bir sitenin tam yedeğini kendi hesabınıza almak, o an için kullanımınızı yaklaşık iki katına çıkarır. Kota dolduğunda yalnızca yedek başarısız olmaz — site de yazamaz hâle gelir, oturumlar bozulur, e-posta düşer.

İkinci sınır: inode sayısı. Paylaşımlı paketlerde dosya sayısı da sınırlıdır. Yedek arşivi tek bir dosya olduğu için inode açısından ucuzdur, ama arşivlenmemiş kopyalar tutuyorsanız sayı hızla şişer. Konunun ayrıntısı için disk kotası ve inode yazısına bakın.

Üçüncü sınır: işlem gücü. Paylaşımlı sunucularda hesap başına CPU ve bellek limiti vardır. Büyük bir arşivleme işi bu limiti zorlarsa süreç yarıda öldürülür ve elinizde bozuk bir arşiv kalır. Bu yüzden yedeği trafiğin en düşük olduğu saatte çalıştırmak sadece nezaket değil, teknik gerekliliktir.

Bu üç sınır, kurulumun şeklini belirler: yedek üretilir, hemen hesap dışına gönderilir, sonra hesaptan silinir. Hesapta uzun süre yedek biriktirmek paylaşımlı ortamda sürdürülebilir değildir.

Panelin Kendi Yedekleme Araçları Ne Yapar, Ne Yapmaz#

cPanel'de yedekle ilgili iki ekran vardır ve ikisi de otomasyonun sadece bir kısmını karşılar.

Yedekleme Sihirbazı (Backup Wizard) tam hesap yedeği üretir ve hedef olarak "Uzak FTP Sunucusu" seçmenize izin verir. Bu, yedeği doğrudan başka bir sunucuya göndermesi bakımından değerlidir — hesabınızda hiç yer kaplamaz. Ancak bu ekran elle tetiklenir; zamanlanmış çalışma seçeneği yoktur. Her gün kendiniz basacaksanız otomatik değildir.

Yedekleme (Backup) ekranı ise ana dizin, veritabanı ve e-posta yönlendiricileri için ayrı ayrı indirme sunar ve genelde sunucunun tuttuğu sistem yedeklerini listeler. Sağlayıcının aldığı bu sistem yedekleri işe yarar ama sizin kontrolünüzde değildir; saklama süresini, sıklığı ve kapsamı siz belirlemezsiniz. Bu ikisinin farkını hosting yedeği mi kendi yedeğim mi yazısında ayrıntılı karşılaştırdık.

Ekranların tam kullanımını görmek isterseniz cPanel yedekleme yazısı adım adım anlatıyor. Buradan sonrası, o ekranların yapamadığı şeyi — zamanlanmış, kendiliğinden çalışan yedeği — kurmakla ilgili.

Cron İşleri Ekranını Tanımak#

cPanel'de Gelişmiş → Cron İşleri ekranı, sunucudaki zamanlayıcıya kendi komutlarınızı yazdırmanızı sağlar. SSH erişiminiz olmasa bile bu ekran çalışır; komut sizin kullanıcı kimliğinizle koşar.

Ekranda üç şeye dikkat edin:

1. Cron E-posta Adresi. Buraya yazdığınız adrese, komutun ürettiği her çıktı gönderilir. Kurulum aşamasında bunu açık bırakın — hata mesajlarını göreceğiniz tek yer burasıdır. Düzen oturduktan sonra komutun sonuna > /dev/null 2>&1 ekleyerek susturabilirsiniz.
2. Ortak Ayarlar açılır listesi. Zamanlamayı elle yazmak yerine buradan seçebilirsiniz, ama alanları anlamak işinize yarar.
3. Komut alanı. Buraya tek satır yazılır. Birden fazla komut çalıştıracaksanız && ile bağlayın veya bir betik dosyası çağırın — ikincisi çok daha temizdir.

Cron zamanlama alanlarının anlamını tazelemek isterseniz cron görevleri linux yazısı beş alanı tek tek açıklıyor.

⚠️ Bir uyarı: cron ortamında PATH değişkeni kabuktakinden çok daha dardır. Kabukta çalışan bir komut cron'da "command not found" verebilir. Çözüm, komutları tam yolla yazmak ya da betiğin başında PATH tanımlamaktır.

Yedekleme Betiğini Yazmak#

En sağlam yol, komutları cron satırına doldurmak yerine bir betik dosyasına koymaktır. Dosya Yöneticisi'nden ana dizininizde (public_html içinde değil) yedek.sh adında bir dosya oluşturun.

Betiğin public_html dışında olması kritiktir: web kökünün içine koyarsanız betiğiniz ve içindeki veritabanı parolası internetten indirilebilir hâle gelir.

#!/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin

KULLANICI="hesapadi"
ANA="/home/$KULLANICI"
HEDEF="$ANA/yedekler"
TARIH=$(date +%Y-%m-%d)

DB_AD="hesapadi_wp"
DB_KUL="hesapadi_wpuser"
DB_SIFRE="buraya_parola"

mkdir -p "$HEDEF"

# 1) Veritabanı dökümü
mysqldump --single-transaction --quick --routines --triggers \
  -u "$DB_KUL" -p"$DB_SIFRE" "$DB_AD" | gzip > "$HEDEF/db-$TARIH.sql.gz"

# 2) Dosya arşivi
tar -czf "$HEDEF/dosya-$TARIH.tar.gz" \
  --exclude="$ANA/yedekler" \
  --exclude="*/wp-content/cache/*" \
  --exclude="*/wp-content/uploads/backup*" \
  -C "$ANA" public_html

# 3) 3 günden eski yerel yedekleri sil
find "$HEDEF" -name "*.gz" -mtime +3 -delete

Dosyayı kaydettikten sonra Dosya Yöneticisi'nde sağ tıklayıp İzinleri Değiştir ile 700 verin. İçinde veritabanı parolası olduğu için başkasının okuyamaması gerekir.

Betikteki üç ayrıntı önemlidir. --single-transaction, döküm alınırken tabloları kilitlemez; onsuz çalışan bir yedek, döküm süresince sitenizi yazılamaz hâle getirebilir. --exclude="$ANA/yedekler" satırı olmazsa tar kendi ürettiği arşivi arşivlemeye çalışır ve dosya sonsuz büyür — bu, paylaşımlı hostingte kotayı en hızlı dolduran klasik hatadır. Önbellek dizinlerini dışarıda bırakmak da arşivi çoğu WordPress sitesinde belirgin biçimde küçültür.

Veritabanı adı, kullanıcı adı ve parolayı nereden alacağınızı bilmiyorsanız veritabanı bilgileri nereden bulunur yazısına bakın; değerler wp-config.php dosyasının içinde de durur.

Yedeği Hesabın Dışına Göndermek#

Bu, tüm kurulumun en önemli adımıdır. Aynı hesapta duran yedek, hesabı kaybettiren hiçbir senaryoda işe yaramaz: hesap askıya alınırsa, sunucu diski arızalanırsa veya site ele geçirilip dosyalar silinirse yedek de gider.

Paylaşımlı hostingte en pratik hedef, başka bir sunucudaki FTP hesabıdır. curl neredeyse her cPanel sunucusunda vardır ve FTP yükleme yapabilir. Betiğin sonuna ekleyin:

FTP_SUNUCU="ftp://yedek.baskasunucu.com/vds1/"
FTP_KUL="yedekkullanici"
FTP_SIFRE="ftp_parolasi"

for dosya in "$HEDEF"/db-$TARIH.sql.gz "$HEDEF"/dosya-$TARIH.tar.gz; do
  curl -sS --ftp-create-dirs -T "$dosya" \
    --user "$FTP_KUL:$FTP_SIFRE" "$FTP_SUNUCU" || echo "YUKLEME HATASI: $dosya"
done

--ftp-create-dirs hedefte klasör yoksa oluşturur. -sS bayrağı ilerleme çubuğunu susturur ama hataları gösterir — cron e-postasında gereksiz çıktı istemezsiniz, hatayı ise mutlaka görmelisiniz.

Hedefte FTP değil SFTP kullanabiliyorsanız tercih edin; FTP kimlik bilgilerini şifresiz taşır. curl SFTP'yi de destekler:

curl -sS -T "$dosya" --user "$FTP_KUL:$FTP_SIFRE" "sftp://yedek.baskasunucu.com/vds1/"

Hedef tarafta yedek için ayrı ve yetkisi kısıtlı bir FTP hesabı açın; ana hesabınızın bilgilerini betiğe yazmayın. Nasıl açıldığını cPanel FTP hesabı oluşturma yazısında bulabilirsiniz. Yedeği bulut depolamaya göndermek istiyorsanız yedekleri Google Drive'a otomatik gönderme yazısı o akışı ayrıca anlatıyor.

Cron Görevini Kurmak ve Zamanlamayı Seçmek#

Betik hazır olduğuna göre cron'a tek satır yazmak kalıyor. Gelişmiş → Cron İşleri ekranında zamanlamayı seçin ve komut alanına şunu yazın:

/bin/bash /home/hesapadi/yedek.sh >> /home/hesapadi/yedek.log 2>&1

Çıktıyı bir günlük dosyasına yönlendirmek, e-posta kutunuzu doldurmadan hataları saklamanızı sağlar. İlk kurulumda bu satırı >> ... 2>&1 olmadan bırakıp çıktının e-postayla gelmesini sağlayın; her şey doğru çalıştığında günlüğe çevirin.

Zamanlama seçerken sitenizin trafik profiline bakın:

Gece 03.00–05.00 aralığı çoğu Türkiye odaklı site için doğru penceredir. Ancak sunucunun saat dilimi sizinkinden farklı olabilir; cron ekranında görünen saati, hesabınızın saat dilimiyle karşılaştırın. Emin olmak için bir kez date komutunu cron'la çalıştırıp çıktıyı e-postayla alın.

E-ticaret satırındaki ikili yapıya dikkat edin: dosyalar günde bir kez, veritabanı altı saatte bir. Sipariş verisi veritabanındadır ve dosyalardan çok daha hızlı değişir; ikisini aynı sıklıkta almak ya gereksiz yük ya da gereksiz risk üretir. Ne sıklıkta yedek alacağınıza karar verirken ne sıklıkta yedek alınmalı yazısındaki ölçütlere bakın.

Kotayı Taşırmadan Çalışmak#

Otomatik yedeklemenin paylaşımlı hostingte en sık öldüğü yer disk kotasıdır. Betiğe küçük bir güvenlik kontrolü ekleyerek bunu tamamen önleyebilirsiniz — yeterli yer yoksa yedek hiç başlamasın, kotayı doldurup siteyi düşürmesin:

# Boş alanı MB cinsinden oku
BOS=$(df -Pm "$ANA" | awk 'NR==2 {print $4}')
GEREKLI=2048   # 2 GB

if [ "$BOS" -lt "$GEREKLI" ]; then
  echo "YEDEK ATLANDI: yetersiz disk alani (${BOS}MB)"
  exit 1
fi

Bunun yanında üç alışkanlık edinin:

1. Eski yedekleri önce silin, sonra yenisini üretin. Betikte find ... -delete satırını arşivleme adımından önce çalıştırmak, en dar durumda bile yer açar.
2. Yerelde en fazla 2-3 kopya tutun. Uzun geçmiş, hesabınızda değil hedef sunucuda tutulmalıdır.
3. Disk kullanımını düzenli izleyin. cPanel'in Disk Kullanımı ekranı hangi klasörün şiştiğini gösterir; ayrıntı için cPanel disk kullanımı yazısına bakın.

Bir de sık atlanan bir nokta var: wp-content/uploads içine yedek yazan eklentiler. Yedekleme eklentisi kullanıyorsanız ürettiği arşivler hem kotanızı yer hem de sizin tar arşivinize dâhil olur — yani yedeğin içinde yedek taşırsınız. Betikteki --exclude satırlarından biri tam olarak bunun içindir.

Uygulama Eklentisiyle mi, Cron ile mi#

WordPress kullanıyorsanız yedekleme eklentileri de zamanlanmış yedek alabilir ve teknik bilgi gerektirmez. İkisinin farkını bilerek seçin.

Belirleyici satır ikincisidir: eklenti, WordPress'in içinde çalışır. Site ölümcül hata verdiğinde ya da veritabanı bağlantısı koptuğunda zamanlanmış yedek de çalışmaz — yani tam ihtiyaç duyduğunuz anda susar. Cron ise siteden bağımsızdır. Eklenti tarafını tercih edecekseniz UpdraftPlus nasıl kullanılır yazısı kurulumu anlatıyor; en sağlam kurulum ise ikisini birlikte kullanmaktır.

Yedeklerin Gerçekten Alındığını Doğrulamak#

Kurduğunuz düzenin sessizce durması, en tehlikeli senaryodur. "Yedek alınıyordur" varsayımıyla geçen aylar, ihtiyaç anında boş bir klasörle sonuçlanır. Üç basit kontrol yeterlidir.

Birincisi: dosya boyutu izleme. Hedef FTP hesabına her gün girip dosya listesine bakmak yerine betiğin sonuna bir doğrulama satırı ekleyin. Arşiv beklenenden küçükse haber versin:

BOYUT=$(stat -c %s "$HEDEF/dosya-$TARIH.tar.gz")
if [ "$BOYUT" -lt 1000000 ]; then
  echo "UYARI: arsiv beklenenden kucuk (${BOYUT} bayt)"
fi

Bu satır çıktı ürettiğinde cron size e-posta atar. Sessizlik iyi haberdir.

İkincisi: arşiv bütünlüğü. Ayda bir, hedeften indirdiğiniz arşivi açılabildiğini doğrulayın. Kendi bilgisayarınızda tar -tzf dosya.tar.gz | head komutu, arşivin okunabildiğini ve beklediğiniz dizin yapısını içerdiğini gösterir.

Üçüncüsü: gerçek geri yükleme. Yılda birkaç kez, yedeği bir test alt alan adına açıp siteyi gerçekten çalıştırın. Tek gerçek test budur ve geri yükleme sırasında karşınıza çıkabilecek hatalar için yedeği geri yükleyince site açılmadı yazısı belirtiden nedene giden bir liste sunuyor. Veritabanı dökümünü geri almanın doğru sırası ise veritabanı yedekten geri yükleme yazısında.

Sık Yapılan Beş Hata#

Yıllardır aynı beş hatayı görüyorum ve beşi de kurulum sırasında beş dakikada önlenebiliyor.

1. Betiği public_html içine koymak. İçinde veritabanı parolası olan bir dosyayı web kökünde tutmak, onu internete yayınlamaktır. Ana dizinde tutun ve izinlerini 700 yapın.
2. Yedek klasörünü arşivden dışlamamak. tar, ürettiği arşivi arşivlemeye çalışır ve dosya kontrolsüz büyür.
3. Yedeği aynı hesapta bırakmak. Hesabı kaybettiren senaryoların hepsinde yedek de kaybolur.
4. Cron çıktısını hiç okumamak. Kurulumdan sonra ilk hafta e-postaları kontrol edin; bir yazım hatası ya da eksik komut ancak orada görünür.
5. Eski yedekleri temizlememek. Kota dolduğunda yalnızca yedek değil, site de yazamaz hâle gelir.

Kurulumu tamamladıktan sonra tek bir kontrol yapın: cron ekranında görevi geçici olarak bir dakika sonrasına ayarlayıp elle tetikleyin, e-postaya gelen çıktıyı okuyun, sonra gerçek zamanlamaya çevirin. Bu tek deneme, sonraki aylardaki sessiz başarısızlıkların neredeyse tamamını ortadan kaldırır.

Sıkça Sorulan Sorular#

SSH erişimim yokken cPanel'de otomatik yedek alabilir miyim#

Alabilirsiniz, çünkü cPanel'in Cron İşleri ekranı SSH erişimi olmadan da komut çalıştırmanıza izin verir. Ekrandan tanımladığınız görev, sunucudaki zamanlayıcı tarafından sizin kullanıcı kimliğinizle koşturulur; kabuk açmanıza gerek kalmaz. Betiği Dosya Yöneticisi ile oluşturup cron satırında çağırmanız yeterlidir. Tek dikkat edilecek nokta, cron ortamının PATH değişkeninin dar olmasıdır; komutları tam yolla yazarsanız bu sorunu da yaşamazsınız.

Yedeği kendi hesabımda tutmak yeterli mi#

Yeterli değildir, çünkü hesabınızı kaybettiren her senaryoda yedek de birlikte kaybolur. Disk arızası, hesabın askıya alınması, dosyaların silinmesiyle sonuçlanan bir güvenlik olayı ya da yanlış bir toplu silme işlemi hem siteyi hem yedeği aynı anda götürür. Hesap içindeki kopya yalnızca "yanlışlıkla sildim" türü küçük hatalarda hızlı dönüş sağladığı için değerlidir. En az bir kopyanın farklı bir sunucudaki FTP hesabında veya bulut depolamada bulunması gerekir.

Otomatik yedek disk kotamı doldurur mu#

Önlem almazsanız doldurur ve bu, paylaşımlı hostingte yedekleme kurulumlarının en sık ölüm nedenidir. Tam bir hesap yedeği, üretildiği anda kullanımınızı yaklaşık iki katına çıkarır; kota dolduğunda site de yazamaz hâle gelir. Bunu önlemenin üç yolu var: betiğe boş alan kontrolü koymak, eski yedekleri yenisini üretmeden önce silmek ve yerelde en fazla iki üç kopya tutmak. Uzun geçmişi hesabınızda değil, yedeği gönderdiğiniz hedef sunucuda saklayın.

cPanel'in Yedekleme Sihirbazı otomatik çalışır mı#

Çalışmaz, çünkü Yedekleme Sihirbazı elle tetiklenen bir araçtır ve zamanlama seçeneği sunmaz. Uzak FTP sunucusuna gönderim yapabilmesi değerlidir ama her seferinde sizin başlatmanız gerekir. Sağlayıcının sunucu tarafında aldığı sistem yedekleri ise otomatiktir, fakat kapsamını, sıklığını ve saklama süresini siz belirleyemezsiniz. Kendi kontrolünüzde bir otomasyon istiyorsanız Cron İşleri ekranı üzerinden kurmanız gerekir.

Yedekleme betiğine veritabanı parolasını yazmak güvenli mi#

Betik web kökünün dışında duruyor ve izinleri kısıtlıysa kabul edilebilir bir risktir. Dosyayı public_html içine koyarsanız internetten indirilebilir hâle gelir ve parolanız açığa çıkar; bu yüzden ana dizinde tutup izinleri 700 yapmanız gerekir. Parolayı doğrudan cron satırına yazmaktan da kaçının, çünkü cron komutları başka ekranlarda ve süreç listelerinde görünebilir. Sunucunuz destekliyorsa kimlik bilgilerini ayrı bir yapılandırma dosyasında tutmak daha temiz bir çözümdür.

Yedeklerin alınıp alınmadığını nasıl takip ederim#

En pratik yöntem, betiğin yalnızca sorun olduğunda çıktı üretmesini sağlamaktır; böylece cron e-postası geldiğinde bir şeyin ters gittiğini anlarsınız. Arşiv boyutunun beklenen eşiğin altında kalması durumunda uyarı basan birkaç satır, sessiz başarısızlıkların çoğunu yakalar. Bunun yanında ayda bir hedef depolamadaki dosya listesine bakıp tarihlerin güncel olduğunu doğrulayın. Asıl kesin kontrol ise yılda birkaç kez yedeği bir test adresine açıp sitenin gerçekten çalıştığını görmektir.

E-posta hesaplarım da yedeğe dâhil oluyor mu#

Betiğe eklemediğiniz sürece dâhil olmaz. cPanel'de posta kutuları genellikle ana dizin altındaki mail klasöründe tutulur; yalnızca public_html dizinini arşivliyorsanız e-postalarınız yedeğin dışında kalır. Posta kutularınızı da almak istiyorsanız tar komutunun kapsamına o klasörü eklemeniz gerekir, ancak boyutun ciddi biçimde artacağını hesaba katın. E-posta yedeklemesinin ayrı yöntemleri için konuya özel rehberlere bakmanız daha verimli olur.

Site çok büyükse yedekleme yarıda kesilir mi#

Kesilebilir, çünkü paylaşımlı sunucularda hesap başına CPU, bellek ve işlem süresi limitleri vardır ve büyük bir arşivleme işi bu limitleri aşabilir. Böyle durumlarda elinizde bozuk, açılamayan bir arşiv kalır. Bunu önlemek için yedeği trafiğin en düşük olduğu gece saatlerine alın, önbellek ve geçici dosya dizinlerini arşivden dışlayın ve dosyalarla veritabanını ayrı görevlerde çalıştırın. Site gerçekten büyükse ve bu limitler sürekli sorun çıkarıyorsa, kaynakların size ayrıldığı bir sunucuya geçmek daha doğru bir çözümdür.

Kapanış#

Paylaşımlı hostingte otomatik yedekleme, root erişimi gerektiren bir iş değildir; cPanel'in Cron İşleri ekranı, doğru yazılmış bir betik ve hesap dışındaki bir hedef yeterlidir. Kurulumun mantığı üç cümleyle özetlenir: yedeği üret, hemen hesabın dışına gönder, yerelde biriktirme. Disk kotasını koruyan bir alan kontrolü, arşivden dışlanan yedek klasörü ve kurulumdan sonra okunan ilk cron e-postası — bu üç ayrıntı, yedekleme düzenlerinin sessizce durmasının önündeki en büyük engellerdir. Sonrası tek bir alışkanlığa iner: yılda birkaç kez yedeği gerçekten geri yükleyip çalıştığını görmek.

Bu işi kendiniz kurmak yerine devretmek isterseniz, sunucu dışında tutulan sürümlü kopyalar için yedekleme çözümümüz bu sorumluluğu üstlenir. Yedekleme için yeterli disk ve kaynak sunan bir pakete geçmek istiyorsanız hosting paketleri sayfasındaki seçenekleri karşılaştırabilirsiniz. WordPress tarafında güncelleme, yedek ve izlemenin düzenli yürütülmesini istiyorsanız WordPress bakım paketine, arşivleme ve cron işlerinin kaynak limitine takıldığı büyük siteler içinse VDS paketleri sayfasına bakmanızı öneririm.