Yazılım ve dijital pazarlamada işletmelere uçtan uca çözümler sunmak üzere kurulan Partnerfy, ajansların ve markaların güvenilir teknoloji ortağıdır.
Geleceği bizimle kodlamaya ne dersin?
"Yedek var mı?" sorusunun cevabı evet olmalı — ama yetmez. Asıl soru: "Geri dönebiliyor muyuz, ne kadar sürede ve ne kadar veri kaybıyla?" Saatlik şifreli yedek, üç kopya iki farklı medya bir off-site, immutable WORM depolama, üç ayda bir gerçek restore tatbikatı ve net RPO/RTO hedefleri — felaket gününde fark eden tek şey budur.
Test edilmemiş bir restore — yedek değil, umuttur. Biz umut satmıyoruz; ölçülebilir kurtarma süreleri ve kanıtlanmış restore raporları teslim ediyoruz.
Birincil sistem düştüğünde ikincil otomatik devralır — gerçek tatbikatlarla doğrulanmış.
İlk acı gerçek: yedeklerin büyük çoğunluğu hiç test edilmiyor. Cron her gece çalışıyor, log dosyasında "OK" yazıyor, monitoring panelinde yeşil ışık var — ama o yedeği gerçekten geri yüklemeye kalktığınızda dosyalar bozuk çıkıyor, şifre çözücü anahtar kayıp veya schema versiyonu uyumsuz. Restore test edilene kadar yedek değildir; sadece umuttur. Biz her müşteride en az üç ayda bir tam restore tatbikatı zorunlu tutuyoruz ve sonucu belgeliyoruz.
İkinci sorun: "yedek" diye saklanan şeyin çoğu, üretim sunucusunun kendisi üzerindeki bir snapshot. Aynı diski paylaşan, aynı erişim hesabıyla yazılabilen, aynı yangının yanında yanacak bir kopya — bu yedek değil, aynı verinin ikinci adı. Donanım arızası, fidye yazılım veya yanlışlıkla silinmiş bir tablo durumunda bu "yedek" üretim verisiyle birlikte yok olur. Gerçek yedek mutlaka ayrı bir sistemde, ayrı bir kimlik altında, ideal olarak ayrı bir coğrafyada durmalıdır.
Üçüncü sorun: off-site kopya yok. Tek bir veri merkezinde, tek bir bulut bölgesinde duran yedek; o bölgenin bir kesintisinde, bir doğal afetinde veya hesabın askıya alınmasında erişilemez hale gelir. AWS bir bölgenin tamamını kapatabilir, Microsoft bir hesabı saatler içinde kilitleyebilir, bir veri merkezi yangını saatlerce sürebilir — bu senaryolarda off-site bir kopya, iş sürekliliğiniz ile iflas arasındaki tek farktır. 3-2-1 kuralının "1"i tartışmasızdır.
Dördüncü sorun: yedekler şifrelenmemiş. Yedek dosyası, üretim veritabanının tam bir kopyasıdır — yani tüm müşteri kayıtlarınız, kredi kartı izleri, şifre hash'leri ve iç yazışmalarınız tek bir tar.gz içindedir. Bu dosya çalındığında ihlal yine ihlaldir; KVKK ve GDPR sizi yedek olduğu için affetmez. Tüm yedekler hem at-rest (AES-256) hem in-transit (TLS 1.3) şifrelenmeli, anahtarlar yedek sisteminden ayrı bir KMS'te saklanmalıdır — yoksa yedek bir saldırı yüzeyidir, savunma değil.
Beşinci sorun: immutability yok. Modern fidye yazılım saldırıları sadece üretim verisini şifrelemekle yetinmiyor — saldırgan önce yedek sistemine sızıyor, son üç ayın yedeklerini siliyor veya geçersiz kılıyor, sonra üretimi şifreliyor. Yedek hesapları üretim ile aynı dizinden, aynı VPN'den, aynı SSO'dan erişilebiliyorsa fidye yazılım orayı da bulur. Çözüm: WORM (write-once-read-many) depolama, S3 Object Lock, Veeam Hardened Repository, hava boşluklu offline kopya — kısacası saldırganın yetkili olsa bile silmesinin matematiksel olarak mümkün olmadığı bir katman.
Restore zaman çizelgesi, fidye yazılım temizleme simülasyonu ve RPO/RTO karşılaştırma paneli — felaket sonrası kararlarınızı önceden ölçülebilir hale getirir.
Saatlik snapshot + günlük tam yedek + haftalık konsolidasyon + aylık arşiv. Restore noktası saniye hassasiyetinde seçilebilir.
Şifreli veri → immutable yedekten geri yükleme → temiz veri yeşil tikle işaretli.
"Yedek yok" senaryosu ile bizim mimarimiz arasındaki farkı tek bakışta görün.
Bir saatlik veri kaybı, yüzlerce sipariş, binlerce stok hareketi ve ödeme uzlaşması anlamına gelir.
Tek kiracının verisini kurtarmak için tüm tabloyu geri yüklemek seçenek değildir.
Hasta kayıtları yıllarca, denetlenebilir biçimde tutulmalı; bir kayıp KVKK/HIPAA ihlalidir.
BDDK, SPK, MASAK kayıtları yıllarca silinmeden, değiştirilmeden saklanmalı.
Tasarım dosyaları, video projeleri, kod depoları kaybolursa tek tek müşteriyi aramak gerekir.
Petabayt boyutunda ham çekim, tekrar üretilemeyen tarihsel materyal — özel mimari gerekir.
Fabrika hattındaki bir kontrolcü konfigürasyonu kaybolursa hat saatlerce durur.
Diploma, transkript ve devam kayıtları sürekli, kalıcı ve denetlenebilir olmak zorundadır.
Strateji tasarımından çalıştırma kitabına, on katmanlık tek paket — birinden tasarruf yapmadan, hiçbirini gereksiz şişirmeden.
İş etki analizi, varlık envanteri, RPO/RTO matrisi ve sözleşmeye giren hedefler.
Hızlı restore için lokasyonda fiziksel veya sanal yedek aygıtı.
Başka bir veri merkezi veya bulut bölgesine asenkron / senkron replikasyon.
S3, Blob, GCS üzerinde yaşam döngüsü politikalı maliyet-optimize yedek.
S3 Object Lock, Wasabi Compliance, Veeam Hardened — silinemeyen katman.
PostgreSQL WAL, MySQL binlog, MongoDB oplog, MSSQL transaction log.
VSS, fsfreeze, pre/post hook ile yazma sırasında tutarlı disk imajı.
Sandbox'a periyodik restore + bütünlük doğrulama + rapor.
Adım adım, kim yapar / kim onaylar / nereye yazar — yazılı plan.
Tetik → izolasyon → forensic → restore → forensic-temiz görüntü.
Hangi sistem ne kadar kritik, kabul edilebilir veri kaybı ve geri dönüş süresi belirlenir; iş etki analizi yapılır.
Üç kopya, iki medya, bir off-site katmanı; immutability + şifreleme + erişim modeli belgelenir.
On-site appliance + bulut hesabı + ağ izolasyonu + monitoring + alerting devreye alınır.
Saatlik / günlük / haftalık / aylık döngü; AES-256 at-rest, TLS in-transit, KMS'te ayrı anahtar.
Gerçek senaryolarla restore; ölçülen RPO/RTO sözleşme hedefiyle karşılaştırılır; sapmalar düzeltilir.
Yedek başarısı, depolama trendi, restore süresi panolarda; aylık rapor + yıllık mimari revizyon.
Hiçbir aracı kendi başına satmıyoruz. Mimarinizi tasarlıyor, hangi katmanda hangi aracın doğru olduğunu açıklıyor ve toplam sahiplik maliyetini şeffaf gösteriyoruz.
250k SKU'lu mağaza Cuma 03:14'te şifrelendi; immutable Wasabi kopyasından 38 dakikada tam üretim — sipariş kaybı sıfır.
Geliştirici prod'da bir tabloyu sildi; PostgreSQL PITR ile 4 dakikada tam tutarlı geri yükleme yapıldı.
Hastane 7 yıllık PHI denetimini geçti; immutable arşivde kayıt eksiksizliği matematiksel olarak ispatlandı.
Senior tasarımcının dizüstü çalındı; client deliverables içeren 2TB Restic ile saatlik off-site'taydı.
Yayıncının ham çekim arşivi tier'lı depolamaya alındı; aktif S3 + Glacier Deep Archive ile yıllık %63 tasarruf.
AWS eu-central-1 outage; otomatik DNS + DB failover ile eu-west-1'e 11 dakikada geçiş, müşteri trafiği kesilmedi.
Hayır, snapshot tek başına yedek değildir. Snapshot, bir disk veya volume'un belirli andaki "fotoğrafıdır" ve büyük çoğunluğu aynı depolama sistemi üzerinde, hatta aynı disk üzerinde yaşar — yani üretim verisi kaybolduğunda snapshot da kaybolur. Hardware arızası, depolama sistemi çöküşü, fidye yazılım ya da admin hatası snapshot'ı da etkiler. Snapshot, çok hızlı restore için harika bir ilk katmandır (saniyeler içinde geri dönebilirsiniz) ama gerçek yedek için snapshot mutlaka ayrı bir sisteme, ayrı bir kimlik altında, ideal olarak ayrı bir coğrafyaya kopyalanmalıdır. Bizim mimarimizde snapshot her zaman kademedir — sırada off-site yedek, immutable arşiv ve felaket kurtarma replikasyonu vardır.
3-2-1 kuralı, sektörde yıllardır kanıtlanmış minimum yedek stratejisidir: üç (3) farklı kopya, iki (2) farklı medya türünde, biri (1) mutlaka off-site. Üç kopyadan biri üretimin kendisi, ikisi yedek — böylece bir yedek bozulsa bile ikincisi vardır. İki medya türü, tek bir teknolojinin sistemik arızasından (örneğin tüm SSD'lerin bir firmware bug nedeniyle çökmesi) korur: disk + bant, disk + nesne depo, NAS + bulut. Off-site kopya, yangın, sel, hırsızlık, bölgesel kesinti veya hesap askıya alınmasından korur — aynı binadaki, hatta aynı şehirdeki kopya off-site sayılmaz. Modern uzantı "3-2-1-1-0" şeklinde: bir kopya immutable olmalı (1) ve restore testlerinde sıfır (0) hata olmalı.
Sadece doğru tasarlanmışsa. Modern fidye yazılım, üretimi şifrelemeden önce haftalarca ağda kalıyor, yedek sistemini keşfediyor ve mevcut yedekleri siliyor veya geçersiz kılıyor — sonra üretimi şifreliyor; restore yapacak şey kalmıyor. Bu yüzden yedek hesapları üretim dizininden, üretim SSO'sundan, hatta üretim ağından bağımsız olmalı. Çözüm WORM (write-once-read-many) depolamadır: S3 Object Lock Compliance modunda, Wasabi Compliance, Veeam Hardened Repository, hava boşluklu bant. Bu katmanlarda silme, admin yetkisiyle bile matematiksel olarak imkânsızdır — saklama süresi boyunca veri "donmuştur". Bizim mimarimizde her müşteride en az bir WORM katmanı vardır ve ransomware kurtarma playbook'u tatbikatla doğrulanır.
En az üç ayda bir, kritik sistemlerde ayda bir, regülasyonlu ortamlarda ise haftalık otomatik test öneririz. Test restore, yedek mimarinizin gerçekten çalıştığının tek kanıtıdır — log'da "OK" yazması yetmez. Tam tatbikat, izole bir sandbox'a tam restore yapmayı, uygulamayı ayağa kaldırmayı, veritabanı bütünlüğünü ve checksum'ları doğrulamayı, ölçülen RPO/RTO'yu sözleşme hedefiyle karşılaştırmayı kapsar. Otomatik testler ise her yedekten sonra "instant recovery" ile sanal bir kopya çıkarır, akıllı taramalar yapar ve sonucu raporlar. Biz her müşteride hem otomatik haftalık doğrulama hem üç aylık manuel tatbikat çalıştırıyoruz; sonuçlar imzalı raporda saklanır — denetimde, sigortada ve sözleşme yenilemesinde işinize yarar.
Doğru tasarlanırsa hayır, yanlış tasarlanırsa son derece pahalı olur. Maliyetin üç ana eksen vardır: depolama (GB başına aylık), egress (geri yüklerken indirme), API çağrıları (her dosya operasyonu için ücret). Naif yaklaşım "her şeyi her gün tam S3'e atalım" yıllık on binlerce dolar olabilir. Doğru yaklaşım katmanlıdır: sık ihtiyaç duyulan son 14 günlük S3 Standard, son 90 gün S3 Standard-IA, son 1 yıl S3 Glacier Instant, daha eski Glacier Deep Archive — aynı veri için maliyet 10-20x değişir. Üstüne yaşam döngüsü politikaları, sıkıştırma, deduplikasyon ve incremental forever stratejisi geldiğinde tipik müşterimizin bulut backup maliyeti aylık birkaç yüz dolar bandındadır. Restore senaryolarınızı bilmek ölçeklendirmenin anahtarıdır; ayda bir restore yapan biri için "Glacier Deep" yıllarca beklerken, günde 5 restore yapan biri için yıkıcı pahalıdır.
RPO (Recovery Point Objective) "ne kadar veri kaybını kabul ediyoruz" sorusunun cevabı, RTO (Recovery Time Objective) ise "ne kadar sürede ayağa kalkmamız gerekiyor" sorusunun. Bu iki sayı iş etki analizinden çıkar: o sistem bir saat durduğunda, bir gün veri kayıp olduğunda gelir, müşteri ve regülasyon açısından gerçek maliyet nedir? E-ticarette saatlik gelir genellikle RTO'yu dakikalara çeker; sipariş kabul eden bir sistem için 1 saat RTO çok uzundur. İç kullanımdaki bir CRM için 8 saat RTO mantıklı olabilir. RPO için: kaybedebileceğiniz iş aktivitesi süresi kaç dakikadır? Saatlik snapshot RPO'yu 60 dakikaya, transaction log replikasyonu saniyelere indirir. Bu hedefler sözleşmede sabittir ve her tatbikatta ölçülerek kanıtlanır — keyfi sayılar değil, iş kararlarıdır.
Evet, bizim mimarimiz GDPR, KVKK, ISO 27001 Annex A.12.3, SOC 2 CC9 ve PCI-DSS 9.5 / 12.10 maddeleriyle tam uyumludur. Bunun anlamı: tüm yedekler hem at-rest (AES-256) hem in-transit (TLS 1.3) şifrelenir; anahtarlar bir KMS'te (AWS KMS, Azure Key Vault, HSM) saklanır ve yedek sisteminden ayrı yetkilendirilir; saklama süreleri yasal gereklilikle örtüşür ve aşıldığında kanıtlanabilir silme yapılır; "right to be forgotten" talepleri için yedek arama + selektif anonimleştirme prosedürü vardır; veri yeri (Türkiye/AB) seçilebilir; tüm erişimler, restore'lar ve yapılandırma değişiklikleri immutable audit log'a yazılır. Denetim hazırlığı paketinde mimari diyagram, politika belgeleri, RACI matrisi ve son tatbikat raporları teslim ederiz — denetçinin sorabileceği her şeyin cevabı hazırdır.
Evet, mevcut Veeam (veya Rubrik, Cohesity, Commvault, Acronis) kurulumunuzu olduğu gibi devralabiliriz; lisansınız değişmez, ekipman aynı kalır. İlk hafta tam bir denetim yaparız: mevcut yedek başarı oranı, son restore tarihi, retention politikaları, immutability durumu, erişim modeli, anahtar yönetimi, monitoring ve alarmlar — her şeyi belgeleriz ve riskleri kırmızı/sarı/yeşil olarak raporlarız. Sonraki 30 günde mimari gözden geçirilir ve gerekirse köprü modunda (eski + yeni paralel) yeni katmanlar eklenir; veri taşınmaz, yeni yedek hedefleri eklenir. Üçüncü ay sonunda tam bir restore tatbikatı yapılır ve baz çizgisi atılır. Sertifikalı Veeam VMCE ve Rubrik RCSA mühendislerimiz var; vendor değiştirmenize gerek yok — sadece doğru yapılandırma ve operasyonel disiplin getiriyoruz.
30 dakikalık ücretsiz görüşmede mevcut yedek durumunuzu birlikte değerlendiriyoruz: RPO/RTO hedefleri, immutability boşlukları, son test restore tarihi ve önümüzdeki 90 günde atılacak somut adımlar — yazılı rapor olarak teslim.
