Barındırma Yedekleri Boşluksuz Nasıl Güvence Altına Alınır
31 Temmuz 2026 tarihinde yayımlandı
Bir yedek, ancak hâlâ mevcutsa, hâlâ okunabiliyorsa ve ilk soruna neden olan kişi ya da süreç için hâlâ erişilemez durumdaysa faydalıdır. Barındırma yedeklerinin nasıl güvence altına alınacağı sorusunun pratik yanıtı şudur: onları üretimden ayırın, şifreleyin, erişimi kısıtlayın ve bir olay size teoriye zaman bırakmadan önce geri yüklenebildiklerini kanıtlayın.
Aynı VPS üzerinde depolanan gecelik bir veritabanı dışa aktarımı hiç yoktan iyidir, ancak fidye yazılımı, ele geçirilmiş bir root hesabı, depolama arızası veya yanlışlıkla sunucunun silinmesi için bir kurtarma planı değildir. Üretim ve yedek aynı kimlik bilgilerini, ana makineyi ve zayıf noktaları paylaşıyorsa birlikte ortadan kaybolabilirler. Çok verimli, ama iyi anlamda değil.
Yedek Onay Kutusuyla Değil, Kurtarma Tasarımıyla Başlayın
Önce, nelerin kurtarılabilir olması gerektiğini belirleyin. Küçük bir işletme web sitesi için buna site dosyaları, bir veritabanı, e-posta yapılandırması, DNS kayıtları ve SSL ile ilgili ayarlar dahil olabilir. Bir e-ticaret mağazası veya SaaS uygulaması için nesne depolamayı, ödemeyle ilgili yapılandırmayı, sıraya alınmış işleri, uygulama sırlarını, altyapı tanımlarını ve hızlıca yeniden oluşturulamayan tüm harici hizmet verilerini dahil edin.
Ardından iki operasyonel hedef tanımlayın. Kurtarma noktası hedefiniz ya da RPO, ne kadar yakın tarihli veriyi kaybetmeyi göze alabileceğinizdir. Bir mağaza en fazla bir saatlik sipariş kaybedebiliyorsa, günde bir kez alınan veritabanı yedeği yeterli değildir. Kurtarma süresi hedefiniz ya da RTO, kurtarma gerçekleşirken hizmetin ne kadar süre kullanılamaz kalabileceğidir. Bu sayılar yedekleme sıklığını, saklamayı, depolama seçimini ve hazır bekleyen altyapıya ihtiyacınız olup olmadığını belirler.
Bilinen 3-2-1 kuralı makul bir temel olmaya devam ediyor: verinin üç kopyasını, iki farklı depolama türünde tutun ve bir kopyayı tesis dışı depolayın. Daha yüksek riskli iş yükleri için 3-2-1-1-0 yaklaşımını kullanın. Ek olan bir, değiştirilemez veya çevrimdışı bir kopyadır; sıfır ise düzenli testlerden sonra doğrulanmamış yedek hatasının sıfır olması anlamına gelir.
Bu, her şirketin büyük bir kurumsal yedek platformuna ihtiyaç duyduğu anlamına gelmez. Yönetilen bir WordPress sitesi ile çok düğümlü bir SaaS platformunun ihtiyaçları farklıdır. Ancak bu, her iş yükünün kesinti maliyetine uyan bir kurtarma tasarımına ihtiyaç duyduğu anlamına gelir.
Barındırma Yedekleri Ayrıştırmayla Nasıl Güvence Altına Alınır
En yaygın yedek zayıflığı, kopyaları üretime fazla yakın yerleştirmektir. Aynı sunucu içinde bağlanmış bir yedek dizini kullanışlıdır, ancak kullanışlılık izolasyon değildir. Bir disk arızası, yıkıcı komut veya ele geçirilmiş yönetici hesabı her iki konumu da etkileyebilir.
En az bir yedek kopyayı ayrı bir hesapta, depolama sisteminde veya sağlayıcı ortamında tutun. İdeal olarak, yedek hedefi üretim sunucusundan farklı kimlik bilgileri kullanır. Belirli ve kontrollü bir neden olmadıkça web uygulamasının, dağıtım kullanıcısının veya rutin sunucu sürecinin geçmiş yedekleri silmesine izin vermeyin.
VPS ve adanmış sunucu ortamları için katmanları da ayırın. Sağlayıcı düzeyinde bir anlık görüntü, işletim sistemi arızasından sonra tüm bir makinenin kurtarılmasına yardımcı olabilir. Uygulama farkındalıklı yedekler, veritabanlarını ve dosyaları tutarlı bir durumda korur. Çoğu zaman ikisine de ihtiyacınız olur. Ham bir disk anlık görüntüsü, veri yazarken bir veritabanını yakalayabilir; bu da geri yüklemeyi karmaşıklaştırabilir. Veritabanı dökümleri, işlem günlüğü yedekleri veya veritabanının yerel anlık görüntüleri daha temiz bir kurtarma noktası sağlar.
Tesis dışı kopyalar üretim sunucusunda yazılabilir bir sürücü olarak kalıcı biçimde bağlanmamalıdır. Fidye yazılımı bir sunucuya ulaşır ve yedek hedefini normal depolama gibi tarayabilirse, biri fark etmeden önce yedekleri şifreleyebilir. Bunun yerine dar kapsamlı kimlik bilgileriyle zamanlanmış bir aktarım kullanın. Sunucunun yeni bir yedek nesnesi yazmasına izin verilmeli, tüm arşivi inceleyip kaldırmasına değil.
Verileri Şifreleyin ve Anahtarları Ayrı Şekilde Koruyun
Şifreleme, aktarım halindeki ve bekleyen verileri kapsamalıdır. Sunucu ile yedek depolama arasındaki aktarımlar SFTP, SSH tabanlı araçlar veya şifreli API bağlantısı gibi güvenli taşıma yöntemlerini kullanmalıdır. Yedek arşivleri de özellikle müşteri kayıtları, parolalar, özel belgeler veya veritabanı içeriği içeriyorsa depolanmadan önce ya da depolanırken şifrelenmelidir.
Şifreleme anahtarı, en az yedeğin kendisi kadar dikkat hak eder. Bir anahtarın tek kopyası kurtarılan sunucuda saklanıyorsa, şifreli arşiv tutacağı olmayan son derece güvenli bir kutuya dönüşür. Kurtarma anahtarlarını korumalı bir parola yöneticisinde, özel bir anahtar yönetim hizmetinde veya üretimden ayrı başka kontrollü bir konumda saklayın.
Yedek depolama için güçlü ve benzersiz kimlik bilgileri kullanın ve yönetim hesabı için çok faktörlü kimlik doğrulamayı etkinleştirin. Desteklenen yerlerde, özellikle yedek işleri için bir hizmet hesabı oluşturun. Bu hesabın yalnızca yedekleri yazmak ve doğrulamak için gereken izinleri olmalıdır. Geniş hesap yönetimi haklarına sahip olmamalıdır.
Ekipler için paylaşılan root parolalarından ve paylaşılan depolama oturum açmalarından kaçının. Her yöneticiye isimli bir hesap verin, ardından sorumluluklar değiştiğinde erişimi hemen kaldırın. Günlükler şimdi de aynı hikâyeyi anlatıyor: açık sahiplik, güvenlik incelemelerini ve olay müdahalesini çok daha az sancılı hâle getirir.
Yedeklerin Değiştirilmesini veya Silinmesini Zorlaştırın
Şifreleme gizliliği korur. Değiştirilemezlik geçmişi korur.
Değiştirilemez bir yedek, saklama süresi dolana kadar değiştirilemez veya silinemez. Bu, özellikle fidye yazılımına ve ayrıcalıklı kimlik bilgilerini ele geçirmiş bir saldırgana karşı çok değerlidir. Birçok depolama platformu object lock, write-once retention veya sürümleme denetimleri sunar. Bunları dikkatle yapılandırın; çünkü aşırı uzun bir saklama politikası gereksiz maliyet oluşturabilir ve veri silme yükümlülüklerini yönetmeyi zorlaştırabilir.
Saklamayı iş gerçekliğine göre ayarlayın. Birçok site için makul bir desen; hızlı kurtarma için sık kısa vadeli yedekler, birkaç hafta boyunca günlük kopyalar, daha uzun geçmiş ihtiyaçları için aylık kopyalar ve kritik iş yükleri için ayrı bir değiştirilemez kopyadır. Kesin zamanlama, veri değişim hızına, yasal gerekliliklere ve mevcut depolama bütçesine bağlıdır.
Varsayılan olarak her yedeği sonsuza kadar saklamayın. Saklama, güvenliğin bir parçasıdır. Eski yedekler, artık var olmaması gereken eski müşteri verilerini, güvenlik açığı bulunan uygulama dosyalarını veya kimlik bilgilerini içerebilir. Saklama sürelerini tanımlayın, mümkün olan yerde süre sonunu otomatikleştirin ve tüm uyumluluk istisnalarını belgelendirin.
Sürümleme faydalıdır ama değiştirilemezlikle aynı şey değildir. Sürümleme, yanlışlıkla üzerine yazma sonrası önceki nesneleri koruyabilir. Yeterli izinlere sahip bir saldırgan yine de bu sürümleri kaldırabilir. "Sürümlemeli" sözcüğünün bunu çözdüğünü varsaymak yerine silme koruması davranışını kontrol edin.
Yalnızca Yedek İşlerini Değil, Geri Yüklemeleri de Doğrulayın
Yeşil bir yedek durumu yalnızca bir işin tamamlandığını doğrular. Arşivin doğru dosyaları içerdiğini, veritabanının tutarlı olduğunu, anahtarın çalıştığını veya geri yüklemeden sonra uygulamanın başlayacağını doğrulamaz.
Geri yükleme testleri planlayın. Tanıtım amaçlı bir site için izole bir test ortamına aylık geri yükleme yeterli olabilir. Aktif mağazalar, müşteri sitelerini yöneten ajanslar ve SaaS işletmecileri için daha sık test yapın ve gerçekçi bir kurtarma sırasını dahil edin: verileri geri yükleyin, yapılandırmayı uygulayın, gerekiyorsa açığa çıkmış kimlik bilgilerini döndürün, hizmetleri çevrimiçi hâle getirin ve temel işlemleri doğrulayın.
Yararlı bir test, yalnızca bir ZIP dosyasını çıkarmak değildir. Bir veritabanını geri yükleyin ve uygulama denetimi çalıştırın. Kullanıcıların oturum açabildiğini, yakın tarihli bir siparişin veya kaydın mevcut olduğunu, zamanlanmış görevlerin çalıştığını ve yüklenen dosyaların beklentilerle eşleştiğini doğrulayın. Sürecin ne kadar s ürdüğünü kaydedin. Bu sayı, bir politika belgesine yazılmış umut dolu sayı değil, gerçek RTO’nuzdur.
Otomatik bütünlük denetimleri de yardımcı olur. Yedek arşivleri için sağlama değerleri oluşturun ve aktarım sonrasında bunları doğrulayın. Başarısız işleri, alışılmadık derecede küçük yedekleri, depolama kapasitesini ve kaçırılan zamanlamaları izleyin. Bir yedeğin bir anda 30 GB’dan 200 MB’a düşmesi teknik olarak başarılı olabilir ama operasyonel olarak işe yaramaz olabilir.
Yedeği Çalıştıran Sistemleri Güvence Altına Alın
Yedek yazılımı, kontrol panelleri ve işletim sistemleri güçlü erişim sağladıkları için yamalanmalıdır. Yedek aracısını ve bağımlılıklarını güncel tutun, ancak iş yükü hassassa büyük yükseltmeleri aşamalı uygulayın. Yoğun bir satış döneminde başarısız bir yedek aracı yükseltmesi dramatik bir sinema değildir, ama yine de kötü bir salıdır.
Sunucuyu en az ayrıcalıklı hesaplar, mümkün olduğunda parola oturumu yerine SSH anahtarları, güvenlik duvarı kuralları ve izlenen yönetim erişimiyle koruyun. Mümkün olduğunda yedek yönetimini güvenilir ağlarla veya VPN erişimiyle sınırlayın. Başarısız oturum açma girişimleri, saklama değişiklikleri, devre dışı bırakılan işler ve beklenmeyen silmeler için denetim günlüklerini inceleyin.
Yapılandırmanın da yedeğe ihtiyacı vardır. Yedek zamanlamalarını, betikleri, saklama ayarlarını ve kurtarma runbook’larını kontrollü bir konumda saklayın. Sistemi kuran mühendis erişilebilir değilse, başka yetkili bir kişi kopyaların nerede olduğunu, onlara kimin erişebileceğini ve nasıl geri yükleneceklerini tahmin yürütmeden anlayabilmelidir.
Yönetilen altyapı kullanan müşteriler için doğrudan şu soruyu sorun: tam olarak ne yedekleniyor, ne sıklıkla, nerede saklanıyor ve geri yüklemeyi kim gerçekleştiriyor? Yönetilen bir yedek hizmeti operasyonel işi azaltabilir, ancak sorumluluk yine de açık olmalıdır. kodu.cloud'da pratik hedef basittir: kurtarma yolunun, ona ihtiyaç duyulmadan önce biliniyor olmasını sağlamak; hizmet zaten kesintideyken bir araya getirilmesini değil.
Küçük Bir Kurtarma Runbook’u Tutun
Runbook’unuz kısa olabilir, ancak belirli olmalıdır. Yedek kopyaların konumunu, mevcut saklama zamanlamasını, kurtarma anahtarının konumunu, geri yükleme sırasını, kilit kişileri ve doğrulama adımlarını ekleyin. Hassas sırları belgenin kendisinin dışında tutun ve bunun yerine onaylı güvenli konuma başvurun.
Altyapı değişikliklerinden sonra runbook’u gözden geçirin. Yeni bir VPS’e, veritabanı sürümüne, depolama sağlayıcısına veya dağıtım sürecine geçiş, eski bir kurtarma prosedürünü sessizce geçersiz kılabilir. Bu en güzel belgelendirme işi değildir, ancak genellikle kontrollü bir geri yükleme ile eski mesajlar arasında uzun bir akşam boyunca arama yapma arasındaki farktır.
Güvenli barındırma yedekleri, kimsenin yönetemeyeceğinden daha fazla kopya toplamakla ilgili değildir. Baskı altında işe yarayan bağımsız, şifreli, izlenen ve test edilmiş kurtarma noktaları tutmakla ilgilidir. Bu disiplini şimdi oluşturun; böylece yığının bir parçası sakin olmadığında bile sunucularınız yeniden sakin kalabilir.
Andres Saar Müşteri Hizmetleri Mühendisi