Web Sitesi Yedekleme Rehberi: 3-2-1 Kuralı ve Hosting Yedekleri

Bir web sitesinin verileri birçok nedenle kaybolabilir: hatalı bir eklenti güncellemesi, yanlışlıkla silinen bir klasör, zararlı yazılım bulaşması, fidye yazılımı, ele geçirilen bir yönetici hesabı veya donanım arızası. Bu durumların hepsinde sitenizi geri getirecek olan, düzenli alınmış ve çalıştığı doğrulanmış bir yedektir. Bu rehberde yedeklemenin temel ilkelerini, 3-2-1 kuralını ve hosting firmanızın aldığı yedeklerin neyi kapsayıp neyi kapsamadığını anlatıyoruz.

Bir web sitesinde neler yedeklenmeli?

Bir web sitesinin yedeği yalnızca dosyalardan ibaret değildir. Eksiksiz bir yedek şu bileşenleri içermelidir:

• Dosyalar: Uygulama dosyaları, tema ve eklentiler, kullanıcıların yüklediği görseller ve belgeler.
• Veritabanı: İçerikler, kullanıcı hesapları, siparişler ve ayarlar. WordPress gibi sistemlerde sitenin asıl değeri veritabanındadır.
• Yapılandırma: wp-config.php, .htaccess, ortam değişkenleri ve web sunucusu ayarları.
• E-postalar: E-posta hesapları aynı hostingteyse kutulardaki iletiler.
• DNS kayıtları: Bölgedeki tüm kayıtların bir kopyası. DNS sağlayıcısı değişirse veya bir kayıt yanlışlıkla silinirse geri dönmeyi kolaylaştırır.
• Zamanlanmış görevler ve entegrasyonlar: Cron işleri, API anahtarları ve harici servis ayarları.

Dosya ve veritabanı yedeklerinin aynı zamana ait olması önemlidir. Farklı zamanlarda alınmış dosya ve veritabanı yedekleri birlikte geri yüklendiğinde, örneğin veritabanında kaydı olan ama dosyası olmayan görseller gibi tutarsızlıklar oluşabilir.

Her şeyi yedeklemek de gerekli değildir. Önbellek klasörleri, geçici dosyalar ve yeniden oluşturulabilen küçük görsel kopyaları yedeğin boyutunu büyütür, ancak geri yüklemede değer katmaz. Bu klasörleri yedek dışında bırakmak hem depolama alanından hem de yedekleme süresinden tasarruf sağlar.

3-2-1 yedekleme kuralı nedir?

3-2-1 kuralı, veri kaybı riskini azaltmak için yaygın olarak kabul gören basit bir ilkedir:

• 3 kopya: Verinin biri canlı, ikisi yedek olmak üzere en az üç kopyası bulunmalıdır.
• 2 farklı ortam: Yedekler en az iki farklı depolama ortamında veya sistemde tutulmalıdır. Aynı diskte duran iki kopya, o disk arızalandığında birlikte kaybolur.
• 1 kopya başka konumda: Kopyalardan en az biri canlı sistemden fiziksel olarak ayrı bir konumda saklanmalıdır. Yangın, sel veya veri merkezi kaynaklı bir sorun tüm kopyaları aynı anda etkilememelidir.

Farklı ortam; sunucu diski, ayrı bir yedekleme sunucusu, nesne depolama hizmeti veya harici bir disk olabilir. Önemli olan, tek bir arızanın veya tek bir hesabın ele geçirilmesinin tüm kopyaları aynı anda etkilememesidir.

Fidye yazılımlarının yedekleri de hedef alması nedeniyle bu kural bugün sıklıkla 3-2-1-1-0 olarak genişletiliyor. Ek olarak bir kopyanın çevrimdışı veya değiştirilemez (immutable) olması, yani yazıldıktan sonra silinememesi ya da şifrelenememesi; geri yükleme testlerinde de sıfır hata alınması hedeflenir.

Bir web sitesi için uygulanabilir bir 3-2-1 düzeni şöyle olabilir: canlı site hosting sunucusunda, hosting firmasının aldığı otomatik yedek ayrı bir yedekleme sisteminde, sizin düzenli olarak indirdiğiniz veya bir bulut depolama hizmetine gönderdiğiniz kopya ise tamamen farklı bir konumda.

Hosting yedekleri neyi kapsar, neyi kapsamaz?

Hosting paketlerinin çoğunda otomatik yedekleme bulunur ve bu yedekler birçok sorunda hızlı bir geri dönüş imkânı sunar. Ancak hosting yedeğine tek başına güvenmeden önce şu soruların yanıtını bilmelisiniz:

• Sıklık: Yedek ne sıklıkla alınıyor? Günlük yedekte en kötü durumda bir günlük veri kaybedilir.
• Saklama süresi: Kaç günlük veya kaç haftalık geçmiş tutuluyor? Zararlı yazılım haftalarca fark edilmeden kalabilir; yalnızca son birkaç günün yedeği varsa temiz bir kopya bulmak zorlaşır.
• Konum: Yedekler canlı sunucuyla aynı yerde mi, yoksa farklı bir sistemde veya konumda mı?
• Kapsam: Dosyalar, veritabanları ve e-postalar dahil mi?
• Geri yükleme: Tek bir dosya veya veritabanı geri getirilebiliyor mu, geri yükleme nasıl talep ediliyor?
• Bildirim: Bir yedekleme başarısız olduğunda bunun fark edilip edilmediği ve size bilgi verilip verilmediği.

Hosting yedeği, hosting firmasının sunduğu ek bir güvencedir ve kendi yedek sorumluluğunuzu ortadan kaldırmaz. Hizmet sözleşmeleri de genellikle müşterinin kendi bağımsız yedeğini almasını öngörür. Hesaba erişimin kaybedilmesi gibi durumlarda elinizdeki tek kopya kendi aldığınız yedek olabilir.

RAID yedek değildir

Sunucularda kullanılan RAID yapıları, disklerden biri arızalandığında sistemin çalışmaya devam etmesini sağlar. Ancak RAID verinin anlık bir aynasıdır: yanlışlıkla sildiğiniz bir dosya veya zararlı yazılımın şifrelediği bir veritabanı, tüm disklerde aynı anda silinir ya da şifrelenir. RAID donanım arızasına karşı koruma sağlar, yedeğin yerini tutmaz.

YetkinBulutNet paketlerinde yedekleme

YetkinBulutNet hosting paketlerinde yedekler JetBackup ile alınır. Yedekleme sıklığı pakete göre değişir:

• cPanel Hosting paketlerinin tamamında otomatik yedekleme bulunur; Standart paket günlük yedekleme içerir.
• Kurumsal Hosting paketlerinden Kurumsal S’de günlük ve haftalık, Kurumsal M, L ve XL’de saatlik yedek alınır.
• WordPress Hosting ve Reseller Hosting paketlerinde günlük yedek alınır.
• Plesk Hosting’de Plesk Pro ve üzeri paketlerde günlük yedek bulunur.
• Ucuz Hosting paketlerinden Eko+ ve Eko Pro’da haftalık yedek alınır; Mini ve Eko paketlerinde yedeğinizi kendiniz almanızı öneririz.

Paket özelliklerinde belirtilen harici yedekler, canlı sunuculardan ayrı olarak Almanya’da (Frankfurt) bunny.net altyapısında saklanır. Bu, 3-2-1 kuralındaki başka konumda bir kopya ilkesini hosting tarafında karşılar. Yine de kendi bağımsız yedeğinizi almanızı öneririz.

Sanal sunucularda yedekleme

Sanal sunucularda işletim sistemi, yazılım ve yedekleme, yönetimli hizmet alınmadıkça sunucu sahibinin sorumluluğundadır. Sanal Sunucu paketlerinin bir kısmında haftalık veya günlük snapshot bulunur. Snapshot, sunucu diskinin belirli bir andaki tam görüntüsüdür ve büyük bir güncelleme öncesinde geri dönüş noktası olarak kullanışlıdır. Ancak snapshot tek başına bir yedekleme düzeni değildir; veritabanlarının ve dosyaların uygulama düzeyinde, sunucu dışındaki bir konuma da yedeklenmesi gerekir. Çalışan bir veritabanının dosyalarını doğrudan kopyalamak tutarsız bir yedek üretebileceği için veritabanı yedeklerini mysqldump gibi araçlarla veya veritabanının kendi yedekleme yöntemleriyle alın.

Kendi yedeğinizi nasıl alırsınız?

Kontrol paneliyle

cPanel’de Yedekleme (Backup) bölümünden ev dizininizi, veritabanlarınızı ve e-posta yönlendirmelerinizi ayrı ayrı indirebilir veya tam hesap yedeği oluşturabilirsiniz. Plesk’te Yedekleme Yöneticisi (Backup Manager) benzer bir işlev görür ve yedekleri harici bir depolama alanına göndermeye izin verir. İndirdiğiniz yedekleri yalnızca bilgisayarınızda bırakmak yerine harici bir diske veya bulut depolama alanına da kopyalayın.

WordPress eklentileriyle

WordPress siteleri için dosya ve veritabanını belirli aralıklarla paketleyip harici bir bulut depolama hizmetine gönderen yedekleme eklentileri vardır. Eklenti seçerken zamanlama, harici depolama desteği ve geri yükleme kolaylığına bakın. Yedekleri sitenin bulunduğu sunucuda bırakan bir ayar, sunucu kaynaklı bir sorunda işe yaramaz.

Bulut depolama seçerken

Yedekleri bir bulut depolama hizmetine gönderecekseniz şu noktalara bakın: verinin hangi ülkede saklandığı, aktarım ve saklama sırasında şifreleme yapılıp yapılmadığı, silinen veya üzerine yazılan dosyaların eski sürümlerinin tutulup tutulmadığı (sürümleme) ve veriyi geri indirirken ek ücret alınıp alınmadığı. Kişisel veri içeren yedeklerde saklama konumunun KVKK açısından değerlendirilmesi gerekir.

Sunucularda betik ve araçlarla

Sanal sunucularda veritabanları mysqldump veya pg_dump gibi araçlarla dışa aktarılır. Dosyalar rsync, restic veya borg gibi araçlarla şifrelenmiş ve artımlı (incremental) olarak başka bir sunucuya ya da nesne depolama alanına gönderilir. Bu işlemler cron ile zamanlanır ve sonuçlarının e-postayla bildirilmesi sağlanır.

Ne zaman ayrıca elle yedek almalısınız?

Otomatik yedekler düzenli aralıklarla alınır; ancak bazı işlemlerden hemen önce elle yedek almak, son otomatik yedekten sonraki değişiklikleri de korur:

• WordPress çekirdeği, tema veya eklenti güncellemelerinden önce
• Tema değişikliği, büyük tasarım düzenlemeleri veya yeni bir eklenti denemesinden önce
• PHP sürümünü yükseltmeden önce
• Siteyi başka bir hostinge veya sunucuya taşımadan önce
• Toplu ürün, fiyat veya içerik içe aktarmalarından önce
• Kullanıcı ve yetki ayarlarında toplu değişiklik yapmadan önce

Yedekleme sıklığı ve saklama süresi nasıl belirlenir?

Doğru sıklığı belirlemek için kendinize şu soruyu sorun: Ne kadar veriyi kaybetmeyi göze alabilirim? Bu süreye RPO (Recovery Point Objective) denir. Haftada bir içerik eklenen bir kurumsal sitede haftalık yedek yeterli olabilir; her saat sipariş alan bir e-ticaret sitesinde ise günlük yedek bile bir günlük siparişin kaybı anlamına gelir.

İkinci soru, sitenin ne kadar sürede yeniden çalışır hale gelmesi gerektiğidir. Buna RTO (Recovery Time Objective) denir. Yedeğin nerede olduğu, ne kadar büyük olduğu ve geri yükleme adımlarının ne kadar net olduğu bu süreyi doğrudan etkiler.

Saklama süresini belirlerken zararlı yazılımların uzun süre fark edilmeyebileceğini unutmayın. Günlük yedeklerin yanında haftalık ve aylık kopyaları daha uzun süre saklamak, örneğin 7 günlük, 4 haftalık ve birkaç aylık kopya tutmak iyi bir dengedir.

Yedekleme yöntemi de saklama planını etkiler. Tam yedek her seferinde tüm verinin kopyasını alır; geri yüklemesi kolaydır ama çok yer kaplar. Artımlı (incremental) yedek ise yalnızca son yedekten bu yana değişen verileri saklar ve daha az alan kullanır; geri yükleme sırasında tam yedek ile sonraki artımlı yedekler birlikte kullanılır. Birçok yedekleme aracı bu iki yöntemi bir arada kullanır.

Geri yükleme testi: yedeğin çalıştığından emin olun

Hiç geri yüklenmemiş bir yedeğin çalışıp çalışmadığını bilemezsiniz. Bozuk bir arşiv, eksik bir veritabanı veya unutulmuş bir klasör ancak geri yükleme sırasında fark edilir. Bu nedenle belirli aralıklarla, örneğin üç ayda bir, yedeği bir test ortamına geri yükleyip sitenin açıldığını ve verilerin eksiksiz olduğunu kontrol edin.

• Yedeği canlı siteden ayrı bir alana veya yerel bilgisayarınıza geri yükleyin.
• Sayfaların, yönetim panelinin ve formların çalıştığını kontrol edin.
• Veritabanındaki son kayıtların tarihine bakarak yedeğin ne kadar güncel olduğunu doğrulayın.
• Geri yükleme adımlarını ve ne kadar sürdüğünü not edin. Gerçek bir sorun yaşandığında bu not zaman kazandırır.

Yedekleri korumak

Yedek dosyaları veritabanı şifreleri, müşteri bilgileri ve API anahtarları içerebilir. Bu nedenle yedekleri şifreleyin ve erişim bilgilerini canlı sunucudan ayrı bir yerde tutun. Canlı sunucu ele geçirildiğinde saldırganın yedek deposuna da ulaşamaması için yedek deposunun bilgilerini sunucuda açık metin olarak bırakmayın; mümkünse yalnızca yazma izni veren, silme izni vermeyen erişim anahtarları kullanın. Kişisel veri içeren yedeklerin KVKK kapsamında korunması da gerekir.

Siteyi başka bir hostinge taşırken yedeklerin nasıl kullanıldığını web sitesi taşıma rehberimizde anlattık.

Sonuç

Yedekleme, bir sorun yaşandığında sitenizi geri getiren önlemdir. 3-2-1 kuralını uygulayın, hosting yedeğini ek bir güvence olarak görün, kendi bağımsız yedeğinizi farklı bir konumda tutun ve yedeklerinizi düzenli olarak geri yükleyerek test edin. Bugün bir yedekleme planınız yoksa ilk adım olarak sitenizin tam yedeğini indirip farklı bir konuma kaydedin, ardından sitenize uygun sıklıkta düzenli bir plan oluşturun.