Web sitesi yedekleme (backup) stratejisi nasıl kurulur? Otomatik backup, off-site depolama, veritabanı yedekleme ve felaket kurtarma planı. Solid Medya'dan hosting güvenliği ve veri koruma rehberi.
Bir web sitesi bir gecede kaybolabilir: hatalı bir güncelleme dosyaları bozar, bir eklenti açığı yüzünden site ele geçirilir, yanlış bir silme komutu veritabanını götürür ya da sunucu bir disk arızası yaşar. Yedeğiniz yoksa sıfırdan yeniden kurmak haftalar sürebilir, eksik kalan siparişler ve müşteri kayıtları ise geri gelmeyebilir.
Neyin yedeklenmesi gerektiği, 3-2-1 kuralı, yedek sıklığı, veritabanı yedeğinin püf noktaları ve bir felaket kurtarma planının nasıl yazılacağı sırasıyla anlatılıyor.
Web sitesi yedeği neden gerekir ve neyi kapsamalıdır?
Yedek, sitenizi bir arıza ya da saldırı sonrasında belirli bir güne geri döndürmenizi sağlayan kopyadır ve eksiksiz olması için dosyaları, veritabanını ve yapılandırmayı birlikte kapsamalıdır. Yalnızca dosyaları yedeklemek, siparişlerin ve yazıların durduğu veritabanını korumaz; yalnızca veritabanını yedeklemek de tema, eklenti ve yüklenen görselleri kaybettirir.
Kapsamı belirlerken siteyi tek başına değil, çalışması için gereken her şeyle birlikte düşünün: web dosyaları, medya yüklemeleri, veritabanı, e-posta kutuları, .htaccess ve cron gibi yapılandırma dosyaları, SSL ve DNS kayıtlarının bir dökümü. Son maddeyi çoğu kişi unutur; DNS kayıtlarını bir yerde saklamadığınızda felaket sonrası siteyi yeniden bağlamak vakit alır.
3-2-1 yedekleme kuralı nedir?
3-2-1 kuralı, verinin üç kopyasının bulunması, bu kopyaların iki farklı ortamda saklanması ve bir kopyanın site dışında (başka bir konumda) tutulması ilkesidir. Üç kopya canlı verinin kendisi ve iki yedektir. İki farklı ortam, örneğin sunucu diski ve bulut depolama ya da harici disk demektir. Site dışı kopya ise yangın, sunucu hatası veya hesap ele geçirilmesi gibi tek noktadan çıkan felaketlere karşı güvencedir.
Örnek bir düzen: canlı site hosting sunucusunda, hosting firmasının otomatik yedeği aynı veri merkezinde ve haftalık tam yedeğiniz farklı bir bulut hesabında tutulur. Aynı sunucuda duran yedek, sunucu bozulduğunda onunla birlikte kaybolacağı için gerçek anlamda yedek sayılmaz. Hosting firmasının yedeği de tek başına güvenilecek bir kopya olarak düşünülmemelidir.
Yedeklerin tutulduğu bulut hesabının parolası ve iki adımlı doğrulaması en az sunucunuz kadar önemlidir; hesap ele geçirilirse saldırgan hem canlı veriye hem yedeğe ulaşır. Mümkünse yedek hesabına yalnızca yazma yetkisi olan ayrı bir erişim anahtarı tanımlayın.
Yedekler ne sıklıkla alınmalı, ne kadar saklanmalı?
Yedekleme sıklığı, kaybetmeyi göze alabileceğiniz veri miktarına göre belirlenir: bu ölçüye kurtarma noktası hedefi (RPO) denir. Haftada bir yeni yazı yayınlayan bir blog için günlük yedek yeterliyken, saatte onlarca sipariş alan bir mağaza için veritabanı yedeklerinin çok daha sık alınması gerekir. Siteyi ne kadar sürede geri ayağa kaldırmanız gerektiğini belirleyen süreye ise kurtarma süresi hedefi (RTO) denir.
Saklama süresi de bir karardır. Bir örnek düzen olarak son 7-14 günün günlük yedeklerini, son birkaç haftanın haftalık yedeklerini ve birkaç aylık aylık yedeği tutabilirsiniz. Bu düzen, sorunun hemen fark edilmediği durumlarda daha eski ve temiz bir kopyaya dönmenizi sağlar. Sadece son yedeği tutmak, bozulma birkaç gün sonra fark edildiğinde bozuk kopyayla baş başa bırakır.
Yedekleme saatini trafiğin düşük olduğu döneme koyun; yedek işlemi sunucuya yük bindirdiği için yoğun saatte alınan yedek siteyi yavaşlatabilir.
Tam, artımlı ve diferansiyel yedek arasındaki fark nedir?
Üç yöntem arasındaki fark, her seferinde ne kadar verinin kopyalandığıdır. Seçim yaparken yedekleme süresi, depolama alanı ve geri yükleme kolaylığı arasında bir denge kurarsınız.
Çoğu küçük site için haftalık tam yedek ile günlük artımlı ya da diferansiyel yedeğin birleşimi iyi bir denge sağlar.
- Tam yedek: tüm dosya ve veritabanının eksiksiz kopyasıdır. Geri yüklemesi en kolay olan yöntemdir, ancak en çok zamanı ve alanı kullanır.
- Artımlı yedek: yalnızca son yedekten (tam ya da artımlı) bu yana değişenleri alır. Hızlıdır ve az yer kaplar, fakat geri yüklemede tam yedeğe ek olarak zincirdeki tüm artımlı yedekler gerekir.
- Diferansiyel yedek: son tam yedekten bu yana değişenleri alır. Artımlıdan daha çok yer kaplar, ama geri yüklemek için yalnızca son tam yedek ve son diferansiyel yedek yeterlidir.
Veritabanı yedeği nasıl alınır?
Veritabanı yedeği; cPanel'deki yedekleme araçlarıyla, phpMyAdmin'in "Dışa Aktar" özelliğiyle ya da komut satırında mysqldump aracıyla alınır. Küçük siteler için phpMyAdmin yeterlidir; veritabanı büyüdükçe zaman aşımı yaşamamak için komut satırı ya da hosting firmasının otomatik yedek aracı daha güvenilirdir.
Sipariş alan bir mağazada yedek alınırken veri yazılmaya devam ettiği için tutarlılık önemlidir. InnoDB tablolarında mysqldump komutuna --single-transaction seçeneğini eklemek, yedeğin tek bir anlık görüntüden alınmasını sağlar. Dosya yedeği ile veritabanı yedeğinin birbirinden çok farklı zamanlarda alınmaması da gerekir; aksi halde geri yüklediğinizde dosyalar ile veriler birbirini tutmayabilir. Yedek dosyalarını sıkıştırın ve içinde kişisel veri bulunduğu için parola veya şifreleme ile koruyun.
WordPress sitesinde wp-content klasörü ve veritabanı yedeği, sıfırdan bir kurulumun üzerine geri yükleyebileceğiniz asgari kümeyi oluşturur; yine de tüm dosyaların yedeği geri dönüşü hızlandırır.
Felaket kurtarma planı nasıl hazırlanır?
Felaket kurtarma planı, site çöktüğünde kimin ne yapacağını, hangi sırayla geri dönüleceğini ve bilgilere nereden ulaşılacağını önceden yazan kısa bir belgedir. En önemli adım ise yedeği gerçekten geri yükleyip denemektir; hiç denenmemiş bir yedek, ihtiyaç anında çalışıp çalışmayacağı belli olmayan bir varsayımdır. Sürekli çalışan siteyi bozmadan, ayrı bir test ortamında üç ayda bir geri yükleme denemesi yapmak makuldür.
Planı yazdıktan sonra bir kopyasını sunucu dışında erişilebilir bir yerde tutun; sistem çöktüğünde kendi sunucunuzdaki belgeye ulaşamayabilirsiniz.
Planınızda en az şunlar bulunmalıdır.
- Hedef RPO ve RTO değerleri: ne kadar veri kaybı ve ne kadar kesinti kabul edilebilir?
- Sorumlu kişiler ve yedekleri; yalnızca bir kişide bulunan bilgi ve erişim bir risktir.
- Hosting, alan adı, DNS ve yedek hesaplarına ait erişim bilgilerinin güvenli bir parola yöneticisinde saklandığı yer.
- Adım adım geri yükleme talimatı: önce dosyalar, sonra veritabanı, ardından yapılandırma ve test.
- Son geri yükleme testinin tarihi ve sonucu.
Yedeklemede en sık yapılan hatalar nelerdir?
En sık hata yedeği canlı sunucuda tutmak, geri yüklemeyi hiç denememek ve yedeğin alındığını varsayıp kontrol etmemektir. Diğer yaygın hatalar yedeklerin şifrelenmemesi, saklama süresinin belirlenmemesi nedeniyle diskin dolması ve yedekleme işinin sessizce başarısız olduğunun fark edilmemesidir. Yedek dosyaları kişisel veri içerdiği için KVKK'nın genel çerçevesinde bunlar da korunması gereken veri sayılır; yetkisiz kişilerin erişemeyeceği bir yerde ve şifreli saklayın.
Yedeklemeyi tek seferlik bir iş değil, düzenli bir rutin olarak kurun: otomatik yedek, başarısızlıkta e-posta uyarısı, periyodik geri yükleme testi. Hosting, yedekleme ve güvenlik düzenini birlikte kurmak isterseniz Solid Medya'nın hosting ve veri koruma desteğinden de yararlanabilirsiniz.