--- title: "Yedekleme Var Ama Geri Dönüş Denenmemiş: Kâğıt Üstünde Güvenlik" url: "https://cilginyazilim.com/blog/yedekleme-var-ama-geri-donus-denenmemis" description: "Yedekleme stratejisinde asıl kritik adım geri dönüş testidir. 3-2-1 kuralı, RPO/RTO belirleme, fidye yazılımına karşı değişmez yedek ve tatbikat planı." published: "2026-10-22T10:00:00+03:00" modified: "2026-10-22T10:00:23+03:00" author: "Çılgın Yazılım" category: "Siber Güvenlik" tags: ["test", "veritabanı", "altyapı", "yedekleme", "sistem yönetimi", "risk yönetimi", "olay müdahalesi", "felaket kurtarma", "veri güvenliği", "rpo", "rto", "fidye yazılımı", "iş sürekliliği"] site: "Çılgın Yazılım" language: "tr" --- # Yedekleme Var Ama Geri Dönüş Denenmemiş: Kâğıt Üstünde Güvenlik Yedek almak kolay, geri dönmek zordur. Denenmemiş bir yedek, olduğunu sandığınız bir güvencedir. **Yedekleme** konusunda ekiplerin çoğu kendini güvende hisseder: bir cron görevi vardır, her gece çalışır, bir yere dosya yazar. Sorun şudur ki yedeklemenin asıl amacı dosya üretmek değil, *geri dönebilmektir* — ve bu iki şey birbirinden çok farklıdır. Sahada karşılaşılan en acı olaylar, yedeğin hiç alınmadığı durumlarda değil, alınan yedeğin işe yaramadığı fark edildiği anlarda yaşanır. ![Yedekleme stratejisi kontrol soruları](https://cilginyazilim.com/uploads/blog/2026/07/yedekleme-var-ama-geri-donus-denenmemis-ozet.png) *Bu beş sorudan üçüncüsü cevaplanamıyorsa, diğerlerinin cevabı önemsizdir.* ## Denenmemiş kopyaların tipik arızaları Geri yükleme ilk kez gerçek bir olayda denendiğinde ortaya çıkan sorunlar şaşırtıcı derecede tekrarlıdır: - **Dosya bozuk veya eksik.** Kayıt oluşmuştur ama içeriği yarımdır; işlem sırasında oluşan hata hiçbir yere bildirilmediği için aylardır böyledir. - **Kopya alınıyor ama veritabanı tutarsız.** Çalışan bir veritabanının dosyalarını doğrudan kopyalamak, işlem ortasında yakalanan tutarsız bir durum üretir. Doğrusu, veritabanının kendi aracını kullanmaktır. - **Bir tablo veya dizin kapsam dışı.** Yeni eklenen bir tablo veya yükleme klasörü ilgili betiğe hiç eklenmemiştir. - **Şifreleme anahtarı kayıp.** Dosya şifrelenmiştir, anahtar ise yalnızca kaybedilen sunucudadır. - **Geri yükleme çok uzun sürüyor.** Kayıt sağlamdır ama 400 GB'lık dosyayı indirip açmak 9 saat sürer — oysa iş tarafı 2 saat bekliyordur. Bu arızaların ortak özelliği, yalnızca gerçek bir geri yükleme denemesiyle ortaya çıkmalarıdır. ## Önce iki sayıyı belirleyin: RPO ve RTO Bu strateji teknik bir tercih gibi görünür, ama aslında iki iş kararına dayanır: **RPO (kabul edilebilir veri kaybı):** Bir felaket anında kaç saatlik veriyi kaybetmeyi göze alabilirsiniz? Cevap "hiç" ise gecelik kopya yetmez; sürekli çoğaltma veya sık aralıklı işlem günlüğü kaydı gerekir. Cevap "bir gün" ise gecelik kopya uygundur. **RTO (kabul edilebilir kesinti süresi):** Sistem ne kadar sürede ayağa kalkmalı? Bu sayı, kopyanın nerede saklanacağını belirler: soğuk arşivden geri yükleme ucuzdur ama saatler alır. Bu iki sayı iş tarafıyla birlikte belirlenmediğinde, teknik ekip genellikle gereğinden pahalı veya gereğinden zayıf bir kurulum yapar. ## 3-2-1 kuralı ve fidye yazılımı gerçeği Klasik kural hâlâ geçerlidir: en az **3** kopya, **2** farklı ortamda, **1** tanesi fiziksel olarak başka konumda. Ancak fidye yazılımı tehdidi buna bir madde daha eklemiştir: kopyanın *kaynak sistemden erişilemez* olması. Sunucusu ele geçirilen birçok kurumda kopyalar da şifrelenmiştir, çünkü ilgili disk aynı makineye bağlıdır veya arşiv sunucusuna aynı kimlik bilgileriyle erişilebilmektedir. Bu yüzden bugün beklenen standart, en az bir kopyanın **değiştirilemez (immutable)** veya yalnızca ekleme yapılabilir bir depoda tutulmasıdır. Erişim yetkilerinin ayrıştırılması konusundaki genel yaklaşım için sıfır güven mimarisi yazımıza bakabilirsiniz. ## Geri dönüş tatbikatı nasıl yapılır? Tatbikat karmaşık olmak zorunda değil; düzenli olması yeterlidir. 1. **Takvime alın.** Üç ayda bir, belirli bir tarihte. Planlanmayan tatbikat yapılmaz. 2. **Temiz bir ortama geri yükleyin.** Mevcut sistemin üzerine değil, sıfırdan kurulan bir sunucuya. Amaç yalnızca verinin değil, *sürecin* de çalıştığını görmektir. 3. **Süre tutun.** Geri yüklemenin ne kadar sürdüğünü ölçün ve RTO hedefinizle karşılaştırın. Aradaki fark, kapatmanız gereken açıktır. 4. **Doğrulayın.** Veritabanı ayağa kalktı diye iş bitmez; kayıt sayılarını, en son işlem tarihini ve birkaç kritik iş akışını kontrol edin. 5. **Adımları yazılı hâle getirin.** Geri yükleme prosedürü, olay anında paniğe kapılmış birinin okuyabileceği kadar açık olmalı ve *yedeklenen sistemin dışında* saklanmalıdır. Wiki'niz de aynı sunucudaysa, olay anında ona da erişemezsiniz. 6. **Rotasyonla yaptırın.** Tatbikatı her seferinde aynı kişi yaparsa, o kişi izindeyken sistem savunmasız kalır. ## İzleme: sessiz başarısızlığı yakalamak Bu işlerin en tehlikeli hâli, sessizce başarısız olmalarıdır. Bu yüzden yalnızca "hata olursa haber ver" kurgusu yetersizdir; iş hiç çalışmadığında hiç hata da üretilmez. Doğru kurgu, **başarılı tamamlanma sinyali beklemektir**: iş bittiğinde bir izleme servisine haber verir, belirlenen süre içinde sinyal gelmezse uyarı çıkar. Ayrıca çıktı dosyasının boyutunu izlemek de basit ama etkilidir — beklenenden çok küçük bir dosya, sessiz bir arızanın habercisidir. Bu kontrollerin dağıtım süreciyle bütünleştirilmesi ve geri dönüş yeteneğinin genel çerçevesi için [geri alma planı yazımıza](https://cilginyazilim.com/blog/geri-alma-plani-olmayan-dagitim-dagitim-degildir) bakabilirsiniz. Altyapı kurarken alınması gereken temel kararlar için ise [altyapı kararları yazımız](https://cilginyazilim.com/blog/uygulama-altyapisi-kurarken-alinacak-yedi-karar) tamamlayıcıdır. Güvenlik kontrollerinin genel çerçevesi için [OWASP kaynakları](https://owasp.org/) başvurulabilir. ## Sonuç Bu süreç, alınan dosyaların varlığıyla değil, geri dönüşün denenmiş olmasıyla ölçülür. Bir yedeğin sağlam olduğunu bilmenin tek yolu onu geri yüklemektir; bunun dışındaki her şey varsayımdır. Bugün ekibinize tek bir soru sorun: "En son ne zaman gerçek bir geri yükleme yaptık ve ne kadar sürdü?" Net bir tarih ve net bir süre veremiyorsanız, elinizde bir kurtarma sistemi değil, bir kurtarma umudu var demektir. İyi haber şu ki bu durumu değiştirmek, bir öğleden sonra ayıracağınız ilk tatbikatla başlıyor. ## Sıkça Sorulan Sorular ### Bulut sağlayıcısının otomatik yedeği yeterli mi? Çoğu senaryo için iyi bir temel sağlar, ancak hesabınızın ele geçirilmesi veya yanlışlıkla silinmesi durumunda aynı hesap içindeki yedekler de risk altındadır. En az bir kopyanın ayrı bir hesapta veya sağlayıcıda tutulması önerilir. ### Ne sıklıkla çalıştırmalıyım? Bu tamamen RPO hedefinize bağlıdır. Bir günlük veri kaybı kabul edilebiliyorsa gecelik çalıştırma yeterlidir; kabul edilemiyorsa işlem günlüğü kaydı veya sürekli çoğaltma gerekir. ### Geri yükleme tatbikatı üretimi etkiler mi? Doğru yapıldığında etkilemez, çünkü tatbikat ayrı ve izole bir ortama yapılır. Üretim üzerinde geri yükleme denemesi yapmak ise ciddi risk taşır ve önerilmez. ### Arşivi şifrelemeli miyim? Kişisel veri veya hassas bilgi içeriyorsa evet, özellikle sistem dışında saklanan kopyalar için. Ancak şifreleme anahtarının yedeklenen sistemden bağımsız ve güvenli bir yerde saklandığından mutlaka emin olun. --- Kaynak: [Yedekleme Var Ama Geri Dönüş Denenmemiş: Kâğıt Üstünde Güvenlik](https://cilginyazilim.com/blog/yedekleme-var-ama-geri-donus-denenmemis)