Kısa cevap: Yedek almak bir iş değildir, geri dönebilmek bir iştir. Yedeği hiç denenmemiş bir site, yedeksiz bir siteden yalnızca biraz daha iyidir. Doğru kurulum üç şeyi aynı anda sağlar: dosyalarla veritabanının AYNI ana ait olması, en az bir kopyanın site sunucusunun dışında durması ve geri dönüşün gerçekten denenmiş olması. Sıklığı ise iki soru belirler: kaç saatlik veri kaybını kabul edebilirsiniz ve ne kadar süre kapalı kalabilirsiniz.
Ölçüt, yedeğin varlığı değil geri dönüşün çalışması
Yedekleme konusunda en sık rastlanan yanlış güven şudur: panelde bir yedek listesi görünüyorsa iş tamamdır. Oysa o listenin bir işe yaraması için üç varsayımın hepsinin doğru olması gerekir. Arşivin içeriği tam olmalı, arşiv okunabilir olmalı ve geri dönüş adımlarını bilen biri olmalı. Üçünden biri tutmazsa elinizde yedek değil, yedek görüntüsü vardır.
İkinci kritik ayrım zamanlamadır. Bir sitenin dosyaları ile veritabanı birbirine bağlıdır: medya kayıtları veritabanında, dosyaların kendisi diskte durur. Dosya yedeğini sabah, veritabanı yedeğini akşam alırsanız geri dönüşte tutarsız bir site elde edersiniz – veritabanı diskte olmayan dosyalara işaret eder ya da tersi olur. İki bileşen aynı ana ait olmalıdır.
Ne yedeklenir: bileşen envanteri
Çoğu yedekleme kurulumu site dosyalarını ve veritabanını alır, gerisini atlar. Oysa sıfırdan ayağa kaldırma anında eksik olan şey genelde bu ikisi değildir.
| Bileşen | Nerede durur | Sıklık ölçütü | Atlanırsa ne olur |
|---|---|---|---|
| Site dosyaları (tema, eklenti, özel kod) | Web köküne bağlı dizin | Kod ya da tasarım ne sıklıkla değişiyor | Site yeniden kurulur ama özelleştirmeler kaybolur |
| Veritabanı | Veritabanı sunucusu | Sipariş, kayıt ve içerik ne sıklıkla eklenir | İçerik, sipariş ve kullanıcılar gider; dosyalar işe yaramaz |
| Yükleme ve medya klasörü | Genelde site dizininin içinde, ayrı diskte de olabilir | Yeni görsel ve belge eklenme hızı | Veritabanı dosyaları çağırır, dosyalar yoktur; her sayfa kırık |
| Sunucu yapılandırması ve sanal ana makine ayarları | Sunucu yapılandırma dizinleri | Her değişiklikten sonra | Site dosyaları yerinde ama hiçbir adres doğru çalışmaz |
| Sertifika ve yenileme yapılandırması | Sertifika aracının yapılandırma dizini | Her yenileme ayarı değişikliğinde | Site açılır ama HTTPS yoktur; kurtarma günü kaybedilir |
| DNS bölgesinin bir dökümü | DNS sağlayıcısının paneli | Her kayıt değişikliğinde | MX ve doğrulama kayıtları hatırlanmaz; e-posta günlerce durur |
| Posta kutuları | E-posta sağlayıcısı ya da posta sunucusu | Yazışma hacmi ve yasal saklama ihtiyacı | Silinen ya da bozulan kutu geri getirilemez |
| Çalışan eklenti ve sürüm listesi | Yazılı bir not ya da paket tanımı | Her güncellemeden sonra | Hangi sürümle çalıştığı bilinmez; geri dönüş deneme yanılmaya döner |
Nereye: aynı sunucudaki yedek yedek sayılmaz
Bu cümle sert görünüyor ama pratikte doğrudur. Yedek, sunucunun kendi diskinde duruyorsa sunucu gittiğinde yedek de gider. Disk arızası, hesap kapanması ya da yanlış bir silme komutu hem siteyi hem kopyasını aynı anda götürür. Fidye yazılımı tarafında durum daha nettir: saldırganın ilk işi erişilebilir yedekleri silmek ya da şifrelemektir, çünkü geri dönüş imkânı pazarlık gücünü yok eder.
Bu yüzden kural şudur: en az bir kopya site sunucusundan AYRI bir yerde durmalı ve mümkünse değiştirilemez (immutable) ya da sürümlü olmalıdır. Değiştirilemez depolama, yazıldıktan sonra belirli bir süre silinemeyen kopya demektir; sürümlü depolama ise bir dosyanın üzerine yazıldığında önceki hâlini saklar. İkisinin de ortak amacı aynı: yedeği silme yetkisini, siteyi yönetme yetkisinden ayırmak.
Ne sıklıkla: önce iki soruyu yazılı cevaplayın
Sıklık bir tercih değil, bir hesabın sonucudur. İki soruyu cevaplamadan sıklık seçilemez. Birinci soru: kaç saatlik veri kaybını kabul edebilirsiniz? Bu, kurtarma noktası hedefidir. Günde üç sipariş alan bir tanıtım sitesinde cevap bir gün olabilir; saatte otuz sipariş alan bir mağazada bir saat bile fazladır. İkinci soru: ne kadar süre kapalı kalabilirsiniz? Bu, kurtarma süresi hedefidir ve yedeğin biçimini belirler – dört saatte ayağa kalkması gereken bir site için elle sıkıştırılmış arşivler yetmez.
Bu iki cevabı yazılı hâle getirmenin pratik faydası şudur: tartışma “günlük yedek yeter mi” sorusundan çıkar, “bir günlük siparişi kaybetmeyi kabul ediyor muyuz” sorusuna döner. İkinci soruyu işin sahibi cevaplar, teknik taraf değil.
Kademeli saklama: neden tek bir günlük kopya yetmez
Yedekleme kurulumlarının sessiz açığı saklama süresidir. Yalnızca son birkaç günlük kopyayı tutuyorsanız, ani arızalara karşı korunmuş olursunuz; yavaş bozulmalara karşı korunmazsınız. Silinmiş bir ürün grubu, bozulan bir içerik alanı ya da yanlış çalışan bir toplu güncelleme haftalar sonra fark edilir. O ana kadar bütün günlük kopyalar bozuk içeriği taşır ve geri dönecek temiz bir nokta kalmaz.
Çözüm kademeli bir desendir: günlük kopyalar kısa bir süre, haftalık kopyalar daha uzun, aylık kopyalar en uzun tutulur. Böylece yakın geçmişte ince taneli, uzak geçmişte seyrek ama var olan bir geri dönüş noktası dizisi elde edersiniz. Süreleri seçerken alt sınırı “bir bozulmayı ne kadar gecikmeyle fark ederiz” sorusu belirler.
Adım adım: çalışan bir yedekleme düzeni kurmak
- Kurtarma hedeflerini yazın. Kabul edilebilir veri kaybı ve kabul edilebilir kapalı kalma süresi. Bu iki sayı yazılı olmadan geri kalan her karar tahmin olur.
- Bileşen envanterini çıkarın. Yukarıdaki tabloyu kendi sisteminize uyarlayın: hangi bileşen nerede duruyor, kimin erişimi var, sürümü ne.
- Otomatik yedeği kurun ve dosyalarla veritabanını AYNI anda alın. İki görev ayrı çalışıyorsa aralarındaki fark kadar tutarsızlık doğar. Tek bir görevin içinde sıralı çalışmaları en güvenli düzendir.
- En az bir kopyayı site sunucusunun dışına çıkarın. Farklı bir sağlayıcı, farklı bir hesap ve farklı bir erişim bilgisi. Siteyi yönetebilen kimlik, yedeği silebilen kimlik olmasın.
- Kademeli saklama kurun. Günlük, haftalık ve aylık kopyalar için ayrı saklama süreleri tanımlayın. Böylece haftalar sonra fark edilen bir bozulmada geri dönecek temiz bir nokta kalır.
- Yedeğin bütünlüğünü otomatik doğrulayın. Her yedekten sonra arşivin açılabildiğini ve veritabanı dökümünün beklenen tabloları içerdiğini kontrol eden bir adım ekleyin. Sessizce boş dosya üreten yedekleme görevleri hiç nadir değildir.
- Üç ayda bir gerçek bir geri dönüş tatbikatı yapın. Tercihen ayrı bir alan adında bir deneme kurulumuna geri dönün ve siteyi gezin. Tatbikat yapılmamış bir kurtarma planı, bir plan değil bir temennidir.
- Geri dönüş adımlarını tek sayfaya yazın. Hangi sırayla ne yapılacak, erişim bilgileri nerede duruyor ve kimin yetkisi var. Bu sayfa, kriz anında siteye erişimi olmayan biri tarafından da okunabilir bir yerde bulunmalı.
Tek sayfalık kurtarma notu neye benzer
Aşağıdaki kalıp doldurulmak üzere bırakılmıştır; köşeli parantez içindeki kısımlar sizin yazacağınız YER TUTUCULARDIR.
KURTARMA NOTU / [site adi] son guncelleme: [tarih] # hedefler kabul edilebilir veri kaybi : [... saat] kabul edilebilir kapali sure: [... saat] # yedek nerede sunucu uzerindeki kopya : [yol] saklama: [... gun] sunucu disindaki kopya : [saglayici / hesap] saklama: [... gun] haftalik ve aylik kopya : [yer] saklama: [... hafta / ay] # bilesenler site dosyalari / veritabani / medya klasoru / sunucu yapilandirmasi sertifika yapilandirmasi / DNS bolge dokumu / posta kutulari calisan eklenti ve surum listesi: [yer] # geri donus sirasi 1. [bakim moduna al] 2. [dosyalari ac] 3. [veritabanini yukle] 4. [sertifika ve yonlendirmeyi dogrula] 5. [ornek sayfalari gez ve formu dene] # yetki erisim bilgileri nerede : [parola kasasi] kurtarmaya yetkili : [ad / rol] haber verilecek kisiler : [ad / rol]
Yaygın hatalar
- Yedeği aynı sunucuda tutmak. Sunucu giderse yedek de gider. Fidye yazılımı tarafında bu hata, geri dönüş seçeneğinizi saldırganın eline verir.
- Yedeği hiç geri dönmeyi denememek. Arşiv bozuk, eksik ya da açılamıyor olabilir ve bunu ancak ihtiyaç duyduğunuz gün öğrenirsiniz. O gün öğrenmek için en kötü gündür.
- Veritabanını alıp medya klasörünü atlamak. Site açılır, bütün sayfalar yerinde durur, ama her görsel kırıktır. Geri dönüş teknik olarak başarılı, iş olarak başarısız sayılır.
- Yedekleri yıllarca saklayıp içinde müşteri verisi birikmesine izin vermek. Eski yedekler sipariş, iletişim ve form kayıtlarını taşır. Kişisel veriyi gereğinden uzun saklamak KVKK açısından sorun yaratır; saklama süresi bir depolama kararı değil, bir uyum kararıdır.
- Şifreleri yedeğin içinde düz metin bırakmak. Yapılandırma dosyaları veritabanı ve servis bilgilerini taşır. Yedek bir kez dışarı çıkarsa bu bilgiler de dışarı çıkmış olur; yedeği şifrelemek ve parolaları bir kasada tutmak gerekir.
- Yedek alma işini eski bir çalışanın kişisel hesabına bağlı bırakmak. Hesap kapandığında yedekleme sessizce durur ve bunu kimse fark etmez. Yedekleme kurumsal bir hesapla çalışmalı ve başarısızlık bildirimi birden fazla kişiye gitmelidir.
Ne zaman uzmana bırakmalı
Tek bir tanıtım sitesinde günlük bir yedek ve üç ayda bir tatbikat tek kişiyle yürür. İşin boyutu şurada değişir: sipariş alan bir mağazada veri kaybının saatle ölçüldüğü durumlar, birden fazla sunucuya ya da sağlayıcıya dağılmış bir yapı, e-posta ve dosya arşivlerinin de yasal saklama kapsamına girdiği işler, ve kurtarma süresinin sözleşmeyle bağlı olduğu durumlar. Bu dördünde yedekleme bir araç seçimi değil, bir süreç tasarımıdır.
Mevcut düzeninizin gerçekten geri dönüp dönmediğini ölçmek isterseniz teknik denetim çalışmamızda bileşen envanterini çıkarıp bir deneme kurulumuna gerçek bir geri dönüş yapıyoruz. Sorularınızı iletişim sayfasından yazabilirsiniz.
Devamını okumak için
Yedeğe en çok ihtiyaç duyulan an bir güvenlik olayıdır; hacklenen siteyi temizleme yazısı yedekten dönüşün hangi adımda yapılacağını anlatıyor. Alan adının kendisi düşerse yedek de işe yaramaz: alan adı süresi bittiğinde ne olur yazısı durum kodlarını ve geri alma penceresini açıklıyor. Posta kutularını taşımak ya da bir kopyasını almak için eski e-postaları yeni sunucuya taşıma yazısına bakın. Yedeklerde biriken kişisel veri için KVKK uyumlu müşteri verisi yazısı saklama tarafını ele alıyor. Tüm başlıklar blog sayfamızda, çalışma alanlarımız ana sayfamızda.