Platformunuz İçin Yedekleme: İki Seçenek Karşılaştırması

Birçok işletme sahibi, barındırma sağlayıcısının bir yerde "günlük yedekleme" kutucuğunu işaretlemiş olması nedeniyle web sitesinin veya web platformunun iyi korunduğunu varsayar. Ancak bir güncelleme başarısız olduğunda, bir veritabanı bozulduğunda veya bir sunucu fiziksel olarak devre dışı kaldığında o kutucuğun pratikte neye değdiği ortaya çıkar. Kağıt üzerindeki bir yedekleme bir garanti değildir. Bir yedekleme, ancak geri yükleme sürecini en az bir kez başarıyla gerçekleştirdiğinizde işlevsel hale gelir.

Altyapı ve güvenilirlik, müşterilerinizin güvenini büyük ölçüde belirler. Örneğin Search Engine Journal'ın yakın tarihli bir araştırması, .org gibi alternatif alan adı uzantılarının bazen geleneksel .com alan adlarına kıyasla yüzde 34'e varan oranda daha fazla e-ticaret cirosu oluşturduğunu gösterdi. Bunun arkasındaki açıklama mantıklıdır: ziyaretçiler bilinçsizce kanıtlanabilir güvenilirlik ve otoriteyi tercih eder. Aynı mantık platformunuzun teknik arka planı için de geçerlidir. Sisteminize ulaşılamıyorsa veya müşteri verilerini kaybediyorsa, bu birikmiş güven anında yok olur.

Bu yazıda, KOBİ web siteleri ve web uygulamaları için iki somut yedekleme yaklaşımını karşılaştırıyoruz: yerleşik barındırma yedeklemesi ile izole dış ortam yedekleme yapısı. Sonunda, hangi seçeneğin işletmenizin risk profiline uyduğunu belirlemenize yardımcı olacak net bir karar kılavuzu bulacaksınız.

Bir yedekleme stratejisi neden günlük bir kopyadan daha fazlasıdır

Bir yedekleme ortamı kurarken mesele yalnızca dosyalarınızın bir kopyasının var olup olmadığı değildir. Mesele, BT dünyasından iki kritik faktördür: kurtarma süresi (Recovery Time Objective veya RTO) ve izin verilen veri kaybı (Recovery Point Objective veya RPO).

Kurtarma süresi, ciddi bir sorun çıktıktan sonra platformunuzun ne kadar süre çevrimdışı kalabileceğini belirler. Bu on dakika mı, iki saat mi yoksa üç iş günü mü? İzin verilen veri kaybı, ne kadar veri kaybetmenize izin verildiğini belirler. Gece yarısı bir yedekleme yapar ve sistem gece saat on birde çökerse, yeni müşteri siparişlerinin, tekliflerin veya hesap oluşturmaların 23 saatlik kısmını kaybedersiniz. Basit bir tanıtım web sitesi için bu kabul edilebilir olsa da, sürekli işlem yapılan özel bir web uygulaması veya e-ticaret sitesi için bu kabul edilemez.

Ayrıca, sorunlar nadiren yalnızca tam bir sunucu çökmesinden kaynaklanır. Çok daha sık olarak insan hatası, yanlış bir veritabanı geçişi, hasarlı medya dosyaları veya haftalardır sisteminizde fark edilmeden duran kötü amaçlı bir kod enjeksiyonu söz konusudur. Yedekleme stratejiniz yalnızca dünü bugünle üzerine yazmaktan ibaretse, bir noktada bozuk veriyi veya kötü amaçlı yazılımı da yedeklersiniz.

Seçenek 1: Yerleşik barındırma veya eklenti yedeklemesi

İlk seçenek, KOBİ'lerde en sık rastlanan yaklaşımdır. Bu, bir barındırma paketiyle standart olarak gelen veya bir CMS'de otomatik bir eklenti aracılığıyla çalışan yedekleme hizmetidir. Örneğin barındırma sağlayıcısı her gece sunucunun bir anlık görüntüsünü alır veya sunucudaki bir betik veritabanını ve dosyaları paketleyip aynı disk üzerindeki belirli bir klasörde saklar.

Bu seçenek nasıl çalışır

Pratikte bu yöntem tamamen arka planda çalışır. Bir kontrol paneli aracılığıyla sistemin her gece saat 02:00'de bir yedekleme yapmasını ayarlarsınız. Bu dosyalar genellikle sağlayıcının sunucusunda yedi ila otuz gün arasında saklanır. Tek bir tıklamayla barındırma panelinde önceki bir duruma geri dönebilirsiniz.

Avantajları

• Düşük giriş eşiği: Kurulumu neredeyse hiç zaman almaz ve altyapı konusunda derinlemesine teknik bilgi gerektirmez.
• Ek altyapı maliyeti yok: Depolama genellikle barındırma paketinizin aylık fiyatına dahildir.
• Küçük hatalarda hızlı kurtarma: Yanlışlıkla bir dosyayı silerseniz veya yanlış bir ayarı değiştirirseniz, bunu barındırma arayüzü üzerinden hızlıca geri alabilirsiniz.

Dezavantajları

• Tek arıza noktası: Fiziksel sunucu devre dışı kalırsa, veri merkezi büyük bir kesinti yaşarsa veya barındırma hesabınız engellenirse, yedeklerinize de artık erişemezsiniz.
• Büyük veritabanlarında kapasite sorunları: Canlı sunucuda çalışan eklentiler veya genel betikler bellek ve işlemci gücü tüketir. Daha büyük veritabanlarında veya çok fazla medyada bu süreçler genellikle bir zaman aşımı nedeniyle takılır.
• Belirli bir ana geri dönüş (Point-in-Time Recovery) yok: Yalnızca anlık görüntünün tam zamanına geri dönebilirsiniz. İki anlık görüntü arasında gerçekleşen her şey kalıcı olarak kaybolur.
• Otomatik doğrulama yok: Oluşturulan yedekleme dosyasının eksiksiz ve kullanılabilir olup olmadığına dair bir kontrol yoktur.

Seçenek 2: Belirli bir ana geri dönüşlü, izole dış ortam yedeklemeleri

İkinci seçenek, kurtarma mekanizmasını canlı ortamdan tamamen ayırır. Bu yöntemde veriler sürekli olarak veya sabit aralıklarla bağımsız, güvenli bir bulut altyapısına aktarılır. Bu, React, TypeScript ve Supabase gibi modern teknoloji yığınlarıyla inşa edilen özel platformlarda standarttır.

Bu seçenek nasıl çalışır

Bu yaklaşımda veritabanı basitçe günde bir kez kopyalanmaz. Write-Ahead Logging (WAL) veya otomatik veritabanı dökümleri gibi teknikler sayesinde değişiklikler sürekli olarak kaydedilir. Yedekleme dosyaları ve medya dosyaları, Supabase Storage veya farklı bir veri merkezindeki özel bir AWS S3 bucket'ı gibi fiziksel olarak ayrı bir nesne depolama konumuna doğrudan şifrelenerek gönderilir.

Kurtarma süreci barındırma sağlayıcınızdan bağımsızdır. Sunucu sağlayıcısının tamamı batarsa, uygulama bağımsız kod deposu ve harici veri depolama sayesinde kısa sürede yeni bir sunucuda yeniden kurulabilir.

Avantajları

• Maksimum izolasyon: Uygulama sunucusundaki bir sorunun yedekleme verilerinin güvenliği üzerinde hiçbir etkisi yoktur.
• Belirli bir ana geri dönüş (PITR): Veritabanını, hata veya çökme meydana gelmeden hemen önceki belirli bir dakikaya geri yükleyebilirsiniz. Bu, veri kaybını en aza indirir.
• Canlı sunucuya yük bindirmez: Depolama ve işleme harici olarak gerçekleşir, bu da canlı web sitesinin veya uygulamanın hızını garanti eder.
• Tedarikçi bağımsızlığı: Tek bir barındırma sağlayıcısına bağlı kalmazsınız. Kendi verileriniz üzerinde her zaman tam kontrolü korursunuz.

Dezavantajları

• Daha yüksek kurulum maliyeti: Bu, deneyimli bir geliştirici tarafından özel çalışma ve doğru yapılandırılmış bir altyapı gerektirir.
• Ayrı bulut maliyetleri: Harici depolama alanı ve veri aktarımıyla ilgili küçük, periyodik maliyetler vardır.
• Bakım gerektirir: Depolama ve kurtarma betikleri periyodik olarak kontrol edilmeli ve test edilmelidir.

İyi düşünülmüş bir plan olmadan somut olarak neler yanlış gider

Pratikte, yedeklemelerinin iyi düzenlendiğini düşünen işletmelerde işlerin nerede ters gittiğini düzenli olarak görüyoruz. Aşağıdaki üç senaryo, hatalı bir stratejinin bir olay anında nasıl sonuçlandığını gösteriyor.

Senaryo A: Hasarlı yedek

Bir şirket CMS'de büyük bir güncelleme gerçekleştirir. Güncelleme başarısız olur ve web sitesi yalnızca hata mesajları gösterir. Geliştirici, barındırma panelinde "Dünün yedeğini geri yükle" seçeneğine tıklar. Geri yükleme süreci başarılı mesajı verir, ancak yedekleme betiği bellek sınırı nedeniyle yarıda kesildiği için veritabanının eksik olduğu ortaya çıkar. Dosya hiçbir zaman otomatik olarak kontrol edilmediği için, web sitesinin en son çalışan durumu kalıcı olarak kaybolmuştur.

Senaryo B: Sunucu fiziksel olarak devre dışı kalır

Veri merkezindeki bir donanım arızası nedeniyle sunucunun diski okunamaz hale gelir. İşletme sahibi barındırma sağlayıcısıyla iletişime geçer ve son anlık görüntünün geri yüklenmesini ister. Barındırma sağlayıcısı, anlık görüntülerin canlı web sitesiyle aynı fiziksel sunucu alanında saklandığını bildirir. Hem canlı ortam hem de yedekler onarılamaz şekilde hasar görmüştür.

Senaryo C: Sessiz veri bozulması

Kötü niyetli bir betik veritabanına erişim sağlar ve arka planda fark edilmeden müşteri verilerini ve fiyatları değiştirir. Şirket sorunu ancak üç hafta sonra fark eder. Barındırma sağlayıcısı yalnızca yedi günlük yedekleri sakladığından, mevcut tüm yedekler zaten bozulmuş veriyi içerir. Uzun vadeli bir arşiv veya gelişmiş günlükleme olmadan geri alınabilecek temiz bir sürüm kalmamıştır.

Karar kılavuzu: Hangi yaklaşım kurumunuza uyar?

KOBİ'niz için hangi yedekleme yapısının gerekli olduğunu belirlemek için aşağıdaki genel bakışı kullanabilirsiniz. Seçim, platform türüne ve olası kesinti süresinin iş operasyonlarınız üzerindeki etkisine bağlıdır.

Seçenek 1'i şu durumda tercih edin:

Web siteniz yalnızca dijital bir kartvizit görevi görüyorsa. İşlem yapılmıyorsa, ziyaretçiler hesap oluşturmuyorsa ve içerik yılda yalnızca birkaç kez değişiyorsa. Web sitesi bir gün çevrimdışı kalırsa, bu doğrudan ciro kaybına veya hukuki sorunlara yol açmaz. Bu durumda yine de ara sıra dosyaların ve veritabanının manuel bir kopyasını indirip kendi güvenli konumunuzda saklamaya özen gösterin.

Seçenek 2'yi şu durumda tercih edin:

Platformunuz iş operasyonlarınızın temel bir parçasıysa. Bu; e-ticaret siteleri, özel panolar, müşteri portalları veya her gün yeni veri, sipariş veya potansiyel müşterinin geldiği uygulamalar için geçerlidir. Bir günlük veri kaybı, doğrudan mali veya itibar kaybı anlamına gelir. İzole bir dış ortam yedekleme yapısı ve belirli bir ana geri dönüş özelliğiyle, sunucuda veya sağlayıcıda ne olursa olsun işletmenizin sürekliliğini güvence altına alırsınız.

Sağlam bir web platformu inşa etmek, güzel bir tasarım veya hızlı kodla sona ermez. Verilerle, güvenlikle ve kurtarma prosedürleriyle nasıl başa çıktığınız, platformunuzun uzun vadeye hazır olup olmadığını belirler.

Mevcut yedekleme yapınızın ve altyapınızın acil durumlarda yeterli koruma sağlayıp sağlamadığını kontrol etmek ister misiniz? ferhat.io/contact üzerinden ücretsiz, otuz dakikalık, yükümlülük getirmeyen bir görüşme için bizimle iletişime geçmekten çekinmeyin.