KOBİ yedekleme hizmeti seçimi: değiştirilemez yedek, Türkiye'de saklama, geri dönüş testi ve sözleşmede bakılacaklar

Muhasebe programınız, ERP veritabanınız ya da dosya sunucunuz bir sabah şifrelenmiş açılırsa işin nasıl devam edeceğini, yedeğin nerede olduğu ve ne kadar sürede geri geldiği belirler. Bir KOBİ yedekleme hizmeti seçerken çoğu teklif GB başı fiyatla karşılaştırılır. Asıl farkı yaratan konular ise başkadır: yedeğin silinip silinemeyeceği, nerede tutulduğu, geri yüklemenin denenip denenmediği ve sözleşmenin çıkışta ne söylediği. Bu rehber, şirket verisini dışarıda yedekletmek isteyen KOBİ sahibi ve sistem yöneticisi için bir karşılaştırma çerçevesi sunuyor.

KOBİ yedekleme hizmeti neyi korumalı

Teklif istemeden önce neyi koruyacağınızın listesini çıkarın. Sağlayıcıya "sunucuyu yedekleyin" demek yetmez; her veri türünün yedekleme yöntemi farklıdır.

• ERP ve muhasebe veritabanları: Logo, Mikro, Netsis, ETA gibi programlar verisini çoğunlukla SQL Server üzerinde tutar. Bu veritabanları çalışırken dosya kopyalamakla tutarlı yedek alınmaz.
• Dosya paylaşımı: Teklifler, sözleşmeler, taranmış belgeler, e-fatura ve e-defter arşivleri. Burada sürüm geçmişi önemlidir, çünkü fidye yazılımı dosyayı yerinde şifreler ve "son sürüm" bozuk sürümdür.
• Sunucunun kendisi: İşletim sistemi, program kurulumu, lisans ve ayar dosyaları. Tüm sunucu imajı, sıfırdan kurulum süresini kısaltır.
• E-posta: Barındırılan hizmet kullanıyorsanız sağlayıcının saklama süresi ile sizin ihtiyacınız aynı olmayabilir.
• Dizüstü bilgisayarlar: Çalışanların yerel diskinde kalan dosyalar çoğu zaman hiç yedeklenmez.

Her kalem için iki soruyu yanıtlayın: kaybedilirse en fazla kaç saatlik veri kaybı kabul edilebilir, ve en geç kaç saat içinde geri gelmesi gerekir. Bu iki sayı aşağıda RPO ve RTO olarak geri dönecek.

3-2-1-1-0 kuralı KOBİ ölçeğinde nasıl uygulanır

Klasik 3-2-1 kuralı fidye yazılımı döneminde iki ek hane kazandı:

• 3 kopya: canlı veri ve iki yedek.
• 2 farklı ortam: örneğin sunucudaki disk ve ayrı bir depolama.
• 1 kopya şirket dışında.
• 1 kopya değiştirilemez ya da çevrim dışı.
• 0 hata: geri yükleme testinde doğrulanmış yedek.

KOBİ ölçeğinde bunu pahalı donanım olmadan kurmak mümkündür. Pratik bir düzen şöyle olabilir:

1. Sunucuda ya da ofisteki NAS cihazında yerel yedek. Hızlı geri dönüş içindir, tek dosya ya da dünkü veritabanı birkaç dakikada geri gelir.
2. Şirket dışında, nesne kilidi (object lock) açık bir depoda ikinci kopya. Fidye yazılımına karşı asıl sigorta budur.
3. Düzenli geri yükleme provası ve sonucunun kaydı.

Yerel NAS tek başına şirket dışı kopya sayılmaz. Aynı ağdaki, aynı yönetici parolasıyla erişilen bir NAS saldırganın erişebildiği ilk yerlerden biridir.

Fidye yazılımına karşı değiştirilemez ve şirket dışı kopya şartı

İnsan eliyle yürütülen fidye yazılımı saldırılarında saldırgan önce ağda dolaşır, yönetici yetkisi ele geçirir ve şifrelemeden önce yedeklere ulaşıp onları siler ya da bozar. Microsoft Learn'deki fidye yazılımı belgesi bu saldırı türünün işleyişini ve yedeklerin neden hedef alındığını anlatır. Bu yüzden "yedeğimiz bulutta" demek tek başına yeterli değildir; asıl soru, yedeğe yazabilen hesabın onu silip silemeyeceğidir.

Sağlayıcıya şu soruları sorun:

• Değiştirilemezlik nasıl sağlanıyor? S3 uyumlu depolarda bu genellikle Object Lock ile yapılır. Compliance kipinde saklama süresi bitene kadar hiçbir hesap nesneyi silemez. Governance kipinde ise özel yetkisi olan kullanıcı kilidi aşabilir; bu yüzden fidye yazılımı senaryosu için compliance kipi daha güçlüdür.
• Saklama süresi kilitli mi? Kilit süresi 7 günse ve saldırı 10 gün önce başlamışsa, temiz yedek kalmamış olabilir. Kilit süresini, saldırının fark edilme süresini aşacak biçimde seçin.
• Yedek kimlik bilgileri nerede duruyor? Sunucudaki yedek aracı yalnızca yazma yetkisine sahip olmalı, silme ve kilit değiştirme yetkisi ayrı bir hesapta ve çok faktörlü doğrulamayla korunmalı.
• Yedek, üretim ağından ayrı mı? Yedek panelinin girişi şirket etki alanı (Active Directory) hesabıyla açılıyorsa, etki alanını ele geçiren saldırgan yedeğe de ulaşır.

Object Lock ile restic ya da rclone kullanarak kendi yedeğinizi kurmak isterseniz S3 yedekleme rehberi adım adım yapılandırmayı gösterir.

Yedeğin nerede tutulduğu: Türkiye'de saklama ve KVKK

Yedekte müşteri, çalışan ve tedarikçi kişisel verileri bulunur. Bu nedenle yedeğin fiziksel konumu yalnızca teknik değil hukuki bir konudur.

• Veri güvenliği yükümlülüğü: KVKK'nın 12. maddesi, veri sorumlusuna kişisel verilerin güvenliği için uygun teknik ve idari tedbirleri alma yükümlülüğü getirir. Şifreli, erişimi kısıtlı ve test edilmiş yedek bu tedbirlerin doğal parçasıdır.
• Yurt dışı aktarım: Yedeği Türkiye dışındaki bir veri merkezinde tutmak, KVKK'nın 9. maddesi kapsamında yurt dışına aktarım olarak değerlendirilebilir ve ek yükümlülük doğurabilir. Kendi durumunuzu hukuk danışmanınızla netleştirin.
• Kopyaların konumu: Sağlayıcı "veri İstanbul'da" diyebilir ama çoğaltılmış kopyalar ya da felaket kurtarma kopyası başka ülkede olabilir. Sözleşmede tüm kopyaların konumunu yazılı isteyin.

Teknik tarafta kontrol edilecekler: aktarım sırasında TLS, depoda şifreleme, şifreleme anahtarının kimde olduğu (istemci tarafı şifrelemede anahtar sizdedir, sağlayıcı veriyi okuyamaz), erişim kayıtlarının tutulması. KVKK açısından ayrı bir yedek kurgusu arıyorsanız KVKK yedekleme çözümü bu başlıkları tek yerde toplar. Kendi yedekleme aracınızı kullanıp yalnızca hedef depo arıyorsanız, verisi ve 3 kopyası Türkiye dışına çıkmayan İstanbul'daki S3 uyumlu Object Storage bir seçenektir.

Logo, Mikro ve Netsis SQL veritabanlarının tutarlı yedeği

ERP veritabanlarında en sık görülen sorun, yedeğin alınmış görünmesi ama geri yüklenememesidir. Çalışan bir SQL Server'ın .mdf ve .ldf dosyalarını düz kopyalamak tutarsız bir kopya üretir. Doğru yöntemler şunlardır:

• SQL Server'ın kendi yedeği (BACKUP DATABASE): En güvenilir yoldur. Express sürümünde SQL Server Agent olmadığı için zamanlama Windows Görev Zamanlayıcı ve sqlcmd ile yapılır.
• VSS uyumlu yedek ajanı: Sağlayıcının ajanı SQL Writer servisiyle çalışıyorsa tutarlı anlık görüntü alabilir. Ajanın SQL farkında olduğunu ve hangi kurtarma modelini desteklediğini sorun.
• İşlem günlüğü yedeği: Gün içinde birkaç saatlik veri kaybı bile kabul edilemiyorsa veritabanını Full kurtarma modeline alıp düzenli log yedeği gerekir. Simple modeldeki veritabanında en son tam ya da fark yedeğinden sonrası geri gelmez.

Sağlayıcının yedeğine güvenmeden önce, kendi elinizle tutarlı bir yedek alıp doğrulayabildiğinizi görün. Aşağıdaki T-SQL, SQL Server 2016 ve sonrası (Express dahil) için hazırlandı. Canlı yedek zincirini bozmamak için COPY_ONLY kullanır, sağlama toplamıyla doğrular ve yedeği farklı adlı bir test veritabanına geri yükler. ORNEK_DB, ORNEK_DB_TEST ve D:\Yedek değerlerini kendi ortamınıza göre değiştirin; mantıksal dosya adlarını RESTORE FILELISTONLY çıktısından alın.

-- 1) Canlı zinciri etkilemeyen, sağlama toplamlı tek seferlik yedek
--    INIT: aynı dosyanın üzerine yazar, tekrar çalıştırılabilir
BACKUP DATABASE [ORNEK_DB]
  TO DISK = N'D:\Yedek\ORNEK_DB_test.bak'
  WITH COPY_ONLY, CHECKSUM, INIT, STATS = 10;

-- 2) Yedek dosyasının okunabilir ve sağlam olduğunu doğrula
RESTORE VERIFYONLY
  FROM DISK = N'D:\Yedek\ORNEK_DB_test.bak'
  WITH CHECKSUM;

-- 3) Yedekteki mantıksal dosya adlarını listele (MOVE için gerekli)
RESTORE FILELISTONLY
  FROM DISK = N'D:\Yedek\ORNEK_DB_test.bak';

-- 4) Yedeği AYRI bir test veritabanına geri yükle
--    Hedef adın canlı veritabanı adı OLMADIĞINDAN emin olun
RESTORE DATABASE [ORNEK_DB_TEST]
  FROM DISK = N'D:\Yedek\ORNEK_DB_test.bak'
  WITH MOVE N'ORNEK_DB'     TO N'D:\Yedek\ORNEK_DB_TEST.mdf',
       MOVE N'ORNEK_DB_log' TO N'D:\Yedek\ORNEK_DB_TEST_log.ldf',
       REPLACE, RECOVERY, STATS = 10;

-- 5) Geri yüklenen kopyada bütünlük denetimi
DBCC CHECKDB ([ORNEK_DB_TEST]) WITH NO_INFOMSGS;

Beklenen çıktı: 2. adımda The backup set on file 1 is valid. iletisi, 5. adımda ise hata satırı olmaması. Test bittiğinde geri almak için yalnızca test veritabanını kaldırın (DROP DATABASE [ORNEK_DB_TEST];) ve D:\Yedek\ORNEK_DB_test.bak dosyasını silin; canlı veritabanına dokunulmaz. Programın kendisi açısından son kontrol, Logo ya da Mikro'yu test veritabanına bağlayıp bir cari bakiyesini ve son fatura numarasını canlı sistemle karşılaştırmaktır.

Geri dönüş testi: RPO, RTO ve aylık geri yükleme provası

RPO (Recovery Point Objective) kabul edilebilir en büyük veri kaybıdır. Günde bir yedek alınıyorsa RPO en kötü durumda yaklaşık 24 saattir. RTO (Recovery Time Objective) sistemin yeniden çalışır hale gelmesi için tanınan süredir. Bu süre yedek boyutuna, indirme hızına ve sunucunun yeniden kurulma süresine bağlıdır.

Sağlayıcıdan bu iki değeri sözlü değil yazılı ve sizin veri boyutunuza göre isteyin. Ardından kendiniz ölçün:

1. Her ay, takvime bağlı bir gün belirleyin.
2. Değişen bir kalemi seçin: bir ay ERP veritabanı, bir ay dosya paylaşımındaki bir klasör, üç ayda bir tüm sunucu imajı.
3. Geri yüklemeyi canlı sisteme değil ayrı bir test sunucusuna yapın.
4. Başlangıç ve bitiş saatini not edin; bu sizin gerçek RTO'nuzdur.
5. Geri gelen verinin hangi ana ait olduğunu kontrol edin; bu sizin gerçek RPO'nuzdur.
6. Sonucu tarih, kalem, süre ve sorunlarla birlikte bir tabloya yazın. KVKK denetiminde ya da sigorta başvurusunda bu kayıt işinize yarar.

Test sırasında şunlara özellikle bakın: şifreleme anahtarı ya da parola birden fazla kişide ve şirket dışında güvenli bir yerde mi, geri yükleme için sağlayıcıya destek talebi mi açmak gerekiyor, büyük bir geri yüklemede ek trafik ücreti çıkıyor mu.

Hizmet sözleşmesinde bakılacaklar

Teklifleri aynı tabloda karşılaştırmak için aşağıdaki maddeleri her sağlayıcıya sorun:

Fiyat tarafında saklama süresinin faturaya etkisi ve gizli kalemler ayrı bir hesap gerektirir; burada önemli olan, düşük birim fiyatın kısa saklama süresi ya da ücretli geri yüklemeyle telafi edilip edilmediğini görmektir.

Kendi kurulumunuz mu, yönetilen hizmet mi?

• Kendi kurulumunuz (restic, Veeam ya da benzeri araç ve S3 uyumlu depo): Maliyet kontrolü ve esneklik sizdedir, şifreleme anahtarı tamamen sizde kalır. Eksisi: izleme, test ve sorun çözme işi ekibinizdedir; yedekten sorumlu kişi ayrılırsa bilgi de gidebilir.
• Yönetilen yedekleme hizmeti: Ajan kurulumu, zamanlama, izleme ve geri yükleme desteği sağlayıcıdadır. Eksisi: sağlayıcının yöntemine bağlı kalırsınız; çıkış maddeleri ve veri biçimi iyi okunmazsa taşınması zor bir bağımlılık oluşabilir.

Karar ölçütü basit: şirkette yedeği her ay test edecek ve uyarılara bakacak biri yoksa, yönetilen hizmet riski azaltır. Böyle biri varsa ve veri hacmi büyükse kendi kurulumunuz daha esnek olabilir.

Sık yapılan hatalar

• Snapshot'ı yedek saymak: Aynı depolama üzerindeki anlık görüntü, depolama ya da hesap ele geçirildiğinde yedekle birlikte gider.
• Yedeği aynı etki alanı hesabıyla yönetmek: Saldırganın ele geçirdiği yönetici hesabı yedek panelini de açar.
• Yalnızca "yedek başarılı" iletisine güvenmek: Başarılı yedek, geri yüklenebilir yedek demek değildir.
• SQL dosyalarını düz kopyalamak: Logo ya da Mikro veritabanı açık bir dosyadır; tutarlı yedek için SQL yedeği ya da SQL farkında ajan gerekir.
• Kısa kilit süresi: Saldırı geç fark edilirse tüm kilitli sürümler zaten şifrelenmiş veriyi içerebilir.
• Şifreleme parolasını tek kişide tutmak: Parola kaybolursa yedek de kaybolmuş sayılır.
• Dizüstüleri ve e-postayı unutmak: Kritik belgeler çoğu zaman sunucuda değil, çalışanın masaüstündedir.

Sık sorulan sorular

Bulut senkronizasyon hizmeti yedek yerine geçer mi?

Hayır. Senkronizasyon, şifrelenen ya da silinen dosyayı da hemen diğer cihazlara ve buluta taşır. Sürüm geçmişi bir ölçüde koruma sağlar ama saklama süresi, değiştirilemezlik ve geri yükleme testi gibi yedek özelliklerinin yerini tutmaz.

Değiştirilemez yedek için ne kadar kilit süresi seçmeliyim?

Saldırının fark edilmesi için gereken süreden uzun ve yasal saklama ihtiyaçlarınızla uyumlu bir süre seçin. Kilit süresi uzadıkça depolanan veri, dolayısıyla maliyet artar. Pratik bir yaklaşım, günlük sürümleri birkaç hafta, aylık sürümleri daha uzun süre kilitli tutmaktır.

Logo veya Mikro yedeğini programın kendi menüsünden almak yeterli mi?

Programın yedek menüsü tutarlı bir dosya üretebilir, ama bu dosya genellikle aynı sunucuda kalır. Yeterli olması için dosyanın otomatik olarak şirket dışındaki değiştirilemez bir depoya taşınması ve düzenli olarak geri yüklenip denenmesi gerekir.

Yedeği yurt dışında tutmak KVKK'ya aykırı mı?

Kendiliğinden aykırı değildir, ama kişisel veri içeren yedeğin yurt dışında tutulması 9. madde kapsamında aktarım sayılabilir ve ek yükümlülükler getirir. Türkiye'de saklama bu yükü azaltır; kesin değerlendirme için hukuk danışmanınıza başvurun.

Geri dönüş testini ne sıklıkla yapmalıyım?

Kritik veritabanı için en az ayda bir, tüm sunucu imajı için en az üç ayda bir deneme önerilir. Sunucu, program sürümü ya da yedekleme aracı değiştiğinde ek bir test yapın.

Bu işi hazır yaptırmak isterseniz

Yedek ajanının kurulumu, zamanlama, şirket dışı kopya ve geri yükleme desteğiyle uğraşmak istemiyorsanız bulut yedekleme hizmeti sayfasından program ve sunucu yedeği seçeneklerini inceleyebilir, yukarıdaki sözleşme tablosundaki soruları teklif aşamasında doğrudan sorabilirsiniz.

Sonuç

İyi bir KOBİ yedekleme hizmeti, en ucuz GB fiyatına sahip olan değil, kötü günde veriyi geri getiren hizmettir. Seçim yaparken dört şeyi yazılı olarak doğrulayın: en az bir kopyanın şirket dışında ve değiştirilemez olması, tüm kopyaların konumu, ERP veritabanlarının tutarlı yöntemle yedeklenmesi ve çıkışta veri iadesi. Ardından ilk ay içinde kendi geri yükleme testinizi yapın ve sonucu kaydedin. Test edilmemiş yedeğe güvenmek yerine her ay ölçülen bir RPO ve RTO ile çalışın.