Yedekleme Stratejisi: Hostingde Veri Kaybına Karşı Korunma

Yedekleme stratejisi, verinizin hangi senaryoda nasıl geri getirileceğini önceden tanımlayan plandır. Temeli 3-2-1 kuralıdır: verinin en az üç kopyası bulunur, bu kopyalar iki farklı ortamda saklanır ve en az biri fiziksel olarak başka bir lokasyonda tutulur. Stratejiyi tamamlayan asıl unsur ise düzenli geri yükleme testidir; çünkü açılmayan bir yedek dosyası, hiç yedek almamakla aynı anlama gelir.

Veri kaybı, çoğu site sahibinin hayal ettiği gibi dramatik bir olayla gelmez. Gerçek hayatta olan şey çok daha sıradandır: bir eklenti güncellemesi siteyi beyaz ekrana çevirir, bir çalışan yanlış klasörü siler, bir tema açığından giren saldırgan dosyalara zararlı kod enjekte eder ya da bir veritabanı tablosu bozulur. Hepsinin ortak noktası aynıdır: geri dönebileceğiniz sağlam bir kopyanız varsa olay bir aksaklıktır, yoksa felakettir.

Bu yazı, yedek almanın ne olduğunu değil, yedekleme stratejisinin nasıl kurulacağını anlatıyor: sıklık, saklama süresi, konum ve en kritik parçası olan geri yükleme testi.

Veri Kaybı Senaryoları ve Hangi Yedek Kurtarır?

Her yedek türü her felaketi çözmez. Bir stratejiyi kurmanın ilk adımı, korunmak istediğiniz senaryoları listelemek ve her birinin hangi tür kopya ile kurtarılabileceğini görmektir. Aşağıdaki tablo, hosting dünyasında en sık karşılaşılan beş kayıp senaryosunu ve bunlara karşı işe yarayan yedek tipini gösteriyor.

Senaryo	Ne olur?	Hangi yedek kurtarır?	Kritik nokta
Yanlışlıkla silme	Bir klasör, bir sayfa veya bir ürün grubu yanlışlıkla silinir. Fark edilmesi bazen günler sürer.	Günlük otomatik yedek; ideal olarak birkaç gün geriye giden sürüm geçmişi.	Tek bir günlük kopya tutuluyorsa ve hata geç fark edilirse, yedek de yanlış hâli içerir. Bu yüzden 7-30 günlük saklama gerekir.
Hack veya fidye yazılımı	Dosyalara zararlı kod enjekte edilir ya da tüm veri şifrelenip para istenir.	Bulaşma tarihinden ÖNCEye ait, sunucudan bağımsız ve değiştirilemez (immutable) dış kopya.	Sunucuya bağlı duran yedek de şifrelenebilir. Bulaşma tarihini doğru tespit etmeden geri dönerseniz zararlı kodu geri yüklersiniz.
Sunucu veya disk arızası	Fiziksel disk bozulur, sunucu açılmaz, donanım arızalanır.	Farklı bir makinede duran tam yedek veya anlık görüntü (snapshot).	Aynı sunucunun içinde tutulan yedek burada tamamen değersizdir. Kopyanın başka bir donanımda olması şarttır.
Güncelleme veya yayın hatası	Eklenti, tema veya kod güncellemesi siteyi bozar; ödeme adımı çalışmaz olur.	Değişiklikten hemen önce alınmış manuel yedek veya anlık görüntü.	En kolay önlenen senaryodur: her güncellemeden önce tek tıkla yedek alma alışkanlığı yeterlidir.
Veritabanı bozulması	Tablolar bozulur, sipariş veya üye kayıtları okunamaz hâle gelir.	Ayrı alınmış, sık aralıklı veritabanı dökümü (SQL dump).	Dosya yedeği ile veritabanı yedeği farklı şeylerdir. Dosyalar sağlam olsa bile bozuk veritabanıyla site çalışmaz.

Tabloda dikkat çeken şey şudur: hiçbir senaryo tek bir yedek türüyle tam olarak çözülmüyor. İşte bu yüzden yedekleme bir ürün değil, bir stratejidir.

3-2-1 Kuralı: Stratejinin Omurgası

Yedekleme dünyasında onlarca yıldır ayakta kalan tek kural 3-2-1 kuralıdır. Karmaşık görünmez, çünkü değildir:

• 3 kopya: Verinin aslı ve en az iki yedeği bulunur. Tek yedek, o yedek bozulduğunda sıfır yedek demektir.
• 2 farklı ortam: Kopyalar aynı türde iki cihazda durmaz. Örneğin biri sunucunun diskinde, diğeri ayrı bir yedekleme deposunda ya da harici bir depolama alanında olur.
• 1 dış lokasyon: En az bir kopya, veriyi üreten sunucunun bulunduğu fiziksel yerden başka bir yerde durur. Aynı binadaki iki disk, bina düzeyindeki bir olayda birlikte gider.

Modern uygulamada bu kurala bir madde daha eklenir: kopyalardan en az biri değiştirilemez (immutable) ya da çevrimdışı olmalıdır. Sebebi fidye yazılımlarıdır. Günümüz fidye yazılımları önce yedekleri arar ve siler; bağlı bir ağ diskinde duran, silinebilir bir yedek onlar için sadece bir dosya daha demektir.

RPO ve RTO: Stratejinizin İki Sayısı

Yedekleme sıklığını duyguyla değil, iki basit soruyla belirlersiniz. Bu iki sorunun cevabı, kurumsal dünyada RPO ve RTO diye adlandırılır ve aslında son derece somuttur.

RPO (Recovery Point Objective) — Ne kadar veri kaybını göze alabilirsiniz? Diyelim ki gece yarısı bir felaket oldu ve son yedeğiniz dün sabah alınmış. Aradaki tüm siparişler, formlar, yorumlar ve içerikler kaybolur. Kabul edebileceğiniz bu kayıp penceresi RPO’nuzdur. Haftada bir güncellenen bir kurumsal tanıtım sitesi için 24 saatlik RPO gayet makuldür. Günde onlarca sipariş alan bir e-ticaret sitesi için 24 saat, kabul edilemez bir para kaybıdır; orada saatlik veritabanı yedeği gerekir.

RTO (Recovery Time Objective) — Site ne kadar süre kapalı kalabilir? Yedeğiniz mükemmel olabilir; ama geri yüklemek 12 saat sürüyorsa siteniz 12 saat kapalı demektir. RTO, kesintiye tahammül sürenizdir. Panelden tek tıkla geri yükleme yapılabilen bir yapıda RTO dakikalarla ölçülür; harici bir diskten elle dosya taşımak ve veritabanını yeniden kurmak gerekiyorsa saatlere çıkar.

Bu iki sayı ihtiyacınız olan altyapıyı da belirler: sıfıra yakın RPO ve RTO isteyen kritik uygulamalar, yedeklemenin yanına yüksek erişilebilirlik gibi ek mimariler ister. Çoğu KOBİ sitesi için ise günlük yedek ve saatler içinde geri dönüş fazlasıyla yeterlidir.

Yedek Türleri: Hangisi Ne İşe Yarar?

Yedek deyince akla tek bir şey gelmez. Farklı türler farklı maliyet, sıklık ve geri dönüş süresi sunar. Sağlıklı bir strateji genellikle bunların birkaçını birlikte kullanır.

Yedek Türü	Nasıl çalışır?	Tipik sıklık	Saklama	Geri dönüş süresi
Tam yedek	Tüm dosyaların ve veritabanının eksiksiz kopyası alınır.	Haftalık (veya paylaşımlı hostingte günlük)	1-4 hafta	Orta; tek pakette her şey vardır, kurulumu basittir.
Artımlı yedek	Yalnızca son yedekten sonra değişen dosyalar kopyalanır. Yer ve bant genişliğinden büyük tasarruf sağlar.	Günlük veya saatlik	2-4 hafta	Daha uzun; zinciri baştan sona uygulamak gerekir. Zincirin bir halkası bozuksa sonrası da riske girer.
Anlık görüntü (snapshot)	Sunucunun o andaki tüm disk durumu dondurulur. Kritik bir güncelleme öncesi geri dönüş noktası açmak için idealdir.	İhtiyaç anında; ayrıca günlük otomatik	Birkaç gün	Çok kısa; sunucu birkaç dakika içinde önceki hâline döner.
Veritabanı dökümü	Yalnızca veritabanı dışa aktarılır. Küçük boyutlu olduğu için çok sık alınabilir.	Saatlik veya günde birkaç kez	1-2 hafta	Kısa; ancak dosyalar ayrıca gerekir.
Dış lokasyon kopyası	Yedek, sunucudan tamamen bağımsız bir yere (nesne depolama, uzak sunucu, ofis diski) aktarılır.	Günlük veya haftalık	1-6 ay	Uzun; ama sunucu tamamen kaybolduğunda hayatta kalan tek kopya budur.

Pratik bir kombinasyon şöyledir: sunucuda günlük otomatik tam yedek (hızlı geri dönüş için), saatlik veritabanı dökümü (yeni siparişleri kaybetmemek için) ve haftalık dış lokasyon kopyası (felaket için). Bulut sunucu kullanıyorsanız anlık görüntü özelliği, güncelleme öncesi güvenlik ağı olarak bu tabloya kolayca eklenir.

Yedekleme Stratejisi Kurma Adımları

Aşağıdaki altı adım, hem tek kişilik bir blog hem de kurumsal bir e-ticaret sitesi için aynı sırayla işler. Değişen tek şey, adımların altını doldurduğunuz sayılardır.

1. Kritik veriyi belirleyin. Her şeyi yedeklemek pahalı ve gereksizdir; hiçbir şeyi yedeklememek ise ölümcül. Önce şunu sorun: kaybedersem işim durur mu? Veritabanı (siparişler, üyeler, içerikler), yüklenen medya dosyaları, tema ve eklenti özelleştirmeleri, yapılandırma dosyaları ve e-posta kutuları bu listeye girer. Önbellek klasörleri ve yeniden üretilebilen dosyalar girmez.
2. Sıklığı (RPO) belirleyin. Kaç saatlik veriyi kaybetmeyi göze alabileceğinizi somut olarak yazın. İçerik nadiren değişiyorsa günlük yedek yeterlidir. Sürekli sipariş veya kullanıcı verisi üretiliyorsa veritabanı için saatlik yedeklemeye geçin. Bu sayıyı tahmin değil, iş gereksinimi belirler.
3. 3-2-1 kuralını uygulayın. Yedeklerinizi sayın. Aslı dahil kaç kopya var? Kaç farklı ortamda duruyorlar? Cevap sizi rahatsız ediyorsa, strateji henüz yoktur. Bu adımda eksik olan kopyaları planlayın.
4. Dış lokasyon kopyasını kurun. Sunucunuzdan bağımsız en az bir hedef seçin: nesne depolama alanı, başka bir veri merkezindeki sunucu ya da şirket içi bir disk. Bu aktarımı elle değil, otomatik ve düzenli çalışan bir görevle yapın. Elle yapılan hiçbir yedekleme uzun vadede sürdürülemez.
5. Geri yükleme testini yapın. Bu, en çok atlanan adımdır. Yedeğinizin varlığı bir şey ifade etmez; açılabilir olması ifade eder. Üç ayda bir, bir test alanına gerçek bir geri yükleme yapın. Site açılıyor mu? Veritabanı bağlanıyor mu? Görseller yerinde mi? Sipariş kayıtları tam mı? Geri yükleme kaç dakika sürdü? Bu son sayı, gerçek RTO’nuzdur; sandığınız değer değil.
6. İzleyin ve uyarı kurun. Sessizce başarısız olan yedekleme işi, olmayan yedekleme işinden daha tehlikelidir; çünkü size güvende olduğunuzu düşündürür. Yedekleme görevinin başarılı bittiğine dair bir bildirim alın, yedeğin boyutunu takip edin (aniden küçülmesi alarm sebebidir) ve saklama süresi dolan kopyaların otomatik silindiğini doğrulayın.

Geri Yükleme Testi Neden Her Şeyden Önemli?

Sahadaki en acı hikâyeler yedeği olmayanlardan değil, yedeği olduğunu sanan sitelerden çıkar. En sık rastlanan üç sürpriz şudur: yedekleme işi haftalardır sessizce hata veriyordur ve kimse fark etmemiştir; yedek dosyası vardır ama veritabanı dökümü boştur; ya da yedek eksiksizdir, fakat geri yükleme prosedürünü kimse bilmediği için kesinti saatlerce uzar. Üçü de tek bir alışkanlıkla önlenir: yılda üç dört kez, üretimi riske atmadan bir test alanında yapılan geri yükleme provası.

Fidye Yazılımı: Yedeklemenin En Sert Sınavı

Fidye yazılımı, yedekleme stratejinizi diğer tüm senaryolardan daha acımasız biçimde test eder. Çünkü sıradan bir arıza gibi davranmaz; aktif olarak yedeklerinizi arar, ulaşabildiklerini siler veya şifreler ve sizi çaresiz bırakmayı hedefler.

Bu tehdide karşı üç ilke geçerlidir. Birincisi, en az bir yedek kopyası sunucudan erişilemez olmalıdır; sunucuya sürekli bağlı duran bir ağ diskindeki yedek, saldırgan için ulaşılabilir bir hedeftir. İkincisi, saklama süresi yeterince uzun olmalıdır; çünkü zararlı yazılım genellikle sisteme girdikten sonra günlerce hatta haftalarca sessiz kalır ve şifrelemeyi sonra başlatır. Sadece 3 günlük yedeğiniz varsa, geri dönebileceğiniz tüm noktalar zaten bulaşmış olabilir. Üçüncüsü, önleme katmanı yedeklemeden ucuzdur: sunucu tarafında zararlı yazılım tarama ve karantina sistemleri (Alastyr paylaşımlı hosting altyapısında Imunify360 bu işi yapar), güncel yazılımlar, güçlü parolalar ve iki adımlı doğrulama olayın hiç yaşanmamasını sağlar.

Alastyr’de Yedekleme Nasıl İşliyor?

Alastyr paylaşımlı hosting paketlerinde yedekleme, ek ücretli bir modül değil paketin standart parçasıdır:

• Günlük otomatik yedekleme: Site dosyalarınız ve veritabanlarınız her gün otomatik olarak yedeklenir. Bunun için bir ayar yapmanız veya bir görev kurmanız gerekmez.
• Panelden geri yükleme: Yedeği geri almak için destek talebi açıp beklemenize gerek yok; kontrol panelinden istediğiniz geri dönüş noktasını seçip geri yükleme başlatabilirsiniz. Bu, RTO’yu saatlerden dakikalara indirir.
• Kendi veri merkezimiz: Sunucularımız İzmir’deki kendi N+1 yedekli veri merkezimizde çalışır. Altyapı üçüncü bir tarafa kiralanmış değildir; enerji, soğutma ve ağ katmanları yedeklidir.
• Zararlı yazılım koruması: Imunify360, sunucu tarafında zararlı dosya taraması ve saldırı engelleme yaparak fidye ve enjeksiyon senaryolarının önüne geçer.
• ISO 27001 ve 7/24 destek: Süreçler bilgi güvenliği yönetim standardına göre işletilir; bir kriz anında gece yarısı da olsa ulaşabileceğiniz bir ekip vardır.

Bulut sunucu ve VDS tarafında ise kontrol tamamen sizdedir: anlık görüntü alabilir, kendi yedekleme aracınızı kurabilir ve kopyaları dilediğiniz dış hedefe gönderebilirsiniz. Yönetim yükünü almak istemeyen kurumlar için kurumsal hosting tarafında yedekleme politikası ihtiyaca göre birlikte tasarlanır.

Dürüst Uyarı: Sağlayıcı Yedeği Tek Başına Yeterli Değildir

Bu bölümü satış cümlesi olarak değil, samimi bir uyarı olarak yazıyoruz. Günlük otomatik yedekleme güçlü bir güvenlik ağıdır ve çoğu kazayı sorunsuz kurtarır. Ancak hiçbir sağlayıcının yedeği, sizin kendi kopyanızın yerini tutmaz ve şu üç sebeple tek dayanağınız olmamalıdır:

• Aynı ekosistem riski: Sağlayıcı yedeği tanımı gereği sağlayıcının altyapısı içindedir. Kendi elinizde duran bir kopya, hesabınızla ilgili herhangi bir sorunda (ödeme aksaması, yanlışlıkla hesap kapatma) da sizi korur.
• Saklama süresi sınırlıdır: Otomatik yedekler belirli bir süre saklanır ve eskiler dönüşümlü olarak silinir. Aylar önce silinmiş bir sayfayı geri istediğinizde o dönemin yedeği artık var olmayabilir; uzun süreli arşiv ihtiyacı sizin sorumluluğunuzdadır.
• Kararı siz verirsiniz: Hangi tarihe dönüleceğine, hangi verinin kritik olduğuna ve geri yüklemenin ne zaman yapılacağına karar verecek olan sizsiniz; bunun için kendi kontrol listenizin olması gerekir.

Uygulamadaki karşılığı basittir: sağlayıcının günlük yedeğine güvenin, ama ayda bir kendi bilgisayarınıza ya da bulut depolamanıza tam bir kopya indirin. Bu on dakikalık alışkanlık, stratejinizin dış lokasyon ayağını tamamlar. Şeffaf fiyatlandırma ilkemiz gereği yedekleme, sonradan fatura edilen bir eklenti değil paketin içindedir.

Sıkça Sorulan Sorular

Hosting sağlayıcımın günlük yedeği benim için yeterli mi?

Günlük otomatik yedekleme kazaların büyük bölümünü kurtarır ve olmazsa olmazdır; ancak tek dayanağınız olmamalıdır. Sağlayıcı yedeği tanımı gereği sağlayıcının altyapısı içinde durur, saklama süresi sınırlıdır ve aylar öncesine dönmek isterseniz o kopya artık bulunmayabilir. Doğru yaklaşım şudur: sağlayıcının günlük yedeğini güvenlik ağı olarak kullanın, ayrıca ayda bir kendi elinizde duran tam bir kopya indirin. Böylece 3-2-1 kuralının dış lokasyon maddesini de gerçekten karşılamış olursunuz.

3-2-1 kuralı küçük bir site için abartı değil mi?

Hayır, çünkü kural bir bütçe değil bir mantık tanımlar. Küçük bir site için uygulaması son derece ucuzdur: aslı sunucunuzda durur, ikinci kopya hosting paketinizin günlük otomatik yedeğidir, üçüncü kopya ise ayda bir indirdiğiniz ve bulut depolamanızda tuttuğunuz arşivdir. Ek bir maliyet çıkmadan üç kopya, iki ortam ve bir dış lokasyon şartını karşılamış olursunuz. Kuralın amacı pahalı sistem kurmak değil, tüm kopyaların aynı anda yok olabileceği bir yapıyı engellemektir.

Ne sıklıkla yedek almalıyım?

Cevabı belirleyen soru şudur: kaç saatlik veriyi kaybetmeyi göze alabilirsiniz? Bu değere RPO denir. İçeriği ayda birkaç kez güncellenen kurumsal bir tanıtım sitesi için günlük yedek fazlasıyla yeterlidir. Günde onlarca sipariş alan bir e-ticaret sitesinde ise 24 saatlik kayıp doğrudan para kaybı demektir; orada dosyalar günlük, veritabanı ise saatlik yedeklenmelidir. Ayrıca sıklıktan bağımsız olarak her büyük güncelleme ve yayın öncesinde elle bir yedek almak iyi bir alışkanlıktır.

Fidye yazılımı yedeklerimi de şifreleyebilir mi?

Evet ve modern fidye yazılımları bunu bilinçli olarak hedefler. Sisteme girdikten sonra önce erişebildikleri yedekleri arar, siler ya da şifreler; ancak ondan sonra asıl veriyi kilitler. Bu nedenle sunucuya sürekli bağlı duran bir disk veya ağ paylaşımındaki yedek güvenli sayılmaz. En az bir kopyanın sunucudan erişilemeyen, değiştirilemez ya da çevrimdışı bir ortamda tutulması gerekir. Ayrıca zararlı yazılımlar genellikle günlerce sessiz kaldığı için saklama süresinin yeterince uzun olması, bulaşma öncesine dönebilmek açısından kritiktir.

Geri yükleme testini nasıl yaparım?

Testi asla üretimdeki siteniz üzerinde denemeyin. Bir test alt alan adı veya geçici bir sunucu açın, en güncel yedeğinizi oraya geri yükleyin ve şu kontrol listesini uygulayın: site açılıyor mu, veritabanı bağlanıyor mu, görseller ve yüklenen dosyalar yerinde mi, üyelik ve sipariş kayıtları eksiksiz mi, formlar çalışıyor mu? İşlemin toplam kaç dakika sürdüğünü de not edin; bu süre gerçek geri dönüş sürenizdir. Bu provayı üç ayda bir tekrarlamak, kriz anında panik yerine prosedür uygulamanızı sağlar.

Yedeklerimi nerede saklamalıyım?

Kural nettir: en az bir kopya, veriyi üreten sunucudan fiziksel olarak başka bir yerde durmalıdır. Sunucunun kendi diskinde tutulan yedek, disk arızasında ya da sunucu ele geçirildiğinde birlikte gider. Uygun hedefler nesne depolama alanları, başka bir veri merkezindeki bir sunucu, kurumsal bulut depolama hesapları veya şirket içinde tutulan harici bir diskdir. Önemli olan bu aktarımın elle değil, otomatik ve düzenli çalışan bir görevle yapılmasıdır; elle sürdürülen yedekleme rutini birkaç ay içinde mutlaka aksar.

Yedekleri ne kadar süre saklamalıyım?

Sadece son yedeği tutmak yaygın ama tehlikeli bir hatadır; çünkü bir sorunun fark edilmesi günler sürebilir ve o sırada tek yedeğiniz zaten bozuk hâli içerir. Pratik bir kademelendirme şöyledir: son 7-14 günün günlük yedekleri, son 4-8 haftanın haftalık yedekleri ve son 6-12 ayın aylık arşivleri. Bu yapı hem yanlışlıkla silinen bir içeriği hem de geç fark edilen bir zararlı yazılım bulaşmasını geri almanıza imkân tanır. Yasal saklama yükümlülüğü olan ticari kayıtlar için süreler daha uzun tutulmalıdır.

Sitem hacklendi, hangi yedeğe dönmeliyim?

Doğrudan en son yedeğe dönmek en sık yapılan hatadır; çünkü saldırgan sisteme büyük olasılıkla daha önce girmiştir ve o yedek zaten arka kapı içerir. Önce bulaşma tarihini tespit edin: sunucu erişim kayıtları, dosya değişiklik zamanları ve zararlı yazılım tarama sonuçları bu tarihi gösterir. Ardından bulaşma tarihinden önceki bir yedeğe dönün, tüm parolaları değiştirin, tema ve eklentileri güncel sürümlere getirin ve giriş noktası olan açığı kapatın. Açığı kapatmadan yapılan geri yükleme, birkaç gün içinde aynı sonucu doğurur.

Dosya yedeği ile veritabanı yedeği arasındaki fark nedir?

Dosya yedeği; tema, eklenti, görsel ve yüklenen belgeler gibi diskte duran her şeyi kapsar. Veritabanı yedeği ise içeriklerin, üye kayıtlarının, siparişlerin ve ayarların tutulduğu veritabanının dışa aktarılmış hâlidir. İkisi birbirinin yerine geçmez: dosyalarınız eksiksiz olsa bile bozuk veya eksik bir veritabanıyla siteniz açılmaz; veritabanınız sağlam olsa bile dosyalar olmadan içerik boş bir kabuktan ibarettir. Bu yüzden yedekleme planı ikisini de kapsamalı ve veritabanı, boyutu küçük olduğu için genellikle daha sık yedeklenmelidir.