Verisi tek bir bilgisayarda ya da tek bir sunucuda duran işletmeler, yedek aldığını sanan ama hiç geri yüklemeyi denememiş ekipler ve fidye yazılımı riskini ciddiye alan yöneticiler.
Yedekleme, herkesin yaptığını sandığı ama çok azının doğruladığı iştir. Sorulduğunda "evet, yedek alıyoruz" cevabı gelir; "en son ne zaman bir dosyayı yedekten geri yüklediniz?" diye sorulduğunda cevap genellikle sessizliktir. Test edilmemiş bir yedek, olmayan bir yedektir.
İkinci yaygın yanılgı, yedeklemenin bir dosya kopyalama işi olduğudur. Oysa asıl soru şu: sistem bugün durursa ne kadar veri kaybederiz ve ne kadar sürede tekrar çalışır hâle geliriz? Bu iki sorunun cevabı bir tercihtir ve maliyeti vardır; kendiliğinden oluşmaz.
Bu yazı yedeklemeyi bir plan olarak ele alıyor: neyin yedekleneceğinden sıklığa, 3-2-1 kuralından fidye yazılımına, geri yükleme testinden kesinti anında izlenecek sıraya. Siber güvenliğin diğer başlıklarını — oltalama, parola, yetki — KOBİ siber güvenlik rehberimizde anlattık; bu yazı onun devamı.
İki soru: ne kadar veri, ne kadar süre?
Yedekleme planı iki sayıyla kurulur. Birincisi kabul edilebilir veri kaybı: arıza anında son yedekten sonrasını kaybedersiniz. İkincisi kabul edilebilir kesinti süresi: sistemin tekrar çalışması ne kadar sürebilir?
Bu iki sayı teknik değil ticari kararlardır ve işletme sahibi verir. "Hiç veri kaybetmek istemiyorum ve hiç durmak istemiyorum" cevabı teorik olarak mümkündür ama maliyeti çoğu işletme için anlamsızdır. Doğru soru şudur: bir günlük satış kaydını kaybetmek bize neye mal olur, yarım gün duramamak neye mal olur?
KABUL EDİLEBİLİR VERİ KAYBI
"En fazla ne kadarlık çalışmayı yeniden yapabiliriz?"
→ Yedek sıklığını bu belirler.
Günde bir yedek = en fazla bir günlük kayıp
Saatte bir yedek = en fazla bir saatlik kayıp
KABUL EDİLEBİLİR KESİNTİ SÜRESİ
"Sistem ne kadar süre durabilir?"
→ Kurtarma yönteminizi bu belirler.
Yedekten kurulum = saatler
Hazır yedek sistem = dakikalar
MALİYET İLİŞKİSİ
İki sayı da küçüldükçe maliyet hızla artar.
Her sistem için AYNI değerleri seçmek zorunda
değilsiniz — kritik olanları ayırın.Neyi yedeklemek gerekir?
Yedekleme listesi dosyalardan ibaret değildir: veritabanı, yapılandırma, e-posta, bulut hesaplarındaki veri ve erişim bilgileri de listeye girer. En sık atlanan kalem, sistemin nasıl kurulduğunu anlatan bilgidir.
- Veritabanı: Satış, stok, cari, personel — işletmenin asıl hafızası burasıdır.
- Dosyalar: Sözleşmeler, teklifler, görseller, tasarım kaynakları.
- E-posta: Kurumsal yazışma çoğu işletmede tek kopya hâlinde sağlayıcıda durur.
- Yapılandırma: Sunucu ayarları, alan adı kayıtları, entegrasyon anahtarları.
- Bulut uygulamalarındaki veri: Muhasebe programı, CRM, pazaryeri panelleri — "bulutta, güvende" varsayımı yanlıştır.
- Erişim bilgileri: Hangi hesap kimde, hangi panelin şifresi nerede — kurtarma bunlarsız başlayamaz.
- Kurulum bilgisi: Sistem sıfırdan nasıl ayağa kalkar? Bu yazılı değilse yedek olsa da kurtarma uzar.
Özellikle e-posta ve bulut muhasebe verisi gözden kaçar. İkisi de "zaten orada duruyor" diye düşünülür; oysa hesap kapanırsa, abonelik biterse ya da erişim kaybedilirse veri de gider. Bu iki kalemi dışa aktarma yoluyla düzenli olarak kendi tarafınıza almak, çoğu işletmenin hiç düşünmediği ama en kolay uygulanan önlemdir.
3-2-1 kuralı: üç kopya, iki ortam, biri dışarıda
Yaygın ve işe yarayan kural şudur: verinin en az üç kopyası olsun, bu kopyalar en az iki farklı ortamda dursun ve en az biri fiziksel olarak başka bir yerde bulunsun.
3 KOPYA
1. Çalışan veri (sunucu / bilgisayar)
2. Yerel yedek (NAS / harici disk)
3. Uzak yedek (bulut / başka lokasyon)
2 FARKLI ORTAM
Aynı sunucunun ikinci diski AYRI ORTAM DEĞİLDİR.
Sunucu + harici disk ✓
Sunucu + bulut ✓
1 KOPYA DIŞARIDA
Yangın, su baskını, hırsızlık ve fidye yazılımı
aynı binadaki tüm kopyaları birlikte götürebilir.
EK KURAL — ÇEVRİMDIŞI KOPYA
Sürekli bağlı duran bir yedek diski, fidye
yazılımı da şifreler. En az bir kopya sistemden
KOPUK olmalı ya da değiştirilemez olmalı.Son madde, kuralın modern hâlidir. On yıl önce yedeklemenin düşmanı donanım arızasıydı; bugün en yaygın senaryo fidye yazılımıdır ve o, ağa bağlı her şeyi şifreler. Sürekli bağlı bir yedekleme diski ya da eşitlenen bir bulut klasörü, saldırı anında şifrelenmiş hâliyle eşitlenir ve yedek de kaybedilir.
- Bağlantısı kesilen bir disk (takıp çıkarılan) en basit çevrimdışı kopyadır.
- Değiştirilemez (immutable) yedek desteği sunan bulut hizmetleri, silinmeye ve şifrelenmeye karşı koruma sağlar.
- Sürüm geçmişi tutan sistemler, şifrelenmiş dosyanın öncesine dönmeyi mümkün kılar.
- Eşitleme (sync) ile yedekleme aynı şey değildir: eşitleme, silmeyi de kopyalar.
- Yedeklere erişimi sınırlayın; günlük kullanılan hesabın yedekleri silme yetkisi olmamalı.
Sıklık: kayıp penceresini siz belirliyorsunuz
Yedek sıklığı, kaybedebileceğiniz veri miktarını doğrudan belirler. Günde bir yedek alıyorsanız en kötü senaryoda bir günlük çalışmayı yeniden yapmanız gerekir.
Bu ilişki basit ama uygulamada sık atlanır: yedek gecenin bir saatinde alınıyorsa ve arıza akşamüstü olursa, o günün tamamı gitmiştir. Gün içinde yoğun veri üreten bir işletmede — sipariş alan, fatura kesen, tahsilat yapan — günlük yedek çoğu zaman yetersizdir.
| Veri türü | Makul sıklık | Neden |
|---|---|---|
| Satış / sipariş veritabanı | Gün içinde birden çok kez | Her saat yeni ve geri getirilemez kayıt üretir |
| Muhasebe / cari | Günlük ya da daha sık | Yeniden girilmesi çok zaman alır |
| Sözleşme ve belgeler | Değiştikçe | Sık değişmez ama kaybı telafi edilemez |
| E-posta | Düzenli dışa aktarım | Sağlayıcıda tek kopya kalmasın |
| Sunucu yapılandırması | Değişiklik yapıldıkça | Kurtarma süresini asıl bu belirler |
| Web sitesi | Yayın öncesi ve düzenli | Güncelleme sonrası bozulmalar için |
Geri yükleme testi: yedeğin tek gerçek kanıtı
Yedekleme başarılı görünen ama geri yüklenemeyen sistemler yaygındır. Yedeğin çalıştığının tek kanıtı, gerçekten geri yüklenmiş olmasıdır. Test edilmemiş yedek, yedek sayılmaz.
Geri yükleme testinin atlanma nedeni anlaşılırdır: yedekleme otomatiktir ve "başarılı" yazar, test ise elle yapılan bir iştir. Ama yedekleme raporunun yeşil olması dosyanın okunabilir olduğunu göstermez — bozuk, eksik ya da parolası kaybolmuş yedekler ancak ihtiyaç anında fark edilir. Ve o an, öğrenmek için en kötü andır.
- 01
Küçük testle başlayın
Ayda bir, rastgele bir dosyayı ya da tek bir kaydı yedekten geri getirin. Beş dakika sürer ve yedeğin okunabilir olduğunu kanıtlar.
- 02
Yılda bir tam tatbikat yapın
Ayrı bir ortamda sistemi sıfırdan yedekten ayağa kaldırın ve süreyi ölçün. Bu süre, kabul edilebilir kesinti süreniz hakkında gerçeği söyler.
- 03
Adımları yazın
Tatbikat sırasında ne yaptığınızı adım adım not edin. Gerçek kriz anında bu not, hafızadan çok daha güvenilirdir — özellikle işi bilen kişi izinliyse.
- 04
Parola ve anahtarları kontrol edin
Şifreli yedeğin parolası nerede? Sunucunun içinde tutuluyorsa ve sunucu gittiyse yedek de gitmiştir. Parolalar yedekten bağımsız ve erişilebilir bir yerde olmalı.
Fidye yazılımı: yedek en güçlü savunmadır
Fidye yazılımı verinizi şifreler ve karşılığında ödeme ister. Ödemeden çıkmanın tek güvenilir yolu, saldırıdan etkilenmemiş bir yedekten geri dönmektir.
Fidye ödemek çözüm gibi görünür ama üç sorunu vardır: anahtarın çalışacağının garantisi yoktur, ödeme sizi tekrar hedef hâline getirir ve bazı hâllerde ödemenin kendisi hukuki risk doğurur. Bu yüzden hazırlık, müzakereden kat kat ucuzdur.
- En az bir kopya çevrimdışı ya da değiştirilemez olsun — ağa bağlı her şey şifrelenebilir.
- Yedeklere erişim ayrı bir hesapla olsun; günlük kullanılan yönetici hesabı yedekleri silememelidir.
- Sürüm geçmişi tutun: şifrelenmiş dosyanın bir önceki hâline dönebilmek gerekir.
- Saldırı fark edildiğinde önce ağ bağlantısını kesin; yayılmayı durdurmak ilk adımdır.
- Şifrelenmiş sistemi hemen silmeyin; adli inceleme ve bazı durumlarda çözüm için gerekebilir.
- Olayı kayıt altına alın: ne zaman fark edildi, hangi sistemler etkilendi, ne yapıldı.
- Kişisel veri etkilendiyse KVKK bildirim yükümlülüğünüz doğabilir — KVKK rehberimize bakın.
Kesinti anında: hangi sırayla hareket edilir?
Kriz anında karar vermek zordur; bu yüzden sıra önceden yazılır. İş sürekliliği planı, sistem durduğunda kimin ne yapacağını ve müşteriye ne söyleneceğini içeren kısa bir belgedir.
- Durumu tespit edin: Ne çalışmıyor, ne zamandan beri, kaç kişiyi etkiliyor?
- Yayılmayı durdurun: Şüphe varsa etkilenen sistemi ağdan ayırın.
- Sorumluyu devreye alın: Planda adı yazan kişi ve yedeği aranır; herkes aynı anda müdahale etmez.
- Geçici çalışma yoluna geçin: Sistem yokken iş nasıl yürüyecek? Kâğıt, telefon, elle kayıt — önceden kararlaştırılmış olmalı.
- Müşteriye ve ekibe haber verin: Ne olduğu ve ne zaman dönüleceği söylenir; sessizlik en kötü seçenektir.
- Kurtarmayı başlatın: Yazılı adımları izleyin, doğaçlama yapmayın.
- Doğrulayın: Sistem açıldıktan sonra verinin bütünlüğünü kontrol edin; eksik dönem varsa tespit edin.
- Olay sonrası değerlendirme yapın: Ne oldu, ne işe yaradı, plan neresinden değişmeli?
Dördüncü madde en çok atlanan ama en çok işe yarayandır. Sistem birkaç saat kapalı kalacaksa satış tamamen durmak zorunda değildir: siparişler kâğıda yazılır, sonra sisteme girilir. Bunun önceden kararlaştırılmış olması, kriz anında "ne yapacağız" tartışmasını ortadan kaldırır.
Sık yapılan hatalar
Veri kaybı yaşayan işletmelerin çoğunda yedekleme vardı. Hatalar yedeklememekten değil, yedeğin test edilmemesinden, kapsamın eksik kalmasından ve kopyaların aynı yerde durmasından doğar.
- Geri yüklemeyi hiç denememek — yedeğin çalıştığının tek kanıtı budur.
- Tüm kopyaları aynı yerde tutmak — yangın, hırsızlık ve fidye yazılımı hepsini birden götürür.
- Yedek diskini sürekli bağlı bırakmak — fidye yazılımı onu da şifreler.
- Eşitlemeyi yedekleme sanmak — eşitleme silmeyi de kopyalar.
- Yalnızca son yedeği tutmak — bozulma fark edilmeden yedeklenirse tek kopya da bozuktur.
- Bulut hizmetini yedek saymak — sağlayıcı altyapı arızasına karşı korur, sizin hatanıza karşı değil.
- E-postayı ve bulut muhasebe verisini kapsam dışı bırakmak — en sık atlanan iki kalem.
- Yedek parolasını yedeklenen sistemin içinde tutmak — sunucu giderse parola da gider.
- Yedeklemenin çalıştığını kimsenin kontrol etmemesi — aylar önce sessizce durmuş olabilir.
- Yeni eklenen sunucu ya da sistemi kapsama almamak — kapsam listesi güncel tutulmalıdır.
- Kurtarma adımlarını yazmamak — işi bilen kişi izinliyken kriz çıkarsa plan yok demektir.
Bu listedeki maddelerin ortak yanı, hiçbirinin pahalı olmamasıdır. Bir diski takıp çıkarmak, ayda bir dosya geri yüklemek, tek sayfalık bir plan yazmak ve kapsam listesini güncel tutmak — hepsi birkaç saatlik iştir. Buna karşılık önledikleri şey, çoğu küçük işletme için toparlanması aylar süren bir olaydır.
Sık sorulan sorular
Veri yedekleme nasıl yapılır?
Önce iki soruyu cevaplayın: en fazla ne kadarlık veriyi kaybetmeyi göze alabiliriz (bu yedek sıklığını belirler) ve sistem en fazla ne kadar durabilir (bu kurtarma yöntemini belirler). Sonra kapsamı çıkarın — veritabanı, dosyalar, e-posta, bulut uygulamalarındaki veri, yapılandırma ve erişim bilgileri. Ardından 3-2-1 kuralını uygulayın: en az üç kopya, en az iki farklı ortam, en az biri başka bir yerde. En kritik adım ise geri yüklemeyi düzenli test etmektir; test edilmemiş yedek, yedek sayılmaz.
3-2-1 yedekleme kuralı nedir?
Verinin en az üç kopyası olsun (çalışan veri + yerel yedek + uzak yedek), bu kopyalar en az iki farklı ortamda dursun (aynı sunucunun ikinci diski ayrı ortam sayılmaz) ve en az biri fiziksel olarak başka bir yerde bulunsun. Modern bir ek kural daha var: en az bir kopya sistemden kopuk (çevrimdışı) ya da değiştirilemez olmalı — çünkü fidye yazılımı ağa bağlı her şeyi şifreler ve sürekli bağlı duran bir yedek diski de şifrelenir.
Ne sıklıkla yedek almalıyım?
Sıklık, kaybedebileceğiniz veri miktarını doğrudan belirler: günde bir yedek alıyorsanız en kötü senaryoda bir günlük çalışmayı yeniden yapmanız gerekir. Gün içinde sipariş alan, fatura kesen, tahsilat yapan bir işletmede günlük yedek çoğu zaman yetersizdir — satış ve muhasebe veritabanı için gün içinde birden çok kez almak gerekir. Ayrıca yalnızca en son yedeği tutmayın: bozulma fark edilmeden yedeklenirse elinizdeki tek kopya da bozuk olur. Birden çok geriye dönük nokta saklayın.
Bulutta tutuyorum, yedek almama gerek var mı?
Var. Bulut hizmeti sizi sağlayıcının altyapı arızalarına karşı korur, kendi hatalarınıza karşı korumaz: yanlışlıkla silinen kayıt, fidye yazılımıyla şifrelenen klasör ya da kapanan bir hesap bulutta da kaybolur. Ayrıca çoğu sağlayıcının kendi yedeği belirli bir süreyle sınırlıdır ve bu süre sizin ihtiyacınızdan kısa olabilir. Özellikle e-posta ve bulut muhasebe verisini düzenli dışa aktarımla kendi tarafınıza almak, en kolay uygulanan ama en çok atlanan önlemdir.
Fidye yazılımı bulaşırsa ne yapmalıyım?
Önce ağ bağlantısını kesin — yayılmayı durdurmak ilk adımdır. Şifrelenmiş sistemi hemen silmeyin; adli inceleme ve bazı durumlarda çözüm için gerekebilir. Olayı kayıt altına alın (ne zaman fark edildi, hangi sistemler etkilendi) ve etkilenmemiş bir yedekten geri dönün. Fidye ödemek güvenilir bir çözüm değildir: anahtarın çalışacağının garantisi yoktur, ödeme sizi tekrar hedef yapar ve bazı hâllerde hukuki risk doğurur. Kişisel veri etkilendiyse KVKK kapsamında bildirim yükümlülüğünüz doğabilir.
Yedeğimin çalıştığını nasıl anlarım?
Tek yolu var: geri yükleyerek. Yedekleme raporunun "başarılı" yazması dosyanın okunabilir olduğunu göstermez — bozuk, eksik ya da parolası kaybolmuş yedekler ancak ihtiyaç anında fark edilir. Ayda bir rastgele bir dosyayı geri getirin (beş dakika sürer), yılda bir de ayrı bir ortamda sistemi sıfırdan ayağa kaldırıp süreyi ölçün. Bu süre, kabul edilebilir kesinti süreniz hakkında gerçeği söyler. Ayrıca şifreli yedeğin parolasının yedeklenen sistemin dışında tutulduğundan emin olun.