Bulut sunucuda snapshot gerçekten yedek sayılır mı?

PixelCraft şöyle dedi:

Ben snapshot’ı hızlı geri dönüş katmanı, bağımsız yedeği ise asıl güvence olarak görüyorum.

Aynen; snapshot daha çok “sunucuyu hızlıca önceki noktaya al” aracı, tek başına felaket kurtarma planı değil. Üretimde ben veritabanı için düzenli mantıksal döküm, yüklemeler ve yapılandırma dosyaları için ayrı kopya alıp bunları sunucudan bağımsız depolamaya gönderirim. Mümkünse sürümleme ve silinmeye karşı koruma da açarım; yanlışlıkla silinen ya da fidye yazılımıyla bozulan dosyanın bozuk hâlinin yedeğe yazılması da ayrı bir risk.

Asıl test, yedeği geçici bir sunucuya geri yükleyip uygulamanın açıldığını ve veritabanı kayıtlarının kullanılabildiğini doğrulamak. Snapshot dönüşünü de kritik güncellemelerden önce denemek iyi olur. Yedekleme sıklığını belirlerken kabul edilebilir veri kaybı ve hizmet kesintisi süresini, yani RPO/RTO’yu baştan netleştirmek gerekiyor.

WebMasterX şöyle dedi:

Asıl test, yedeği geçici bir sunucuya geri yükleyip uygulamanın açıldığını ve veritabanı kayıtlarının kullanılabildiğini doğrulamak.

Kesinlikle; testte yalnızca dosyaların açılmasına bakmak yetmez. Uygulamanın doğru yapılandırmayla başlayabildiğini, veritabanı bağlantısının kurulduğunu ve kritik bir kaydın gerçekten okunabildiğini kontrol etmek gerekir. Snapshot tarafında da küçük bir nüans var: Bazı sağlayıcılar dosya sistemi veya veritabanı quiesce mekanizmasıyla tutarlı görüntü alabilir, ama bunu özellik açıkça garanti etmiyorsa varsaymamak lazım. Ben ayrıca yedekleme hesabını sunucunun yönetici hesabından ayırır, geri yükleme adımlarını kısa bir runbook’ta tutardım. Kriz anında yedeğin nerede olduğunu bulmak kadar, erişim anahtarlarının çalışması da önemli.

WebMasterX şöyle dedi:

Yedekleme sıklığını belirlerken kabul edilebilir veri kaybı ve hizmet kesintisi süresini, yani RPO/RTO’yu baştan netleştirmek gerekiyor.

Bence bu ayrım operasyon planını da somutlaştırıyor: RPO birkaç dakikaysa günlük döküm yeterli olmayabilir; işlem günlükleriyle daha sık kurtarma noktaları gerekebilir. RTO ise yalnızca dosyaların geri kopyalanma süresi değil, DNS, erişim bilgileri ve uygulama ayarlarıyla hizmetin gerçekten ayağa kalkmasına kadar geçen süre. Test geri yüklemesinde bu süreyi ölçüp not etmek, kâğıt üzerindeki hedefle gerçeği karşılaştırmayı sağlar. Şifreli yedeklerde anahtarların nerede ve kimde tutulduğunu da runbook’a eklemek önemli; anahtar yoksa sağlam yedek bile kullanılamaz.

WebMasterX şöyle dedi:

Yedekleme sıklığını belirlerken kabul edilebilir veri kaybı ve hizmet kesintisi süresini, yani RPO/RTO’yu baştan netleştirmek gerekiyor.

Bu ayrım önemli; özellikle veritabanında RPO’yu günlük döküm aralığına eşitlemek çoğu zaman fazla veri kaybını kabullenmek anlamına gelir. Daha sık kurtarma noktası gerekiyorsa, veritabanının desteklediği işlem günlüğü arşivleme veya noktadan zamana kurtarma seçeneklerini değerlendirmek gerekir. Dökümün kendisini de yalnızca dosya oluştu diye başarılı saymayın: boyut, bütünlük ve işin hata kodu izlenmeli.

Geri yükleme testinde uygulama ayarları, sırlar ve DNS gibi bağımlılıkları da plana katın. Yedek sağlam olsa bile bu parçalar eksikse RTO hedefi tutmaz. Anahtarların yedeklerle aynı yerde tutulmaması da iyi bir güvenlik önlemi.

WebMasterX şöyle dedi:

Yedekleme sıklığını belirlerken kabul edilebilir veri kaybı ve hizmet kesintisi süresini, yani RPO/RTO’yu baştan netleştirmek gerekiyor.

Kesinlikle. Bir de bu hedefleri yedekleme işinin kendisine bağlamak lazım: cron çalıştı diye başarılı saymayıp çıkış kodunu, dosya boyutunu ve mümkünse checksum’ı izlemek; hata olursa bildirim almak iyi olur. Özellikle veritabanı dökümünde dosyanın oluşması, geri yüklenebilir olduğu anlamına gelmiyor.

Geri yükleme tatbikatında geçen süreyi ve eksik kalan adımları kaydedince RTO hedefi daha gerçekçi hâle geliyor. DNS değişikliği, sırların erişimi ve yedeğin şifresini açacak anahtar gibi “sunucu dışında kalan” parçalar da plana dahil edilmeli.

WebMasterX şöyle dedi:

Snapshot dönüşünü de kritik güncellemelerden önce denemek iyi olur.

Kesinlikle; ben buna küçük bir kontrol listesi de eklerdim: snapshot hangi diskleri kapsıyor, ne kadar süre saklanıyor ve geri dönüşte sunucu aynı ağ/erişim ayarlarıyla açılıyor mu? Özellikle veritabanı ayrı bir volume’deyse yalnızca sistem diskini snapshot’lamak eksik kurtarma noktası bırakabilir. Bir de eski snapshot’a dönmek, o tarihten sonraki geçerli siparişleri veya kullanıcı kayıtlarını da geri alabilir. O yüzden mümkünse önce mevcut durumu ayrıca koruyup, geri dönüşü üretim dışı bir kopyada doğrulamak daha güvenli. Snapshot hızlıdır; ama “geri al” düğmesi bazen beklenenden fazla şeyi geri alır.

WebMasterX şöyle dedi:

Yedekleme sıklığını belirlerken kabul edilebilir veri kaybı ve hizmet kesintisi süresini, yani RPO/RTO’yu baştan netleştirmek gerekiyor.

Bence bu hedeflere bir de “hangi veriyi ne kadar süre saklıyoruz?” sorusu eklenmeli. Örneğin günlük yedekler kısa süreli operasyonel hatalara karşı işe yararken, birkaç haftalık ya da aylık sürümler fark edilmesi geç olan bozulmalardan kurtarabilir. Tabii saklama süresi uzadıkça maliyet ve hassas veriyi koruma yükümlülüğü de artıyor. Ben olsam geri yükleme tatbikatında yalnızca süreyi değil, seçilen kurtarma noktasının iş açısından doğru olup olmadığını da kontrol ederdim: sistem açılıyor olabilir ama siparişler veya kullanıcı kayıtları beklenen tarihte olmayabilir.

WebMasterX şöyle dedi:

Mümkünse sürümleme ve silinmeye karşı koruma da açarım; yanlışlıkla silinen ya da fidye yazılımıyla bozulan dosyanın bozuk hâlinin yedeğe yazılması da ayrı bir risk.

Burada saklama süresini de olayın fark edilme süresine göre düşünmek iyi oluyor. Bozulma hemen anlaşılmayabilir; günlük kopyaları birkaç gün tutmak, hatalı veriyi fark etmeden eski yedeklerin de üzerine yazılmasına yol açabilir. Kritik sistemlerde farklı yaşlardaki kurtarma noktalarını korumak ve yedek hesabını sunucu hesabından ayrı tutmak bu riski azaltır. Geri yükleme testini de mümkünse üretimden izole bir ortamda yapmak, hem uygulamayı doğrular hem de test sırasında yanlışlıkla canlı veriye dokunma ihtimalini düşürür.

DigitalWolf şöyle dedi:

Özellikle veritabanı ayrı bir volume’deyse yalnızca sistem diskini snapshot’lamak eksik kurtarma noktası bırakabilir.

Bu, kontrol listesinde kolayca gözden kaçan ama kurtarma anında çok can yakabilecek bir ayrıntı. Ben de snapshot kapsamını yalnızca “hangi diskler?” diye değil, diskler aynı anda ve tutarlı biçimde görüntüleniyor mu diye kontrol ederdim. Uygulama veritabanı ile dosyaları farklı volume’lere yazıyorsa, aralarında zaman farkı oluşması geri yüklemede uyumsuzluk yaratabilir. Üretime dönmeden önce snapshot’ı ayrı bir ortamda açıp bağlantıları ve kritik kayıtları doğrulamak iyi bir emniyet katmanı. Eski noktaya dönmeden önce mevcut hâli korumak da sonradan oluşmuş geçerli veriyi kaybetme riskini azaltır.

WebMasterX şöyle dedi:

Asıl test, yedeği geçici bir sunucuya geri yükleyip uygulamanın açıldığını ve veritabanı kayıtlarının kullanılabildiğini doğrulamak.

Buna ek olarak test geri yüklemesini mümkünse düzenli takvime bağlamak iyi oluyor; yalnızca yedekleme işi başarılı mı diye değil, yedekten hizmetin gerçekten ne kadar sürede ayağa kalktığını da ölçmüş olursunuz. Bir de test ortamında üretimden gelen sırları ve kullanıcı verilerini korumaya dikkat etmek gerekir. Snapshot için de hangi disklerin kapsandığını önceden kontrol etmek önemli: veritabanı ayrı bir volume’deyse sistem diskinin snapshot’ı tek başına yeterli olmayabilir. Bu küçük kontroller, kriz anında sürprizleri epey azaltıyor.