Havacılık eğitimlerinde ve paraşüt atlayışlarında her sporcunun omuriliğine kazınan çok katı bir hayatta kalma kuralı vardır.

Uçağın kapısından dört bin metre yükseklikte boşluğa atlayan bir paraşütçünün sırtında iki çanta bulunur: Ana paraşüt ve yedek paraşüt. Paraşütçü gökyüzünde süzülürken "Nasıl olsa sırtımda yedek paraşütüm var, bana bir şey olmaz" diyerek kendini güvende hisseder.

Fakat o yedek paraşüt son iki yıldır hiç açılmamışsa, nemli bir depoda fareler tarafından kemirilmişse, katlama protokollerine göre katlanmamış ve ipleri düğümlenmişse ne olur?

Bin metre irtifada ana paraşüt açılmadığında paraşütçü panikle göğsündeki kırmızı mandalı çeker: Yedek paraşüt fırlar; fakat açılmaz, ipleri birbirine dolanır ve paraşütçü saatte iki yüz kilometre hızla yere çakılır.

Havacılığın kanla yazılmış en temel dersi şudur: Daha önce yere inişi bizzat test edilmemiş bir yedek paraşüt, bir kurtarıcı değil; sadece sahte bir özgüven aşılayan ağır bir kumaş parçasıdır.

Web hosting sektöründe, veritabanı yönetiminde ve bilişim dünyasında da her gün yüzlerce şirketin dijital ölümüne sebep olan, ofisleri mezar sessizliğine gömen en trajik kabus tam olarak budur: "Yedeğimiz Vardı" Zanneden Müşterinin "Restore" (Geri Yükleme) Anında Karşılaştığı Korkunç Sessizlik.

Bir Tıklamayla Buharlaşan On Yıllık Şirket Hafızası

Olaylar genellikle sıradan bir salı günü öğleden sonra, çok basit bir insan hatasıyla başlar:

Şirketin genç yazılımcısı phpMyAdmin paneline girer. Test veritabanını temizlemek isterken yanlışlıkla canlı prodüksiyon veritabanını seçer ve o meşhur butona basar: DROP DATABASE.
Ya da şirket sahibi WordPress sitesine yeni bir muhasebe eklentisi kurarken bir hata oluşur ve sitenin tüm ürünler, siparişler ve müşteri kayıtları tablosu bozulur (corrupt).

On yıllık şirket verisi, faturalar, cari hesaplar, müşteri bakiyeleri bir saniyede buharlaşmıştır!

Şirket patronu panikle koltuğundan fırlar. Yüzü bembeyazdır. Fakat içindeki o sahte güven duygusu hala canlıdır: "Neyse ki hosting firmamız var! Onlar her gece sunucunun yedeğini alıyor, hemen arayın dünkü yedeği geri yüklesinler (restore etsinler)."

Patron telefona sarılır, hosting firmasını arar veya destek paneline kırmızı ünlemlerle dolu acil bir bilet (ticket) açar:

"Sitemizin veritabanı yanlışlıkla silindi. Lütfen bu sabah saat 04:00'te aldığınız otomatik sistem yedeğini derhal geri yükleyin!"

Ve beş dakika sonra... Hosting firmasından gelen o resmi, soğuk, hukuki yanıt patronun göğsüne bir kurşun gibi saplanır.

Sözleşmedeki Küçük Punto: Madde 7.3

"Sayın Müşterimiz,
Hizmet Satış Sözleşmemizin 7.3 maddesi uyarınca: 'Paylaşımlı hosting hizmetlerinde veri yedekleme ve saklama sorumluluğu tamamen müşteriye aittir. Sağlayıcı olası donanımsal felaketlere karşı haftalık periyodik imajlar alabilir; ancak alınan yedeklerin bütünlüğünü, çalışabilirliğini ve veri kaybı yaşanmayacağını hiçbir koşulda taahhüt etmez.'
Sistemlerimiz incelendiğinde hesabınıza ait güncel bir geri yükleme noktası bulunamamıştır."

Patronun başı döner. Kulakları çınlamaya başlar: "Nasıl yani?! Ben size her yıl para ödüyorum, benim yedeklerimi almıyor musunuz?!"

Almıyorlar. Çünkü yıllık 100-200 liraya satılan paylaşımlı bir hosting paketinde; 500 müşterinin yüzlerce gigabaytlık verisini her gece harici depolama ünitelerine yedeklemek, o yedekleri tek tek test etmek ve saklamak devasa bir depolama ve lisans maliyetidir.

Hosting firmaları o yedekleri şirket için değil; sadece sunucunun tüm diskleri patlarsa kendi altyapılarını ayağa kaldırmak için toplu imajlar halinde alırlar. Müşterinin tek bir tablosunu kurtarmak onların sorumluluk alanında değildir.

Bozuk Arşiv Faciası: Yedeğin Var Ama Aslında Yok!

Yine de bazen şans yüzünüze güler gibi olur. Hosting firmasının iyi niyetli bir destek personeli çıkar: "Ahmet Bey, ana backup sunucumuza baktım. Şanslısınız, geçen pazar gecesinden kalma bir cPanel yedek arşiviniz (backup-4.12.2026.tar.gz) duruyor. Boyutu 4.2 GB. İsterseniz bunu sunucunuza restore edebilirim."

Ofiste bir bayram havası eser! Patron rahat bir nefes alır: "Oh çok şükür, sadece iki günlük veri kaybettik, en azından 10 yılımız kurtuldu!"

Mühendis terminalden geri yükleme komutunu çalıştırır: tar -zxvf backup-4.12.2026.tar.gz

Ve restorasyonun ortasında, saat 16:45'te o tarihi ölüm fermanı konsola basılır: gzip: stdin: unexpected end of file tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now MySQL import error: Table 'musteriler' doesn't exist / Corrupted SQL dump file.

Yedek dosyası bozuktur! Geçen pazar gecesi o yedek alınırken sunucunun yedekleme diski dolmuş ve sistem yedeği yarım bırakarak arşivi kapatmıştır! Dosyanın boyutu 4 GB görünmektedir; fakat içi boş, bozuk ve yarım yamalak bir veri çöpüdür.

Veritabanı geri yüklenemez. Şirketin on yılı sonsuza kadar yok olmuştur. Ofise çöken o ölüm sessizliğini, çalışanların birbirine çaresizce bakışını hiçbir kelime tarif edemez.

Schrödinger'in Yedeği: Test Edilmemiş Yedek Yok Hükmündedir

Bilişim dünyasında sistem mühendislerinin çok acı bir aforizması vardır: "Schrödinger'in Yedeği: Alınan bir yedeğin sağlam olup olmadığını, ancak onu geri yüklemeye (restore) çalıştığınız an anlarsınız. Test edilene kadar o yedek aynı anda hem vardır, hem yoktur."

Bir şirketin yedekleme stratejisi dosya kopyalamaktan ibaret olamaz.

Dünyanın kabul ettiği altın standart "3-2-1 Yedekleme Kuralı"dır:

3 Kopya: Verinizin en az 3 farklı kopyası olmalıdır (1 prodüksiyon + 2 yedek).
2 Farklı Medya: Bu kopyalar en az 2 farklı depolama türünde tutulmalıdır (örneğin biri yerel SSD, biri NAS veya Bulut Depolama).
1 Harici Lokasyon: En az 1 kopya, ana sunucunun bulunduğu veri merkezinden tamamen bağımsız, coğrafi olarak farklı bir lokasyonda (örneğin AWS S3, Wasabi veya Google Cloud) saklanmalıdır.

Ve bu kuralın en hayati dördüncü maddesi şudur: Ayda bir kez o yedek başka bir boş sunucuya geri yüklenmeli ve sitenin, veritabanının tıkır tıkır ayağa kalktığı gözlerle doğrulanmalıdır!

Dijital Hayatınızı Şansa Bırakmayın

Bir web siteniz, bir e-ticaret girişiminiz veya bir şirketiniz varsa; şu andan itibaren şu gerçeği kabul etmek zorundasınız:

Hosting firmanız sizin babanızın şirketi değildir; sözleşmede yazan madde neyse kanun odur. Hiçbir hosting firması sizin verinizi sizin kadar önemsemez.
Kendi yedeğinizi kendiniz almak zorundasınız: Her cuma günü cPanel'e girip tam bir "Full cPanel Backup" indirin veya sitenize otomatik olarak Google Drive'a / Amazon S3'e yedek atan bağımsız eklentiler (UpdraftPlus, Duplicator vb.) kurun.
O yedeği bilgisayarınızın yerel diskine çekin; sunucuda bırakılan yedek, sunucu yandığında sunucuyla birlikte yanar.

Tıpta yere inişi test edilmemiş paraşütle atlayan sporcu yere çakılır.

Bilişimde de "firmam yedek alıyordur" tembelliğiyle yaşayan patron; bir gün o tek bir yanlış tıkla on yıllık emeğinin, itibarının ve sermayesinin dijital bir mezara gömülüşünü çaresiz gözyaşlarıyla izlemeye mahkûmdur. Verinizi başkasına emanet etmeyin; çünkü giden veriyi hiçbir mahkeme geri getiremez.

Backup

"Yedek Almayı Müşteriye Bırakmak": "Restore" Anındaki Büyük Çaresizlik