ERP'de yedekleme ve felaket kurtarma: veri kaybı riskini azaltma rehberi

Bir orta ölçekli dağıtım firmasının muhasebe sunucusu bir sabah açılmadı. Disk arızasıydı; IT firması diskin fiziksel olarak kurtarılamayacağını söyledi. Firma son yedeği aradığında ortaya çıkan tablo şuydu: yedek alma görevi altı ay önce işten ayrılan bir çalışana bağlıydı, kimse görevi devralmamıştı, en güncel kopya sekiz ay öncesineydi. Sekiz aylık fatura, sipariş ve cari hareket — yeniden girilemeyecek kadar büyük bir hacim — kayboldu. Bu senaryo tek bir firmaya özgü değil; ERP verisinin yedeklenmesi çoğu işletmede "IT'nin bir yerde hallettiği" bir konu olarak kalır, ta ki gerçekten ihtiyaç duyulana kadar.

ERP tek bir uygulama değil, işletmenin finans, stok, sipariş ve cari kayıtlarının tek doğru kaynağıdır; bu yüzden ERP verisinin kaybı diğer sistemlerin kaybından farklı bir ağırlık taşır. Bu yazı yedekleme sorumluluğunun bulut ve şirket içi kurulumlarda nasıl paylaşıldığını, e-belge saklama yükümlülüğünün nereden geldiğini ve bir yedeğin gerçekten işe yarayıp yaramadığının nasıl test edildiğini ele alıyor.

RTO ve RPO: iki farklı soru

Yedekleme planlaması iki ayrı soruya cevap arar ve bu iki soru genelde birbirine karıştırılır. RTO (kurtarma süresi hedefi), sistem çöktükten sonra yeniden çalışır hale gelmesinin ne kadar sürebileceğini tanımlar. RPO (kurtarma noktası hedefi) ise en fazla ne kadarlık veri kaybının kabul edilebilir olduğunu tanımlar. Bir işletme "sistemim dört saat içinde ayağa kalkmalı, en fazla bir saatlik veri kaybını göze alabilirim" dediğinde RTO dört saat, RPO bir saat olarak belirlenmiş olur.

Bu iki rakam yedekleme sıklığını ve yöntemini doğrudan belirler. Günde bir kez alınan yedek, RPO yirmi dört saat demektir — gece yarısı alınan yedekle sabah saat onda yaşanan bir arıza arasında geçen on saatlik hareket telafi edilemez. RPO bir saatin altına inmesi gerekiyorsa günlük yedek yeterli değildir, sürekli ya da saatlik replikasyon gerekir; bu da genelde ek maliyet ve teknik karmaşıklık demektir. Çoğu KOBİ için RPO'nun sıfıra yakın olması gerekmez — asıl hata, bu rakamın hiç konuşulmamış olmasıdır. ERP sözleşmesi görüşülürken vendor'dan ya da iş ortağından RTO/RPO taahhüdünün yazılı olarak istenmesi, bu konuyu varsayımdan çıkarıp somut bir sözleşme maddesine dönüştürür; bu maddenin genel çerçevesini ERP sözleşmesi kontrol listemizde de ele aldık.

Bulut (SaaS) ERP'de yedekleme sorumluluğu kimde

Bulut tabanlı bir ERP'ye geçildiğinde yaygın bir varsayım, yedeklemenin artık tamamen sağlayıcının sorumluluğunda olduğudur. Bu varsayım kısmen doğrudur: çoğu bulut ERP sağlayıcısı altyapı seviyesinde (sunucu, veritabanı, felaket senaryosunda veri merkezi değişimi) düzenli yedek alır. Ancak bu, "kendi verinizin dışa aktarılabilir, kurumunuzun elinde tuttuğu bir kopyası" ile aynı şey değildir. Sağlayıcının kendi altyapısını korumak için aldığı yedek, genelde kendi felaket senaryosuna (veri merkezi arızası, kendi sistem hatası) karşı bir önlemdir — kullanıcı hatasıyla silinen bir kayıt, hatalı bir toplu güncelleme ya da sözleşme sona erdiğinde verinin dışarı taşınması gibi durumları her zaman kapsamaz.

Kişisel Verilerin Korunması Kanunu'nun 12. maddesi veri sorumlusuna, kişisel verilerin güvenliğini sağlamak için gerekli teknik ve idari tedbirleri alma — bunun içinde düzenli yedekleme ve güvenli ortamda saklama da bulunur — yükümlülüğü getiriyor; veri işleyen sıfatıyla çalışılan bir bulut ERP sağlayıcısı kullanılsa bile bu sorumluluk veri sorumlusu üzerinde kalmaya devam ediyor. Yani "verim bulutta, sağlayıcı hallediyor" cümlesi hem operasyonel hem hukuki açıdan eksik bir varsayım. Bulut ile şirket içi kurulum arasındaki genel tercih çerçevesini bulut ERP karşılaştırmamızda ayrıca ele aldık; yedekleme sorumluluğu bu tercihin gözden kaçan bir alt maddesi.

Pratik karşılığı: sözleşme veya hizmet şartlarında verinin standart bir formatta (örneğin CSV, XML ya da sağlayıcının belgelediği bir dışa aktarma biçiminde) düzenli olarak dışa aktarılıp aktarılamayacağı netleştirilmeli. Bu dışa aktarma bir kez sözleşme imzalanırken değil, düzenli aralıklarla test edilmeli — aksi halde ihtiyaç anında dışa aktarma özelliğinin çalışmadığı ya da beklenenden eksik veri döndürdüğü ortaya çıkabilir.

Şirket içi kurulumda 3-2-1 kuralı ve fidye yazılımı riski

Şirket içinde barındırılan bir ERP'de yedekleme sorumluluğu tamamen işletmenin kendi IT ekibi ya da dış hizmet sağlayıcısındadır. Bu senaryoda sektörde yaygın kabul gören bir çerçeve 3-2-1 kuralıdır: verinin en az üç kopyası tutulur, bu kopyalar en az iki farklı ortamda saklanır, kopyalardan en az biri fiziksel olarak farklı bir konumda ya da çevrimdışı tutulur.

Son maddenin — offsite ya da çevrimdışı kopya — önemi fidye yazılımı saldırılarıyla birlikte arttı. Saldırganlar yalnızca üretim ortamını değil, ağa bağlı yedekleme sunucularını da hedef alıyor; ağa sürekli bağlı kalan bir yedek, üretim verisiyle birlikte şifrelenebiliyor. Bu riski ve genel ERP güvenlik tehdit haritasını ERP güvenliği yazımızda ayrıca işledik; buradaki pratik çıkarım, en az bir yedek kopyanın ağdan fiziksel ya da mantıksal olarak koparılmış (üzerine yazılamaz) biçimde tutulması gerektiğidir.

e-Fatura, e-Arşiv, e-Defter: GİB'in sakladığı süre ile sizin sorumluluğunuz farklı

Türkiye'deki işletmelerde sık rastlanan bir başka yanlış güven, e-belgelerin Gelir İdaresi Başkanlığı tarafından süresiz saklandığı varsayımıdır. Gerçekte GİB, e-arşiv faturalarını sisteminde yalnızca sınırlı bir süre (yaklaşık altı ay) tutuyor; bu sürenin ötesinde faturanın XML formatında saklanması tamamen mükellefin sorumluluğunda. Türk Ticaret Kanunu'na göre ticari defter ve belgelerin saklama süresi on yıl, Vergi Usul Kanunu'na göre vergiyle ilgili defter ve belgeler için bu süre beş yıl olarak belirlenmiş durumda; iki kanun arasındaki fark nedeniyle uygulamada en güvenli yaklaşım on yıllık saklama süresini esas almak.

Bunun ERP tarafındaki karşılığı açık: e-fatura, e-arşiv ve e-defter kayıtlarının üretildiği anda değil, yıllar sonra da erişilebilir, bütünlüğü bozulmamış biçimde saklanması gerekiyor. ERP veya entegratör değiştiğinde, sözleşme sona erdiğinde ya da sistem sürüm yükseltmesi yapıldığında bu arşivin nasıl taşınacağı ve XML formatının korunacağı ayrıca planlanmalı — bu konuyu e-fatura, e-arşiv ve e-irsaliye zorunluluk limitleri yazımızda ve GİB e-Beyan sistemi entegrasyon rehberimizde daha ayrıntılı ele aldık. Kurumsal değerlendirme sürecinde sorulacak somut soru şu: sözleşme sona erdiğinde ya da sistem değiştirildiğinde e-belge arşivinin tamamı hangi formatta, ne kadar sürede teslim ediliyor?

Restore testi yapılmadan yedek yoktur

Yedek alma görevinin düzenli çalıştığını gösteren bir log kaydı, verinin gerçekten geri yüklenebileceğinin kanıtı değildir. Yedek dosyası bozuk olabilir, alınan yedek eksik tablo içerebilir ya da geri yükleme süreci hiç denenmediği için ne kadar süreceği bilinmeyebilir — bu üç durumun hiçbiri normal yedekleme raporunda görünmez. Bir yedeğin işe yaradığı tek kanıt, gerçekten geri yüklenip test edilmiş olmasıdır.

Kurumsal değerlendirme sürecinde önerilen pratik: yılda en az bir, kritik sistemlerde iki kez tam bir restore tatbikatı yapılmalı — test ortamına gerçek bir yedekten sistem ayağa kaldırılmalı, veri bütünlüğü kontrol edilmeli, bu işlemin ne kadar sürdüğü kayıt altına alınmalı. Bu süre, daha önce belirlenen RTO hedefiyle karşılaştırılmalı; tatbikatta dört saat süren bir geri yükleme, sözleşmede iki saat taahhüt edilmişse bu fark önceden fark edilmiş ve düzeltilmiş olur — gerçek bir arıza anında değil.

Sektöre göre değişen risk eşiği

Yedekleme ve saklama disiplini her sektörde aynı ağırlıkta değil. Finans ve mali kontrol ağırlıklı yapılarda denetim ve raporlama gereksinimleri veri bütünlüğüne ek bir katman getiriyor; bu ihtiyacı finans sektörü sayfamızda ele aldık. Kamu kurumlarıyla çalışan ya da kamu ihalesine giren işletmelerde veri saklama ve denetim izi beklentisi daha katı bir çerçevede işliyor; bu konuyu kamu sektörü sayfamızda topladık. İlaç ve sağlık ürünleri üretiminde ise parti bazlı izlenebilirlik verisinin kaybı yalnızca mali değil, düzenleyici bir sorun haline gelebiliyor; bu sektöre özgü çerçeveyi ilaç sektörü sayfamızda işledik. Bu üç sektörde yedekleme ve saklama politikası genel geçer bir şablonla değil, sektörün kendi denetim gereksinimiyle birlikte tasarlanmalı.

Kurumsal değerlendirme süreci için kontrol listesi

• Vendor ya da iş ortağıyla yazılı bir RTO/RPO taahhüdü var mı, yoksa bu konu hiç konuşulmadı mı?
• Bulut ERP kullanılıyorsa kendi verinizin standart formatta, düzenli aralıklarla dışa aktarımı test edildi mi?
• Şirket içi kurulumda en az bir yedek kopyası ağdan fiziksel ya da mantıksal olarak koparılmış mı tutuluyor?
• e-Fatura, e-Arşiv ve e-Defter arşivinin sözleşme sona erdiğinde hangi formatta, ne sürede teslim edileceği netleşti mi?
• Son restore testi ne zaman yapıldı ve geri yükleme süresi RTO hedefiyle karşılaştırıldı mı?
• Yedek alma görevinin sorumlusu net mi, bu kişi işten ayrıldığında görev otomatik olarak devrediliyor mu?

Bu kontrol listesindeki maddelerin çoğu, ERP seçim sürecinin demo ya da sözleşme aşamasında somut sorularla test edilebilir; bu aşamaların genel çerçevesini ERP demo değerlendirme rehberimizde ayrıca ele aldık. Kendi altyapısı ve sektörü için yedekleme ve saklama riskini birlikte değerlendirmek isteyen kurumlar bir keşif görüşmesi talep edebilir; ölçeğe uygun ürünleri karşılaştırmak için uygun ERP bul aracı da kullanılabilir.

Kaynaklar

• Kişisel Verileri Koruma Kurumu — Veri Güvenliğine İlişkin Yükümlülükler (KVKK md. 12)
• TÜRMOB — VUK'a göre defter ve belgelerin saklanma süreleri
• ERP güvenliği 2026: fidye yazılımı ve tedarik zinciri riski