Bir sabah sunucu açılmaz, ya da biri yanlışlıkla sipariş tablosunu siler, ya da dosyalarınızın uzantısı değişip bir fidye notu belirir. Aynı anda üç soru gelir: "Yedeğimiz var mı?", "Ne kadarını geri getirebiliriz?" ve "Ne kadar sürer?" Çoğu işletmede ilk cevap "evet", ikinci ve üçüncü cevap ise bir sessizliktir. Çünkü yedek almak ile yedeğe güvenmek aynı şey değildir. Bu rehberde veri yedekleme nasıl yapılır sorusunu, tek bir örnek sistem üzerinden, neyin yedekleneceğinden geri yükleme testine kadar adım adım cevaplıyoruz.
Rehberi bir eğitim gibi kurduk: yedi ders, her biri bir kavram, bir örnek hesap ve bir ders görevi. Örnek sistemimiz, bayi portalının veritabanı: 200 GB veri, günde yaklaşık %3 değişim. Rakamlar temsilidir. Bir yazılım projesini sipariş eden, yöneten ya da işleten biriyseniz, yazının sonunda yazılımcınıza hangi soruları soracağınızı da bileceksiniz.
Veri Yedekleme Nedir?
Veri yedekleme, verinin kaybolma, bozulma, silinme ya da ele geçirilme ihtimaline karşı, asıl veriden bağımsız bir yerde ayrı bir kopyasının tutulması ve gerektiğinde bu kopyadan verinin geri getirilebilmesidir. Yedeğin değeri, asıl veriden ne kadar bağımsız olduğuyla ölçülür.
Üç şey sıkça yedekle karıştırılır. Disk aynalama (RAID) bir diskin bozulmasına karşı korur ama yanlışlıkla silinen kaydı da aynı anda siler. Gerçek zamanlı çoğaltma (replikasyon) sistemi ayakta tutar ama bozulmuş ya da şifrelenmiş veriyi de yedek sunucuya hızla kopyalar. Bulut klasörü eşitleme dosyayı başka bir yere koyar ama bir dosya silindiğinde ya da şifrelendiğinde bu değişiklik eşitlenir. Üçü de sürekliliği sağlar, ama geçmişe dönüş sağlamaz; yedek ise belirli bir andaki "temiz" hâle dönmenizi sağlar.
Okumanızı öneririz: Web yazılım hizmetimiz: güvenli barındırma, yetki ve denetim kayıtlarıyla
Bu Rehberi Nasıl Kullanmalısınız?
Dersleri sırayla izleyin; her ders bir öncekinin sonucunu kullanır.
| Ders | Konu | Sonunda yapabildiğiniz |
|---|---|---|
| 1 | Veri envanteri ve kritiklik | Neyin ne kadar sık yedekleneceğine karar vermek |
| 2 | RPO ve RTO | Kabul edilebilir veri kaybını ve kesinti süresini rakama dökmek |
| 3 | 3-2-1 kuralı | Yedeğin kaç kopyasının nerede duracağını belirlemek |
| 4 | Yedek türleri ve depolama | Tam, artımlı ve fark yedeği arasında seçmek, depolama ihtiyacını hesaplamak |
| 5 | Yedeği korumak | Yedeği fidye yazılımına ve yetkisiz erişime karşı güvenceye almak |
| 6 | Geri yükleme testi | Gerçek kurtarma süresini ölçmek |
| 7 | Maliyet–fayda ve yazılı plan | Yedekleme yatırımını rakamla savunmak |
Ders 1: Neyi Yedekleyeceğinize Nasıl Karar Verirsiniz?
Yedeklemenin ilk adımı, işletmenin hangi verilere sahip olduğunu ve bu verilerin kaybolması hâlinde ne olacağını yazmaktır: veri envanteri. Her veri aynı sıklıkta yedeklenmez; kritik veri sık ve hızlı geri getirilecek biçimde, kolay yeniden üretilebilen veri seyrek yedeklenir.
| Veri | Kaybolursa ne olur? | Kritiklik | Yedekleme yaklaşımı |
|---|---|---|---|
| Sipariş, cari ve stok veritabanı | İş durur, kayıtlar yeniden üretilemez | Çok yüksek | Sık ve ek konumda yedek; hızlı geri yükleme |
| Faturalar ve mali belgeler | Yasal saklama yükümlülüğü, mali kayıp | Çok yüksek | Sık yedek, uzun saklama (süreyi mali müşavirinizle belirleyin) |
| Müşteri ve bayi belgeleri | Sözleşme ve teslimat belgelerinin kaybı | Yüksek | Günlük yedek |
| Yazılımın kaynak kodu ve ayarları | Sistemin yeniden kurulamaması | Yüksek | Sürüm yönetimi ve ayrı yedek |
| Kayıt (log) dosyaları | İzlenebilirlik kaybı | Orta | Haftalık yedek ya da merkezi kayıt sistemi |
| Geçici ve önbellek verisi | Kolayca yeniden üretilir | Düşük | Genellikle yedeklenmez |
Envanter yalnızca sunucuyu kapsamamalıdır: çalışanların Excel dosyaları, e-posta kutuları ve bulut hizmetlerindeki (muhasebe, CRM, e-ticaret) veriler de aynı soruya tabidir: "Bunu kaybedersek ne olur ve geri getirmek için elimizde ne var?"
Ders 2: RPO ve RTO Nedir, Nasıl Hesaplanır?
RPO (Recovery Point Objective, hedef kurtarma noktası), olay anında kaybetmeyi göze aldığınız en uzun veri süresidir; RTO (Recovery Time Objective, hedef kurtarma süresi) ise olay anından sistemin yeniden çalışmasına kadar kabul ettiğiniz en uzun süredir. İkisi birlikte yedekleme stratejinizi belirler.
RPO yedek sıklığını gösterir: günde bir yedek alıyorsanız RPO 24 saattir, çünkü olay yedeğin hemen öncesine denk gelirse bir günlük veri kaybolur. RTO ise geri yükleme yönteminin hızını gösterir: yedeğin yerinden bulunması, sunucunun kurulması, verinin geri yüklenmesi ve doğrulanması ne kadar sürüyorsa RTO odur.
Hedefleri koyarken iş birimine şu iki soruyu sorun: "En çok kaç saatlik veriyi kaybetmeyi göze alabilirsiniz?" ve "Sistem en çok kaç saat kapalı kalabilir?" Cevap, bayi portalı için günün saatine göre değişebilir; kampanya sabahı ile cuma akşamı aynı değildir. Örnekte portalın iş saatlerinde ortalama saatte ₺35.000 sipariş değeri taşıdığını varsayalım. İki senaryoyu karşılaştıralım:
| Senaryo | RPO | RTO | Olay başına üst sınır: (RPO + RTO) × ₺35.000 |
|---|---|---|---|
| A: günlük yedek, elle kurtarma | 24 saat | 24 saat | 48 × ₺35.000 = ₺1.680.000 |
| B: saatlik yedek, hazır kurtarma planı | 1 saat | 4 saat | 5 × ₺35.000 = ₺175.000 |
Bu hesap bir üst sınır tahminidir: kaybolan siparişlerin bir kısmı bayilerden yeniden alınabilir, kesinti sırasında bazı işler ertelenebilir. Ama büyüklük farkı nettir: aynı olay, hazırlıklı bir işletmede yaklaşık onda biri kadar bir maliyet yaratır.
Ders 3: 3-2-1 Yedekleme Kuralı Nedir?
3-2-1 kuralı şunu söyler: verinin en az üç kopyası olsun (asıl veri ve iki yedek), bu kopyalar iki farklı depolama türünde tutulsun ve bir kopya farklı bir konumda (başka bir bina, şehir ya da bulut) bulunsun. Amaç, tek bir olayın hem veriyi hem de yedeği aynı anda yok edememesidir.
| Kural | Anlamı | Karşıladığı risk |
|---|---|---|
| 3 kopya | Asıl veri + iki bağımsız yedek | Bir kopyanın bozulması ya da hatalı çıkması |
| 2 farklı tür | Örneğin sunucu diski ve ayrı bir yedek depolaması ya da bulut | Aynı tür depolamayı etkileyen arıza ya da hata |
| 1 uzak konum | Başka bir bina, şehir ya da bulut bölgesi | Yangın, su baskını, hırsızlık, bina erişilmezliği |
Kuralın günümüzde sık kullanılan genişletilmiş hâli 3-2-1-1-0'dır: bir kopya çevrimdışı ya da değiştirilemez (immutable) olsun ve yedeklerin hatasız geri yüklenebildiği doğrulansın (sıfır hata). Birinci ek, fidye yazılımına karşı; ikincisi, yedeğe güvenmeden önce onu sınamak içindir.
Ders 4: Hangi Yedek Türü Seçilmeli ve Depolama Ne Kadar Gerekir?
Yedek türü, her seferinde neyin kopyalandığını belirler: tam yedek bütün veriyi, artımlı yedek son yedekten beri değişeni, fark yedeği son tam yedekten beri değişeni kopyalar. Seçim; depolama alanı, yedekleme süresi ve geri yükleme kolaylığı arasında bir dengedir.
| Tür | Neyi kopyalar? | Depolama ve süre | Geri yüklemede gereken parça |
|---|---|---|---|
| Tam (full) | Tüm veri | En çok yer, en uzun süre | Tek parça; en kolay |
| Artımlı (incremental) | Son yedekten (tam ya da artımlı) beri değişen | En az yer, en kısa süre | Son tam yedek + aradaki tüm artımlılar |
| Fark (differential) | Son tam yedekten beri değişen | Orta yer; her gün biraz büyür | Son tam yedek + son fark; iki parça |
Örnek sistemimizde veri 200 GB ve günde %3 değişiyor: günlük değişim 200 × 0,03 = 6 GB. Dört haftalık (28 gün) saklama için üç stratejiyi karşılaştıralım. Haftanın ilk günü tam yedek alınıyor, kalan altı gün artımlı ya da fark yedeği.
| Strateji | Hesap | 4 haftalık depolama |
|---|---|---|
| Her gün tam yedek | 28 × 200 GB | 5.600 GB |
| Haftalık tam + günlük fark | 4 × (200 + 6 + 12 + 18 + 24 + 30 + 36) = 4 × 326 | 1.304 GB |
| Haftalık tam + günlük artımlı | 4 × (200 + 6 × 6) = 4 × 236 | 944 GB |
Artımlı strateji, her gün tam yedeğe göre yaklaşık altıda bir yer kaplıyor (944 ÷ 5.600 ≈ 0,17). 3-2-1 kuralı için iki yedek kopya gerektiğinden depolama ihtiyacı iki katına çıkar: 944 × 2 = 1.888 GB, yaklaşık 1,9 TB. Gerçekte sıkıştırma ve tekilleştirme bu boyutu belirgin biçimde düşürebilir; ama planı yapacağınız üst sınırı bilmek için hesabı sıkıştırmasız yapın.
Bedeli ise geri yüklemede ödersiniz: artımlı yedekte en kötü günde (altıncı artımlı) son tam yedek ve altı artımlı, yani yedi parça sırayla geri yüklenmelidir; zincirdeki bir parça bozuksa sonrası da kullanılamaz. Fark yedeğinde her zaman iki parça yeter. RTO hedefi çok kısaysa fark yedeği ya da daha sık tam yedek tercih edilir.
Okumanızı öneririz: SaaS nedir? Yedekleme ve izleme sorumluluğu kimde?
Ders 5: Yedekler Fidye Yazılımına ve Yetkisiz Erişime Karşı Nasıl Korunur?
Fidye yazılımı saldırılarında yedekler de hedef alınabilir; yedeği olmayan bir işletmenin ödeme baskısı artar. Bu yüzden yedeğin güvenliği, yedeğin kendisi kadar önemlidir.
| Önlem | Ne sağlar? | Nasıl uygulanır? |
|---|---|---|
| Yedeği ağdan ayırmak | Saldırgan asıl sisteme girse bile yedeğe ulaşamaz | Yedek depolamayı ayrı ağda tutmak, çevrimdışı ya da farklı hesapta saklamak |
| Değiştirilemez (immutable) kopya | Yedek belirli süre silinemez ve değiştirilemez | Yazma-bir-kez ya da saklama kilidi özelliği olan depolama |
| Şifreleme | Yedek çalınsa bile okunamaz | Hem aktarım hem depolama sırasında; anahtar yedekten ayrı yerde |
| Ayrı kimlik bilgileri | Asıl sistemin parolası yedeği açmaz | Yedek yönetimi için ayrı hesap, çok adımlı doğrulama |
| Uyarı ve izleme | Başarısız ya da eksik yedek anında fark edilir | Her yedekten sonra başarı raporu, eksik yedekte uyarı |
Yedekler ve kişisel veri (KVKK)
Yedekler de kişisel veri içerir; bu yüzden asıl veriye uygulanan koruma yükümlülükleri yedeklere de uygulanır. Dikkat edin: yedek şifreli ve erişim kontrollü olmalı, saklama süreleri amaca uygun belirlenmeli (süresi dolan verinin yedekten de nasıl silineceği dahil) ve yedek yurt dışındaki bir bulutta tutuluyorsa aktarım kuralları gözetilmeli. Hukuki ayrıntı için hukuk danışmanınıza başvurun. Test ortamına gerçek müşteri verisi içeren yedek geri yüklemek de risktir; test için örnek ya da anonimleştirilmiş veri kullanın.
Ders 6: Geri Yükleme Testi Nasıl Yapılır?
Geri yükleme testi, yedeklerden gerçekten veri geri getirerek hem yedeğin sağlam olduğunu hem de gerçek kurtarma süresini ölçmektir. Hiç denenmemiş bir yedek ilk kez olay anında denenir; o an yedeğin eksik ya da bozuk olduğu anlaşılırsa artık geç kalınmıştır.
- Senaryo seçin: "Sipariş tablosu yanlışlıkla silindi", "Sunucu tamamen kaybedildi" ve "Dün geceki durumuna dönmek gerekiyor" gibi gerçekçi olaylardan birini seçin.
- Ayrı bir ortama geri yükleyin: Canlı sistemi etkilemeden, test ortamına. Gerçek müşteri verisi içeren yedek kullanılıyorsa ortamın erişimi kısıtlı olsun.
- Süreyi ölçün: Yedeğin bulunmasından, sistemin yeniden çalışıp kontrolden geçmesine kadar geçen süreyi saatle ölçün. Bu, gerçek RTO'nuzdur.
- Veriyi doğrulayın: Kayıt sayılarını, son sipariş tarihini ve birkaç örnek kaydı kaynakla karşılaştırın. Verinin geri yüklenmesi, verinin doğru olduğunu göstermez.
- Gerçek RPO'yu bulun: Geri yüklenen verideki son kaydın zamanı ile olay anı arasındaki fark, fiilen kaybettiğiniz süredir.
- Bulguları kaydedin: Hedeflerle gerçeği karşılaştırın, eksikleri (eksik yedek, bilinmeyen parola, yazılı olmayan adım) listeleyin ve düzeltin.
Örneğin hedef RTO 4 saatken testte 7 saat çıkması iyi bir bulgudur: sorun olay gününde değil test gününde ortaya çıktığı için düzeltilebilir. Testi düzenli aralıklarla (örneğin üç ayda bir) ve büyük değişikliklerden sonra tekrarlayın.
Okumanızı öneririz: Yazılım testi nasıl yapılır? Test senaryosundan hata raporuna
Ders 7: Yedekleme Yatırımı Nasıl Savunulur ve Yedekleme Planı Nasıl Yazılır?
Daha iyi yedekleme ek maliyet getirir; bu maliyet, olayın beklenen yıllık maliyetindeki azalmayla karşılaştırılarak savunulur: Beklenen yıllık kayıp = Yılda olay olasılığı × Olay başına maliyet. Olasılık tahmindir; ama tahmini yazmak, hiç hesaplamamaktan iyidir.
Ders 2'deki iki senaryoyu kullanalım. Yılda ciddi bir olay yaşama olasılığını %20 varsayalım (temsilî). B senaryosu için gereken ek yatırım (saatlik yedek, ikinci konum, izleme ve hazır kurtarma planı) yılda ₺120.000 olsun.
| Kalem | Senaryo A (günlük, elle) | Senaryo B (saatlik, hazır plan) |
|---|---|---|
| Olay başına üst sınır | ₺1.680.000 | ₺175.000 |
| Beklenen yıllık kayıp (%20) | ₺336.000 | ₺35.000 |
| Yıllık ek yedekleme maliyeti | - | ₺120.000 |
| Yıllık toplam (kayıp + maliyet) | ₺336.000 | ₺155.000 |
B senaryosu yıllık beklenen toplam maliyeti ₺181.000 düşürüyor (336.000 − 155.000). Olasılığı %5'e indirseniz de karar değişir: A için ₺84.000 beklenen kayıp, B için ₺8.750 + ₺120.000 = ₺128.750 olur ve bu durumda ek yatırım karşılığını vermez. Bu yüzden hesap, tek bir doğru cevaptan çok, kararın hangi varsayımlara dayandığını görünür kılar.
Yedekleme planını yazılı bir belgeye dökün: kapsam, her sistem için RPO ve RTO, yöntem (tür, sıklık, saklama, kopya ve konumlar), güvenlik önlemleri, sorumluluklar, test sıklığı ve olay günü adımları (kimi arayacağınız, hangi sırayla ne yapılacağı). Plan, yönetimin onayıyla bağlayıcı olur.
Veri Yedeklemede Sık Yapılan Hatalar Nelerdir?
Yedekleme hataları genellikle olay gününe kadar görünmez. En sık görülenler şunlardır:
- Yedeği hiç geri yüklemeyi denememek: Başarılı görünen yedek işi, geri yüklenebilir bir yedek anlamına gelmez.
- Yedeği asıl veriyle aynı yerde tutmak: Aynı sunucuda, aynı odada ya da aynı hesapta duran yedek, aynı olayda birlikte kaybolur.
- Eşitlemeyi yedek sanmak: Silinen ya da şifrelenen dosya eşitlenir; geçmişe dönüş olmayan her çözüm yedek değildir.
- Yedeği şifrelememek ya da anahtarı yanında tutmak: Çalınan yedek, açık bir veri sızıntısıdır.
- Bulut hizmetinin yedeğini sağlayıcıya bırakmak: Sağlayıcı hizmeti ayakta tutar; sizin yanlışlıkla sildiğiniz veriyi geri getirmeyi garanti etmeyebilir. Sözleşmedeki kapsamı okuyun.
Yazılım Tedarikçinize Hangi Yedekleme Sorularını Sormalısınız?
Yazılımınızı bir firma geliştiriyor ya da işletiyorsa, teklif aşamasında şunları sorun ve cevapları sözleşmeye yazdırın: hedeflenen RPO ve RTO nedir; yedekler kaç kopya, hangi türde ve hangi konumlarda tutuluyor; yedekler şifreli mi, kimler erişebiliyor ve silebiliyor; geri yükleme ne sıklıkla test ediliyor ve sonuç size raporlanıyor mu; yedekler ne kadar saklanıyor; yedekleme bakım bedeline dahil mi?
Okumanızı öneririz: Yazılım projesi maliyeti nasıl hesaplanır? Altyapı ve bakım kalemleri
Okumanızı öneririz: Yazılım Bakım ve Destek Sözleşmesi (SLA) Nedir? Kapsam, Süreler ve Ücret Rehberi
Okumanızı öneririz: API güvenliği nasıl sağlanır? Kimlik, yetki, token ve hız sınırı rehberi
Okumanızı öneririz: Rol Bazlı Yetkilendirme (RBAC) Nedir?
Okumanızı öneririz: Veritabanı Nasıl Seçilir?
Okumanızı öneririz: Bulut mu Yerel Sunucu mu?
İnovabil ile Veri Güvenliği ve Yedekleme
İnovabil olarak geliştirdiğimiz yazılımların hizmet kapsamında rol bazlı yetki, denetim kayıtları ve güvenli barındırma gibi güvenlik bileşenleri yer alıyor. Yedekleme ve geri yükleme beklentilerinizi, yani veri kaybı toleransınızı, kabul edebileceğiniz kesinti süresini ve yedeklerin nerede tutulacağını, gereksinim aşamasında birlikte netleştirmenizi ve bunları bakım kapsamına yazılı olarak eklemenizi öneriyoruz.
Projenizin hangi verileri tutacağını ve bir olayda ne kadar kayıp ya da kesintiyi kaldırabileceğinizi birkaç cümleyle anlatın; size özel bir yedekleme ve güvenlik çerçevesi hazırlayalım.
Okumanızı öneririz: Özel yazılım geliştirme hizmetimiz
Sık Sorulan Sorular
Veri yedekleme nasıl yapılır, kısaca hangi adımlardan oluşur?
Önce veri envanteri çıkarılıp kritiklik belirlenir; sonra RPO ve RTO hedefleri konur, 3-2-1 kuralına göre kopyalar ve konumlar planlanır, yedek türü ve depolama ihtiyacı hesaplanır, yedekler şifrelenip erişimi kısıtlanır, geri yükleme düzenli olarak test edilir ve tüm bunlar yazılı bir yedekleme planında toplanır.
3-2-1 yedekleme kuralı nedir?
Verinin en az üç kopyası (asıl veri ve iki yedek) olması, bu kopyaların iki farklı depolama türünde tutulması ve bir kopyanın farklı bir konumda bulunması kuralıdır. Genişletilmiş hâli 3-2-1-1-0'da ayrıca bir kopya çevrimdışı ya da değiştirilemez olur ve yedeklerin hatasız geri yüklendiği doğrulanır.
RPO ve RTO nedir, aralarındaki fark nedir?
RPO, kaybetmeyi göze aldığınız en uzun veri süresidir ve yedek sıklığını belirler. RTO ise olaydan sistemin yeniden çalışmasına kadar kabul ettiğiniz en uzun süredir ve geri yükleme yönteminin hızını belirler. Günlük yedek, 24 saatlik RPO demektir.
Bulut klasörü eşitleme ya da RAID yedek yerine geçer mi?
Hayır. İkisi de sürekliliği sağlar ama geçmişe dönüş sağlamaz: yanlışlıkla silinen ya da fidye yazılımıyla şifrelenen dosya hemen eşitlenir ve aynalanan diske de yansır. Yedek, belirli bir andaki temiz hâle dönmenizi sağlayan bağımsız bir kopyadır.
Geri yükleme testi ne sıklıkla yapılmalıdır?
Test düzenli aralıklarla, örneğin üç ayda bir, ve sistemde büyük bir değişiklikten sonra yapılmalıdır. Sıklık, verinin kritikliğine göre belirlenir. Her testte gerçek kurtarma süresi ve veri doğruluğu ölçülüp hedeflerle karşılaştırılmalı, eksikler giderilmelidir.