Veri Yedekleme 3-2-1 Kuralı ve İşletme Yedekleme Stratejisi

3-2-1 yedekleme kuralı, kritik verinizin en az 3 kopyasını, 2 farklı ortam/medya türünde tutmanızı ve bu kopyalardan 1 tanesini fiziksel olarak farklı bir konumda (offsite) saklamanızı söyleyen klasik bir veri koruma prensibidir. Amaç basittir: tek bir arıza, hırsızlık, yangın ya da fidye yazılımı saldırısı, işletmenizin tüm verisini aynı anda yok edememelidir. Bir işletmenin ERP veritabanı, e-fatura arşivi, muhasebe kayıtları ve müşteri bilgileri söz konusu olduğunda yedekleme bir “iyi olur” değil, faaliyetin sürdürülebilirliği için zorunluluktur.

Bu yazıda 3-2-1 kuralını işletme bağlamında somutlaştırıyor; offsite/bulut yedeğin nasıl kurgulanacağını, RPO/RTO hedeflerini, yedeğin test edilmesini ve fidye yazılımına dayanıklı (immutable) yedek mimarisini ele alıyoruz.

3-2-1 kuralı tam olarak neyi söyler?

Kuralı parçalara ayıralım:

3 kopya: Çalışan (üretimdeki) veri + en az iki ayrı yedek kopya. Üretimdeki dosyanın kendisi de bir “kopya” sayılır.
2 farklı ortam: Tüm yedeklerin aynı disk dizisinde veya aynı sunucuda olmaması. Örneğin biri yerel NAS/disk, diğeri bulut nesne deposu olabilir. Tek bir donanımın çökmesi tüm kopyaları götürmemelidir.
1 offsite kopya: En az bir kopyanın binadan/tesisten fiziksel olarak ayrı bir yerde olması. Yangın, su baskını, hırsızlık ya da elektriksel bir olay tüm yerel kopyaları aynı anda etkileyebilir.

Modern bir genişletme olarak 3-2-1-1-0 kuralı da yaygınlaşmıştır: ek “1”, offline veya değiştirilemez (immutable) bir kopyayı; “0” ise doğrulanmış, sıfır hatalı geri dönüş (test edilmiş restore) anlamına gelir. Fidye yazılımı çağında bu iki ek madde giderek daha kritik hale geldi.

Neden tek bir yedek veya tek bir lokasyon yeterli değil?

Çünkü gerçek hayattaki kayıp senaryoları tek boyutlu değildir. En sık karşılaşılan veri kaybı nedenleri şunlardır:

Donanım arızası: Disk veya RAID dizisinin çökmesi. RAID bir yedekleme yöntemi değildir; sadece kesintisizliği artırır.
İnsan hatası: Yanlışlıkla silinen kayıt, üzerine yazılan dosya, hatalı bir toplu güncelleme.
Fidye yazılımı (ransomware): Saldırgan önce erişebildiği yedekleri şifreler/siler, sonra üretim verisini kilitler. Ağa bağlı tek bir yedek çoğu zaman saldırıyla birlikte kaybolur.
Fiziksel olaylar: Yangın, su baskını, elektrik dalgalanması, hırsızlık.
Yazılım/veritabanı bozulması: Sessizce ilerleyen veri bozulması (silent corruption), zamanla tüm kopyalara da yayılabilir.

Tek bir yerel yedek bu senaryoların yalnızca bir kısmını karşılar. 3-2-1, riski farklı ortam ve konumlara dağıtarak “tek nokta kaybı” ihtimalini büyük ölçüde ortadan kaldırır.

RPO ve RTO nedir, neden önce bunları belirlemelisiniz?

Yedekleme stratejisi teknolojiyle değil, iki hedefle başlar:

RPO (Recovery Point Objective): “Ne kadar veriyi kaybetmeyi göze alabilirim?” Yani iki yedek arasındaki kabul edilebilir süre. RPO 1 saat ise, en kötü senaryoda son 1 saatlik veri kaybolur; bu da yedeği saatte bir almanız gerektiği anlamına gelir.
RTO (Recovery Time Objective): “Sistemi ne kadar sürede geri ayağa kaldırmam gerekir?” ERP’siz geçen her saatin maliyeti yüksekse RTO’nuz düşük (örneğin birkaç saat) olmalıdır.

Bu iki sayı, yedekleme sıklığınızı, saklayacağınız kopya sayısını ve geri yükleme altyapısını doğrudan belirler. RPO/RTO’yu belirlemeden alınan kararlar çoğu zaman ya gereğinden pahalı ya da kriz anında yetersiz kalır.

Senaryo	Tipik RPO	Tipik RTO	Uygun yaklaşım
Kritik ERP / muhasebe veritabanı	15 dk – 1 saat	Birkaç saat	Sık veritabanı yedeği + offsite replikasyon
Dosya sunucusu / paylaşımlar	4 – 24 saat	1 iş günü	Günlük artımlı + haftalık tam yedek
Arşiv / nadiren değişen veri	1 hafta	Esnek	Düşük maliyetli bulut/soğuk depolama

Not: Yukarıdaki değerler genel referanstır; doğru hedef her işletmenin kendi kayıp toleransına göre belirlenmelidir.

Offsite ve bulut yedeği nasıl kurgulanmalı?

Offsite kopya geleneksel olarak başka bir ofise, banka kasasına ya da uzak bir veri merkezine taşınan disk/tape ile sağlanırdı. Bugün çoğu işletme için en pratik offsite çözüm bulut yedeğidir. Dikkat edilmesi gereken noktalar:

Şifreleme: Yedekler hem aktarım sırasında (in-transit) hem de durağan halde (at-rest) şifrelenmelidir. Şifreleme anahtarının yönetimi sizde olmalı.
Veri yerleşimi ve KVKK: Kişisel veri içeren yedeklerin nerede tutulduğu önemlidir. Yurt dışına veri aktarımı söz konusuysa KVKK yükümlülüklerini güncel resmi kaynaklardan (KVKK ve ilgili mevzuat) teyit edin.
Bant genişliği: İlk tam yedeğin yüklenmesi uzun sürebilir; sonrasında artımlı (incremental) yedekle trafik azaltılır.
Geri yükleme maliyeti: Bazı bulut depolama katmanlarında veriyi indirmek (egress) ek ücretlidir. Felaket anında geri yükleme maliyetini önceden bilin.

İdeal kurguda yerel bir kopya hızlı geri dönüş (düşük RTO) için, bulut kopyası ise felakete karşı dayanıklılık için kullanılır.

Yedek “alınmış olması” yeterli mi? Test neden şart?

Hayır. Sektörde acı şekilde öğrenilen bir gerçek vardır: Test edilmemiş yedek, yedek değildir. Yedek işi yıllarca “başarılı” raporu üretmiş olabilir ama dosya bozuksa, eksikse ya da geri yükleme prosedürü çalışmıyorsa kriz anında elinizde hiçbir şey olmaz.

Düzenli yedek testi şunları içermelidir:

Düzenli geri yükleme provası: Periyodik olarak gerçek bir geri yükleme yapın; tercihen ayrı/izole bir ortama.
Bütünlük doğrulaması: Yedek dosyalarının checksum/doğrulama ile sağlamlığını kontrol edin.
Tam felaket tatbikatı: Yılda en az bir kez, “sunucu tamamen gitti” senaryosunu baştan sona deneyin ve gerçek RTO’nuzu ölçün.
Dokümantasyon: Geri yükleme adımları yazılı olsun; sadece tek bir kişinin kafasında durmasın.

Bu, 3-2-1-1-0 kuralındaki “0 hata” maddesinin pratik karşılığıdır.

Yedeklerinizi fidye yazılımına nasıl dayanıklı yaparsınız?

Modern fidye yazılımı saldırılarının ortak hedefi yedeklerin kendisidir. Saldırgan ağa girdiğinde erişebildiği tüm yedekleri şifrelemeye ya da silmeye çalışır. Dayanıklılık için temel önlemler:

Immutable (değiştirilemez) yedek: Belirlenen süre boyunca silinemeyen/değiştirilemeyen yedekler (object lock / WORM). Saldırgan yönetici hakkı ele geçirse bile bu kopyaları bozamaz.
Air-gap / offline kopya: Ağdan fiziksel veya mantıksal olarak ayrılmış bir kopya. Çevrimdışı olan yedeğe uzaktan ulaşılamaz.
Ayrı kimlik ve yetki: Yedekleme sistemi, üretim alan adı (Active Directory) yönetici hesaplarından bağımsız kimlik bilgileriyle çalışmalı; tek bir hesap ele geçirildiğinde her şey çökmemeli.
Çok faktörlü kimlik doğrulama (MFA): Yedek konsoluna ve bulut hesabına erişimde MFA zorunlu olmalı.
İzleme ve uyarı: Olağandışı silme/şifreleme aktivitesinde alarm üreten bir izleme katmanı.

Bu önlemler, doğru yapılandırılmış bir güvenlik duvarı (ör. Fortinet), segmentli ağ ve güncel uç nokta korumasıyla birlikte düşünülmelidir. Yedek, savunmanın son katmanıdır; ilk katmanları da ihmal etmemek gerekir.

İşletmeler için pratik 3-2-1 kontrol listesi

Kritik verileriniz (ERP veritabanı, e-fatura/e-arşiv, muhasebe, dosya sunucusu) envanteri çıkarıldı mı?
Her kritik sistem için RPO ve RTO belirlendi mi?
En az 3 kopya, 2 farklı ortam, 1 offsite kuralı sağlanıyor mu?
Bulut/offsite kopya şifreli ve KVKK uyumlu mu?
En az 1 kopya immutable veya offline mı?
Geri yükleme provası son 6 ayda yapıldı mı?
Geri yükleme prosedürü yazılı ve birden fazla kişi tarafından biliniyor mu?
Yedek konsolu MFA ile ve ayrı yetkiyle korunuyor mu?

Sıkça Sorulan Sorular

3-2-1 kuralındaki “2 farklı ortam” tek bir bulut sağlayıcısıyla sağlanır mı? Tek başına aynı sağlayıcıda iki kova oluşturmak, ortam çeşitliliği açısından idealde yeterli sayılmaz. Amaç tek bir teknolojinin/altyapının çökmesinde tüm kopyaları kaybetmemektir. Pratikte yaygın yaklaşım, bir yerel kopya (disk/NAS) ile bir bulut kopyasını birlikte kullanmaktır.

RAID kurduk, ayrıca yedek almaya gerek var mı? Evet, kesinlikle var. RAID disk arızasında kesintisizliği artırır ama yanlışlıkla silme, fidye yazılımı, yangın veya veri bozulmasına karşı koruma sağlamaz. RAID bir yedekleme değil, erişilebilirlik (uptime) önlemidir.

Yedeği ne sıklıkla test etmeliyim? Geri yükleme provasını mümkünse ayda bir, en azından üç ayda bir yapmanız önerilir; tam felaket tatbikatını ise yılda en az bir kez. Düzenli test olmadan yedeğin gerçekten çalıştığını bilemezsiniz.

Fidye yazılımı yedeklerimi de şifreledi, ne yapmalıyım? Bu nedenle en az bir kopyanın immutable veya air-gap (çevrimdışı) olması kritiktir. Bu tür bir kopyanız varsa, etkilenmemiş bu kopyadan temiz bir geri yükleme yapabilirsiniz. Hiçbir izole kopya yoksa kurtarma ihtimali ciddi şekilde düşer.

KVKK açısından yedeklerimi yurt dışı bulutta tutabilir miyim? Kişisel veri içeren yedeklerin yurt dışına aktarımı belirli koşullara tabidir. Bu eşikler ve koşullar değişebildiği için, güncel resmi kaynağı (KVKK mevzuatı) kontrol etmenizi veya bu konuda profesyonel destek almanızı öneririz.

İşletmenize özel yedekleme ve güvenlik kurgusu

Giza Teknoloji olarak Gaziantep/Şehitkamil merkezli ekibimizle; Netsis 3 ERP ve e-Dönüşüm verilerinizden başlayarak işletmenize uygun 3-2-1 yedekleme stratejisini, offsite/bulut yedeği ve sunucu, güvenlik duvarı (Fortinet) ve ağ güvenliği çözümlerini birlikte tasarlıyoruz. Donanım ve bakım tarafında NAS/sunucu altyapısı, proje ve iş zekası tarafında ise raporlama ve süreklilik planlaması konularında yanınızdayız.

Yedekleme ve felaket kurtarma planınızı gözden geçirmek için bize ulaşın: telefonla 0532 599 51 12, WhatsApp üzerinden 0532 599 51 12 veya bilgi@gizateknoloji.com. Daha fazla bilgi için iletişim ve hakkımızda sayfalarımızı ziyaret edebilirsiniz.