Kısaca özet
- Hosting yedeklemesi, sitenizin dosyalarının ve veritabanının düzenli aralıklarla ayrı bir yere kopyalanması ve gerektiğinde geri yüklenebilmesidir.
- Veri kaybının en sık dört sebebi var: hatalı eklenti güncellemesi, kullanıcı hatası, zararlı yazılım ve sunucu donanım arızası.
- Tam yedek her seferinde her şeyi kopyalar, geri dönüşü basittir; artımlı yedek yalnızca değişeni alır, yer kazandırır ama geri yükleme zincire bağlıdır.
- Dosya yedeği ile veritabanı yedeği ayrı iki iştir; yalnız birini almak siteyi ayağa kaldırmaya yetmez.
- Yedeği yalnızca sitenin durduğu sunucuda tutmak, yedek almamakla neredeyse aynı sonucu verir.
- Geri yükleme denemesi yapılmamış bir kopya, çalıştığı kanıtlanana kadar yedek sayılmaz.
Bir sabah siteye girdiğinizde beyaz ekran görmek ya da ana sayfada tanımadığınız bir yönlendirme bulmak, site sahiplerinin çoğunun başına en az bir kez gelir. O anda tek bir soru vardır: geriye dönebileceğimiz bir kopya var mı? Hosting yedeklemesi tam olarak bu soruya cevap veren sistemdir. Aşağıda yedeğin hangi senaryolarda işe yaradığını, tam ve artımlı yedek farkını, kopyanın nerede durması gerektiğini ve geri yükleme tatbikatının neden atlanmaması gerektiğini anlatıyoruz.
Hosting yedeklemesi neden hayati bir konu?
Bir sitenin değeri sunucudaki dosyalarda değil, o dosyalar ile veritabanının bütünlüğündedir. Ürün kayıtları, sipariş geçmişi, üye bilgileri, yıllarca yazılmış içerik; hepsi tek bir dizin ve tek bir veritabanı içinde durur. Bu ikisinden biri bozulduğunda site yayında görünse bile işlevsizdir.
Hosting yedeklemesi bu riski zamanla sınırlar. Elinizde sağlam bir kopya varsa sorun “site gitti” olmaktan çıkar, “kaç saatlik veri kaybettik” sorusuna döner. Kopya yoksa geriye yalnızca sunucu günlükleri, arama motoru önbelleği ve tahmin kalır. İkisi arasındaki fark çoğu işletme için birkaç saat ile birkaç ay arasındaki farktır.
Bilgi
Yedek ile arşiv aynı şey değildir. Yedek, olabildiğince yeni bir kopyayı hızlı geri yüklemek içindir. Arşiv ise geçmiş bir tarihe dönmek içindir. İkisini birlikte tutmak gerekir, çünkü zararlı yazılım günler sonra fark edildiğinde en yeni kopya da bulaşmış olabilir.
Veri kaybı en çok hangi senaryolarda yaşanıyor?
Sunucu yanması akla ilk gelen senaryodur ama pratikte en seyrek olanıdır. Yedeği asıl kullandıran olaylar çok daha sıradandır.
- Eklenti ya da tema güncellemesi. Uyumsuz bir sürüm yüklenir, site beyaz ekrana düşer ya da tasarım dağılır. Güncellemeyi geri almak çoğu zaman mümkün değildir, dosyaları geri yüklemek gerekir.
- Kullanıcı hatası. Yanlış dizinin silinmesi, yanlış veritabanı tablosunun boşaltılması, toplu düzenlemede bin ürünün fiyatının sıfırlanması. Panelde tek tıkla yapılan işlerin çoğunun geri alma düğmesi yoktur.
- Zararlı yazılım. Eski bir eklenti üzerinden kod enjekte edilir, sayfalara gizli bağlantılar eklenir ya da dosyalar şifrelenir. Parola denemeleriyle yapılan saldırıların nasıl işlediğini brute force yazımızda ayrıntılandırdık.
- Sunucu ya da disk arızası. RAID bile tek başına yedek değildir; disk kopyalama, silinen dosyayı da bozulan veriyi de anında ikinci diske yazar.
Örnek senaryo
Küçük bir mobilya satıcısı, sepet eklentisini otomatik güncellemeye açık bıraktı. Gece çıkan bir sürüm ödeme adımını bozdu ve sabaha kadar gelen siparişler yarım kaldı. Geliştirici sorunu iki saatte çözebilirdi ama panelden alınan bir gün öncesine ait tam yedek, siteyi on beş dakikada çalışır hâle getirdi. Kaybedilen tek şey, bozuk sürümün yayında kaldığı saatlerdeki birkaç yarım siparişti. Yedek olmasaydı kayıp, o günün cirosunun tamamı olacaktı.
Tam yedek ile artımlı yedek arasındaki fark
Yedekleme yöntemleri, her seferinde ne kadar veri kopyalandığına göre ayrılır. Seçim, disk alanı ile geri dönüş hızı arasındaki dengeye bakar.
| Yedek türü | Kapsam | Geri dönüş süresi | Kime uygun |
|---|---|---|---|
| Tam yedek | Dosyaların ve veritabanının tamamı | En kısa, tek dosyadan dönülür | Küçük ve orta ölçekli siteler |
| Artımlı yedek | Son yedekten bu yana değişen dosyalar | Uzun, zincirdeki tüm parçalar gerekir | Büyük dosya arşivi olan siteler |
| Diferansiyel yedek | Son tam yedekten sonra değişen her şey | Orta, tam yedek artı tek parça | Günlük değişimi yüksek siteler |
| Anlık görüntü | Sunucunun o andaki disk imajı | Çok kısa, sunucu bütün olarak döner | Sanal sunucu ve bulut kullananlar |
| Yalnız veritabanı | Tablolar ve kayıtlar | Kısa, dosyalar ayrıca gerekir | İçeriği sık değişen, dosyası sabit siteler |
Pratik kural şudur: tam yedek yer yer ama zaman kazandırır, artımlı yedek yer kazandırır ama zaman ister. Çoğu site için doğru kurgu ikisinin karışımıdır; haftada bir tam yedek, aralarda artımlı ya da diferansiyel kopyalar. Zincir mantığının bir zayıflığı vardır: aradaki tek bir parça bozulursa o tarihten sonraki tüm artımlı yedekler kullanılamaz hâle gelir.
Dosya yedeği ile veritabanı yedeği ayrı iki iştir
Bir web sitesi iki ayrı parçadan oluşur. Dosya tarafında tema, eklentiler, yüklediğiniz görseller ve yapılandırma dosyaları vardır. Veritabanı tarafında yazılar, sayfalar, ürünler, siparişler, yorumlar, kullanıcılar ve ayarlar durur.
Yalnızca dosyaları yedeklerseniz siteyi geri yüklediğinizde boş bir kurulum elde edersiniz. Yalnızca veritabanını yedeklerseniz içerik yerinde olur ama tema ve görseller eksik kalır. İki parçanın aynı ana ait olması da gerekir; farklı tarihlerden birleştirilen yedekler eksik tablo ve kırık görsel bağlantısı üretir. Veritabanı tarafının nasıl dışa aktarıldığı WordPress resmî veritabanı yedekleme belgesinde adım adım anlatılıyor.
Dikkat
Yedeği yalnızca sitenin çalıştığı sunucuda tutmak en yaygın hatadır. Disk bozulursa, hesap askıya alınırsa ya da bir saldırgan yetki ele geçirirse hem site hem de yedek aynı anda kaybolur. Zararlı yazılımların ilk yaptığı işlerden biri sunucudaki yedek dizinlerini silmektir. Sunucu içindeki kopya yalnızca hızlı geri dönüş içindir, tek kopyanız olamaz.
Yedek nerede saklanmalı — 3-2-1 kuralı
Saklama tarafında yıllardır değişmeyen bir ölçüt var. 3-2-1 kuralı üç şey ister: verinin en az üç kopyası, bu kopyaların en az iki farklı ortamda tutulması ve en az bir kopyanın sunucunun dışında olması.
Uygulamada bu şöyle görünür: birinci kopya yayındaki sitenin kendisi, ikinci kopya panel üzerinden alınan ve sunucuda duran yedek, üçüncü kopya ise indirip kendi bilgisayarınızda ya da ayrı bir depolama hesabında sakladığınız arşiv. Üçüncü kopya kuralın en çok atlanan ama en çok işe yarayan maddesidir.
Dış kopyayı almanın en basit yolu, panelin ürettiği yedek dosyasını düzenli olarak indirmektir. Panel arayüzleri arasındaki yetki ve araç farklarını WHM ve cPanel karşılaştırmamızda bulabilirsiniz. Dosyayı indirirken şifreleyip parola ile korumak da iyi bir alışkanlıktır; yedek dosyası veritabanı kullanıcı adınızı ve bağlantı bilgilerinizi de taşır.
Geri yükleme tatbikatı yapılmamış yedek, yedek değildir
Yedekleme sisteminin başarısı alınan kopya sayısıyla değil, geri yüklenebilen kopya sayısıyla ölçülür. Bozuk sıkıştırma, yarım kalan aktarım, eksik tablo ya da yanlış karakter seti yüzünden açılmayan arşivler sanıldığından yaygındır ve bu ancak gerçekten ihtiyaç duyulduğu gün fark edilir.
Tatbikat basittir. Panelde bir test alan adı ya da alt alan adı açın, son yedeği oraya geri yükleyin, ana sayfayı ve bir iç sayfayı açın, yönetim paneline girin, bir ürün ya da yazı kaydını kontrol edin. Yarım saatlik bu deneme, hosting yedeklemesi sisteminizin gerçekten çalışıp çalışmadığını gösteren tek kanıttır. Tatbikatı büyük bir güncelleme öncesinde tekrarlamak ayrıca güven verir.
WordPress sitelerinde hosting yedeklemesi nasıl kurgulanır?
WordPress’te yedeklenmesi gereken dosya tarafı bellidir: wp-content dizini ve wp-config.php. Çekirdek dosyaları gerektiğinde yeniden indirilebilir, ama temanız, eklentileriniz ve medya kitaplığınız yalnızca sizde vardır. Veritabanı tarafında ise tabloların tamamı alınır; tablo ön eki varsayılandan farklıysa bu ön ekin de not edilmesi gerekir.
Eklenti tabanlı çözümler işi kolaylaştırır, ancak sitenin kendi içinden çalıştıkları için site açılmadığında devreye giremezler. Bu yüzden eklenti yedeği ile panel yedeği birbirinin yerine geçmez, birbirini tamamlar. Hangi eklentilerin işinize yaradığını seçerken eklenti rehberimize göz atabilirsiniz. Resmî yaklaşım ve dizin listesi için WordPress yedekleme dokümantasyonu iyi bir başlangıçtır.
Altyapı seçimi de yedek düzenini etkiler. Paket kapsamındaki yedekleme seçeneklerini panelden kontrol etmek, hangi kopyanın hazır geldiğini ve hangisini kendinizin indirmesi gerektiğini netleştirir. WordPress için barındırma seçerken nelere bakıldığını ayrı bir yazıda ele aldık.
Sonuç
İşleyen bir hosting yedeklemesi düzeni üç şeye dayanır: dosya ve veritabanının birlikte alınması, en az bir kopyanın sunucu dışında durması ve geri yüklemenin en az bir kez denenmiş olması. Bu üçü tamamsa bir arıza günü kayıp değil, gecikme olarak kapanır.
Yedekleme kontrol listesi
- Dosya ve veritabanı yedeğinin aynı ana ait olduğunu doğrulayın.
- Paket kapsamındaki yedekleme seçeneklerini panelden kontrol edin.
- En az bir kopyayı sunucunun dışına indirin ve parola ile koruyun.
- Yedek dosyasının boyutunu takip edin; ani küçülme eksik yedek işaretidir.
- Büyük güncellemelerden önce elle bir tam yedek alın.
- Geri yükleme tatbikatını test alan adında en az bir kez yapın.
- Eski yedekleri düzenli temizleyin; disk dolduğunda yeni yedek alınamaz.
- Yedeklerin ne zaman ve nereye alındığını yazılı bir notta tutun.
Sıkça sorulan sorular
Hosting yedeklemesi ne sıklıkla alınmalı?
Ölçüt, kaybetmeyi göze alabileceğiniz veri miktarıdır. Haftada birkaç yazı eklenen bir tanıtım sitesinde haftalık kopya yeterli olabilir. Her gün sipariş alan bir mağazada günlük, hatta gün içinde ek bir kopya gerekir. Kendinize şunu sorun: en son yedekten bu yana girilen veriyi elle yeniden girebilir miyim?
Sunucudaki otomatik yedek tek başına yeterli mi?
Hayır. Sunucudaki kopya hızlı geri dönüş için idealdir ama diski, hesabı ya da sunucuyu etkileyen bir sorunda site ile birlikte kaybolur. En az bir kopya her zaman sunucunun dışında durmalıdır.
Artımlı yedek mi tam yedek mi seçmeliyim?
Site boyutu birkaç gigabaytın altındaysa tam yedek daha pratiktir; tek dosyadan dönersiniz. Medya arşivi büyüdükçe artımlı yedek disk ve süre açısından avantajlı hâle gelir, karşılığında geri yükleme zincire bağımlı olur. Yaygın çözüm haftalık tam, ara günlerde artımlı kopyadır.
Yedeğim var ama geri yükleyemiyorum, sebebi ne olabilir?
En sık üç sebep vardır: arşiv aktarım sırasında yarım kalmıştır, veritabanı dışa aktarımı karakter seti uyuşmazlığı taşımaktadır ya da yedek eski bir PHP sürümünde alınmış ve mevcut sürümle uyumsuzdur. Tatbikat bu üçünü de ihtiyaç anından önce ortaya çıkarır.
Zararlı yazılım bulaşmış siteyi yedekten dönerek temizleyebilir miyim?
Bulaşmanın hangi tarihte olduğunu biliyorsanız evet, o tarihten önceki bir kopyaya dönersiniz. Bu yüzden yalnızca en yeni yedeği değil, geriye dönük birkaç tarihi de saklamak gerekir. Dönüşten sonra giriş yolunu kapatmaz, parolaları ve eklentileri güncellemezseniz aynı açık kısa sürede tekrar kullanılır.
Narhost’ta
Hosting paketlerinde site dosyalarınızın ve veritabanınızın yedeği panel üzerinden alınabilir, indirilebilir ve geri yüklenebilir. Paket kapsamındaki yedekleme seçeneklerini ürün sayfasından inceleyebilirsiniz.