Hosting Firmasının Yedeği Yeterli mi? Kendi Yedeğiniz Şart mı

"Hosting firması zaten yedek alıyor" cümlesi, veri kaybı yaşamış insanların hepsinin bir zamanlar kurduğu cümledir. Hosting yedek alıyor mu sorusunun teknik cevabı çoğu firmada "evet"tir; ama asıl soru bu değildir. Asıl soru şudur: o yedek kaç gün geriye gidiyor, siz mi ulaşabiliyorsunuz yoksa talep mi açmanız gerekiyor, geri dönüş ücretli mi, ve firma o yedeğin varlığını sözleşmede taahhüt ediyor mu? Bu dört sorunun cevabını bilmeden alınan güvence, güvence değil varsayımdır.

Bu yazıda yedek almanın nasıl yapıldığını anlatan yüzlerce Türkçe yazının atladığı yere gireceğiz: hizmet sözleşmelerindeki "yedekleme bir hizmet garantisi değildir" maddesinin ne anlama geldiği, saklama süresinin neden çoğu felakette yetmediği, geri dönüşün ücretli olabileceği, ve yedeğin siteyle aynı sunucuda durmasının neden yedek sayılmadığı. Sonra 3-2-1 kuralının hosting dünyasındaki pratik karşılığını, kendi yedeğinizi otomatikleştirecek gerçek komutları ve — en çok atlanan adım — geri yükleme provasını göstereceğim.

Sağlayıcı Yedeği Nedir, Sözleşmede Ne Yazar#

Hosting firmalarının aldığı yedek genellikle operasyonel yedektir: firmanın kendi altyapısını kurtarabilmesi için aldığı, sunucu çöktüğünde hizmeti ayağa kaldırmaya yarayan yedektir. Sizin "dün yanlışlıkla ürün kategorimi sildim, geri alır mısınız" talebiniz için tasarlanmamıştır — çoğu zaman o iş de görülür, ama tasarım amacı bu değildir.

Bu ayrım sözleşmeye şu tür maddelerle yansır. Neredeyse her sağlayıcının hizmet şartlarında benzer bir cümle bulunur:

Yedekleme hizmeti bir garanti değildir. Müşteri, kendisine ait tüm veri ve içeriğin yedeğini almakla yükümlüdür. Sağlayıcı, yedeklerin eksiksizliğinden, güncelliğinden veya geri yüklenebilirliğinden sorumlu tutulamaz.

Bu madde kötü niyetli değildir; teknik gerçeğin hukuki ifadesidir. Bir sağlayıcı, üzerinde binlerce hesap barındıran bir sunucuda her hesabın her dosyasının her sürümünü sonsuza kadar tutmayı taahhüt edemez. Ettiği anda depolama maliyeti hizmeti sürdürülemez kılar.

Sözleşmeyi okurken şu üç ifadeyi arayın:

1. "Yedek alınabilir" / "alınmaktadır" — taahhüt değildir, mevcut durumu tarif eder.
2. "Sorumlu tutulamaz" — geri yükleme başarısız olursa tazminat yolu kapalıdır.
3. "Müşterinin yükümlülüğündedir" — sorumluluk açıkça size verilmiştir.

Hosting satın alırken sözleşmenin bu bölümünü okumak, paket karşılaştırmasının bir parçası olmalı. Satın alma sürecinde nelere bakılacağını hosting nasıl satın alınır yazısında topluca ele aldık.

Saklama Süresi: Yedek Kaç Gün Geriye Gider#

Yedeğin varlığı kadar kaç gün geriye gittiği önemlidir. Tipik saklama politikaları şöyle kurgulanır:

Buradaki asıl tehlike, kaybın geç fark edilmesidir. İşte gerçek hayatta olan şey:

Bir sitede zararlı yazılım 12 Mayıs'ta bulaşıyor. Site çalışmaya devam ediyor, kimse fark etmiyor. 4 Haziran'da arama motoru uyarısı gelince fark ediliyor. Sağlayıcının 7 günlük yedeği var — yani en eski yedek 28 Mayıs'a ait ve o yedek zaten enfekte. Temiz bir kopya elinizde yok. Yedek vardı, işe yaramadı.

Aynı senaryo şuralarda da tekrar eder:

• Yanlış yapılandırılmış bir eklenti üç hafta boyunca sipariş tablosunu bozuyor.
• Bir çalışan iki ay önce bir dizini silmiş, kimse görmemiş.
• Veritabanı karakter seti bozulmuş, eski kayıtlar Mayıs'tan beri "ç" gibi görünüyor.

Bu yüzden yedek politikanızda en az bir uzun süreli kopya olmalıdır: ayda bir alınan ve bir yıl saklanan bir arşiv, günlük yedeklerin çözemediği her felaketi çözer.

Yedeğin Siteyle Aynı Sunucuda Durması Neden Yedek Sayılmaz#

Bu, en sık yapılan ve en pahalıya patlayan hatadır. cPanel'den "Tam Yedek" alıp dosyayı /home/kullanici/ altında bırakmak yedek almak değildir. Sebebi basit: yedeğinizle veriniz aynı riski paylaşıyor.

Yedeğin sunucu içinde durması şu senaryoların hiçbirinden sizi korumaz:

• Disk arızası. Diskteki her şey gider, yedek de dahil.
• Hesabın askıya alınması ya da kapatılması. Ödeme sorunu, kaynak aşımı veya kötüye kullanım nedeniyle hesap kapatıldığında dosyalara erişemezsiniz. Bu tablonun nasıl geliştiğini hosting hesabım askıya alındı yazısında anlattık.
• Fidye yazılımı / şifreleme saldırısı. Saldırgan yazma yetkisi olan her dosyayı şifreler; yedek arşiviniz de yazma yetkisi olan bir dosyadır.
• Sunucuya sızma. Siteyi tahrif eden saldırgan çoğu zaman bulduğu yedek arşivlerini de siler. Deface saldırısı sonrası ilk kontrol edilen şeylerden biri budur.
• Kendi hatanız. rm -rf yanlış dizinde çalıştığında ayrım yapmaz.

Yedeğin tanımı şudur: veriyle aynı anda kaybolamayacak bir kopya. Aynı sunucudaki dosya bu tanımı karşılamaz. Aynı sunucudaki farklı bir disk bile kısmen karşılar. Farklı bir makinede, tercihen farklı bir ağda duran kopya karşılar.

Bunu hemen kontrol edin — yedeklerinizin nerede durduğunu görün:

# Ana dizinde duran yedek arşivleri
find /home/kullanici -maxdepth 2 -name "*.tar.gz" -o -name "*.sql" -o -name "*.zip" | head -20

# Ne kadar yer kaplıyor
du -sh /home/kullanici/backup* 2>/dev/null

Çıktıda dosyalar görüyorsanız, o dosyaların bir kopyasının sunucu dışında olduğundan emin olun.

Geri Dönüş Ücreti ve Süresi#

Yedeğin var olması, ona ulaşmanın ücretsiz ve hızlı olduğu anlamına gelmez. Pratikte üç farklı model görürsünüz:

1. Self-servis geri yükleme. Panelinizden kendiniz seçip geri yüklersiniz. En iyi senaryodur: ücretsizdir, dakikalar sürer ve gece yarısı da çalışır. cPanel tarafında bu genellikle JetBackup benzeri bir arayüzle sunulur; kullanımını JetBackup geri yükleme yazısında adım adım anlattık.

2. Talep üzerine geri yükleme. Destek talebi açarsınız, ekip yedeği yükler. Burada iki değişken vardır: cevap süresi ve ücret. Kritik bir e-ticaret sitesinde cumartesi gecesi açılan bir talebin pazartesi sabahı cevaplanması, geri yükleme ücretsiz olsa bile size kaybettirir.

3. Ücretli geri yükleme. Bazı sağlayıcılar, özellikle düşük fiyatlı paketlerde, yedekten dönüşü ayrı bir hizmet olarak ücretlendirir. Sözleşmede "restore ücreti" ya da "yedek geri yükleme bedeli" ifadesini arayın.

Satın alma öncesi sorulacak dört soru şudur:

1. Yedek kaç gün geriye gidiyor?
2. Geri yüklemeyi ben mi yapıyorum, talep mi açıyorum?
3. Geri yükleme ücretli mi?
4. Tek bir dosyayı ya da tek bir veritabanını seçebiliyor muyum, yoksa hesabın tamamı mı geri dönüyor?

Dördüncüsü fark yaratır: 40 GB'lık bir hesabın tamamını geri yüklemek, dün eklenen 300 siparişi de silmek demektir. Seçmeli geri yükleme olmayan bir yedek, çoğu vakada kullanılamaz.

3-2-1 Kuralının Hostingteki Karşılığı#

3-2-1 kuralı kurumsal yedeklemenin standardıdır: 3 kopya, 2 farklı ortam, 1 tanesi tesis dışında. Kulağa büyük ölçekli geliyor ama tek bir WordPress sitesinde bile birebir uygulanabilir:

Pratik bir kurulum şöyle görünür:

• Kopya 1: Canlı site (yedek değil, korunan şey).
• Kopya 2: Sağlayıcının günlük yedeği — yakın tarihli hataları hızlı geri almak için.
• Kopya 3: Sizin haftalık otomatik yedeğiniz, uzak bir sunucuya ya da kendi diskinize iniyor. Ayda bir alınan kopyalar bir yıl saklanıyor.

Bu üçlünün her biri farklı bir felaket tipini karşılar. Sağlayıcı yedeği dünkü hatayı, sizin haftalık yedeğiniz sunucu erişiminizi tamamen kaybettiğiniz durumu, aylık arşiv ise geç fark edilen bozulmayı çözer.

Kendi Yedeğinizi Almanın Pratik Yolları#

Kendi yedeğinizin üç bileşeni olmalı: dosyalar, veritabanı ve yapılandırma (DNS kayıtları, e-posta hesapları, cron görevleri).

Panelden manuel tam yedek#

En basit yol cPanel üzerinden Files → Backup → Download a Full Account Backup adımıdır. Arşiv üretilir, e-posta ile haber verilir, indirirsiniz. Ayrıntılı kullanımı cPanel yedekleme yazısında. Bu yöntemin tek sorunu manuel olmasıdır — insan unutur.

Veritabanı dökümü#

Veritabanı sitenin gerçek içeriğidir; dosyalar çoğu zaman yeniden kurulabilir ama veriler kurulamaz.

mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
  --routines --triggers \
  -u db_kullanici -p db_adi | gzip > /home/kullanici/yedek/db-$(date +%F).sql.gz

--single-transaction InnoDB tablolarında siteyi kilitlemeden tutarlı bir döküm alır, --default-character-set=utf8mb4 Türkçe karakterlerin bozulmasını engeller. Ayrıntılı seçenekler için mysqldump ile veritabanı yedekleme yazısına bakın.

Dosyaları uzak sunucuya senkronlamak#

rsync yalnızca değişen dosyaları gönderdiği için günlük çalıştırmak ucuzdur:

rsync -az --delete \
  --exclude 'wp-content/cache/' \
  --exclude '*.log' \
  -e "ssh -p 22 -i /root/.ssh/yedek_key" \
  /home/kullanici/public_html/ \
  yedek@uzak-sunucu:/yedekler/alanadiniz/dosyalar/

Kullanım ayrıntıları ve dönüşümlü (rotasyonlu) kurgular için rsync ile yedekleme yazısı iyi bir referanstır.

Otomatikleştirme: cron görevi#

Manuel yedek, alınmayan yedektir. Cron'a bağlayın:

# crontab -e
# Her gece 03:30 veritabanı dökümü
30 3 * * * /usr/bin/mysqldump --single-transaction --default-character-set=utf8mb4 -u db_kullanici -p'SIFRE' db_adi | gzip > /home/kullanici/yedek/db-$(date +\%F).sql.gz

# Her gece 04:00 dosyaları uzak sunucuya gönder
0 4 * * * /usr/bin/rsync -az --delete -e "ssh -i /root/.ssh/yedek_key" /home/kullanici/public_html/ yedek@uzak-sunucu:/yedekler/alanadiniz/dosyalar/

# 30 günden eski yerel dökümleri sil
15 5 * * * /usr/bin/find /home/kullanici/yedek -name "db-*.sql.gz" -mtime +30 -delete

Cron çıktısını mutlaka izleyin. Sessizce başarısız olan bir yedek görevi, hiç yedek almamaktan daha tehlikelidir çünkü size sahte bir güven verir. Basit bir kontrol:

ls -lh /home/kullanici/yedek/ | tail -5

Son dosyanın tarihi dünse iyisiniz; üç hafta öncesiyse cron çalışmıyor demektir.

Yapılandırmayı da yazın#

Yedeğinizin yanına düz bir metin dosyası koyun ve şunları yazın: alan adı kayıt firması, nameserver'lar, tüm DNS kayıtları (A, MX, TXT, CNAME), e-posta hesapları listesi, kullanılan PHP sürümü, aktif eklenti listesi. Sıfırdan kurulum yapmak zorunda kaldığınızda bu dosya, arşivin kendisi kadar değerlidir.

Yedeği Test Etmeyen Yedek Almamıştır#

Yedeklemenin en çok atlanan adımı geri yükleme provasıdır. Sahada gördüğüm başarısız geri dönüşlerin sebepleri hemen her zaman aynıdır:

• Arşiv bozuk indi, açılmıyor.
• Veritabanı dökümü boş (0 bayt) ya da yarım — çünkü cron'daki şifre yanlıştı ve hata kimseye gitmedi.
• wp-config.php yedeğe dahil değil çünkü hariç tutma kuralında *.php vardı.
• Yükleme dizini (wp-content/uploads) hariç tutulmuş, tüm görseller yok.
• Karakter seti uyumsuz, Türkçe karakterler bozuk geri gelmiş.

Bunları öğrenmenin doğru zamanı kriz anı değildir. Üç ayda bir 20 dakikalık bir prova yapın:

1. Arşivin bütünlüğünü doğrulayın:

gzip -t db-2026-08-11.sql.gz && echo "SQL arşivi saglam"
tar -tzf site-2026-08-11.tar.gz > /dev/null && echo "Dosya arsivi saglam"

2. Dökümün gerçekten dolu olduğunu kontrol edin:

zcat db-2026-08-11.sql.gz | grep -c "INSERT INTO"
zcat db-2026-08-11.sql.gz | tail -3

Son satırda -- Dump completed görüyorsanız döküm tam bitmiştir. Görmüyorsanız yarıda kesilmiştir.

3. Geçici bir alt alan adı ya da yerel bir ortam açıp yedeği gerçekten yükleyin. Ana sayfa açılıyor, giriş yapılabiliyor, bir ürün sayfası geliyorsa yedeğiniz gerçek yedektir.

Bu provayı bir kez yapan herkes en az bir eksik bulur. Beklenen sonuç budur; provanın amacı da tam olarak o eksiği kriz öncesinde bulmaktır.

Hangi Felaket Hangi Yedekle Çözülür#

Tablo şunu söylüyor: sağlayıcı yedeği kısa vadeli hataların çoğunu çözer ve gerçekten değerlidir. Ama uzun vadeli bozulmalar ve erişim kaybı senaryolarında tek başına yetmez. Kaybettiğiniz bir siteyi kurtarma yollarının tamamını silinen web sitesi nasıl kurtarılır yazısında topladık; oradaki yöntemlerin çoğunun elinizde bir kopya olmasına bağlı olduğunu göreceksiniz.

Sıkça Sorulan Sorular#

Hosting firmaları gerçekten yedek alıyor mu#

Çoğu firma alıyor, ancak bu yedek öncelikle firmanın kendi altyapısını kurtarmak için tasarlanmıştır. Sizin tek bir dosyayı geri istemeniz genellikle mümkündür ama sözleşmede taahhüt edilmemiş olabilir. Satın almadan önce saklama süresini, geri yüklemenin self-servis mi talep üzerine mi olduğunu ve ücretlendirilip ücretlendirilmediğini açıkça sorun. Bu üç bilginin yazılı cevabı, "yedek alıyoruz" cümlesinden çok daha değerlidir.

Yedek kaç gün geriye gitmeli#

Günlük yedeklerin 7 gün geriye gitmesi çoğu operasyonel hata için yeterlidir, ancak tek başına yetersizdir. Geç fark edilen bozulmalar ve zararlı yazılım bulaşmaları için ayda bir alınan ve en az bir yıl saklanan uzun süreli bir arşive de ihtiyacınız vardır. Pratik bir kurgu şudur: günlük 7, haftalık 4, aylık 12 kopya. Bu şema hem yeni hataları hem de aylar öncesine dönme ihtiyacını karşılar.

Yedeğimi kendi sunucumda tutmam yeterli mi#

Yeterli değildir. Yedeğin tanımı, korunan veriyle aynı anda kaybolamayacak bir kopya olmasıdır; aynı sunucudaki arşiv disk arızasında, hesap kapanmasında, sunucuya sızmada ve fidye yazılımında veriyle birlikte gider. Yedeği en az bir kopya hâlinde farklı bir makinede, tercihen farklı bir ağda tutmalısınız. Kendi bilgisayarınıza indirdiğiniz haftalık bir arşiv bile hiçbir şeyden iyidir.

Sağlayıcı yedeğinden geri dönüş ücretli mi#

Sağlayıcıya ve pakete göre değişir. Bazı hizmetlerde panelden self-servis geri yükleme ücretsizdir, bazılarında destek ekibinin yaptığı geri yükleme ayrı bir bedel olarak faturalanır. Ayrıca ücret olmasa bile cevap süresi bir maliyettir: hafta sonu açılan bir talebin pazartesi cevaplanması ticari bir sitede ciddi kayıp demektir. Sözleşmede "restore" veya "yedek geri yükleme bedeli" ifadelerini arayın.

Yedeğimin çalıştığını nasıl anlarım#

Yalnızca gerçekten geri yükleyerek anlarsınız. Arşivin bütünlüğünü gzip -t ve tar -tzf ile doğrulayın, veritabanı dökümünün son satırında dökümün tamamlandığı bilgisini arayın ve içindeki INSERT satırı sayısına bakın. Ardından geçici bir alt alan adına ya da yerel bir ortama yedeği gerçekten yükleyip siteyi gezin. Üç ayda bir yapılan bu prova, kriz anında yaşayacağınız sürprizlerin neredeyse tamamını önceden yakalar.

3-2-1 kuralı küçük bir site için abartı değil mi#

Değil, çünkü küçük sitede uygulaması da küçüktür. Canlı siteniz birinci kopya, sağlayıcının günlük yedeği ikinci kopya, haftada bir kendi bilgisayarınıza indirdiğiniz arşiv üçüncü kopyadır. Bu üçüncü kopya aynı zamanda "tesis dışı" şartını karşılar ve size sadece birkaç dakika ile birkaç yüz megabayt alana mal olur. Kural karmaşık altyapı değil, tek bir alışkanlık gerektirir.

Yedek alırken neleri dahil etmeliyim#

Dosyalar, veritabanı ve yapılandırma olmak üzere üç bileşeni de almalısınız. Dosya tarafında gizli dosyaları (.htaccess, wp-config.php gibi) ve yükleme dizinini mutlaka dahil edin; önbellek ve log dizinlerini hariç tutabilirsiniz. Veritabanı dökümünü doğru karakter setiyle alın. Yapılandırma tarafında DNS kayıtlarınızı, e-posta hesap listenizi, cron görevlerinizi ve kullandığınız PHP sürümünü düz bir metin dosyasına yazıp arşivin yanına koyun; sıfırdan kurulum gerektiğinde bu not arşiv kadar değerlidir.

Otomatik yedek görevim çalışmıyorsa nasıl fark ederim#

Yedek dizininin son değişiklik tarihini düzenli kontrol ederek fark edersiniz; en son dosya bugüne ya da düne ait değilse görev çalışmıyordur. Cron çıktısını bir dosyaya yazdırmak ya da e-posta olarak almak da erken uyarı sağlar. Bir adım ilerisi, yedek boyutunu izlemektir: her gün 400 MB olan arşiv bir gün 2 KB düştüyse döküm başarısız olmuş demektir. Sessizce başarısız olan bir yedek görevi, hiç yedek almamaktan daha risklidir çünkü size yanlış bir güven verir.

Kapanış#

Hosting firmasının yedeği değersiz değildir — dün yapılan bir hatayı geri almanın en hızlı yolu genellikle odur. Ama bir garanti değildir ve sözleşme bunu zaten açıkça yazar. Yedek politikanızı kurarken sorulacak sorular teknik değil, pratiktir: kaç gün geriye gidiyor, ona kim ulaşabiliyor, geri dönüş ne kadar sürüyor ve o kopya sitenizle aynı riski mi paylaşıyor. Bu dört sorunun cevabı "bilmiyorum" ise, elinizde bir yedek stratejisi değil bir umut vardır. Haftada bir çalışan bir cron görevi ve üç ayda bir yapılan yirmi dakikalık bir geri yükleme provası, bu tabloyu tamamen değiştirir.

Yedeği kendiniz kurgulamak yerine otomatik ve sunucu dışında saklanan bir çözüm istiyorsanız yedekleme hizmeti tam olarak bu boşluğu doldurur ve arşivi sitenizle aynı riski paylaşmayan bir yerde tutar. Yedekleme ve geri yükleme arayüzünün hazır geldiği bir ortam arıyorsanız paylaşımlı hosting paketlerinde panel üzerinden bu işlemleri kendiniz yapabilirsiniz; kendi yedek şemanızı komutlarla kurgulamak ve dilediğiniz sıklıkta anlık görüntü almak istiyorsanız root erişimi olan bir sanal sunucu daha esnek bir zemin sunar. WordPress sitenizin güncelleme, yedek ve geri yükleme döngüsünü tamamen devretmek isterseniz WordPress bakım hizmeti bu işi düzenli bir takvime bağlar.