Bir yedekleme işi “başarılı” tamamlandığında verinin geri dönebileceği kanıtlanmış olmaz. Dosya eksik olabilir, obje bozulmuş olabilir, şifreleme anahtarı erişilemez durumda kalabilir veya uygulama geri yüklenen veriyi açamayabilir. S3 uyumlu Object Storage kullanan ekipler için düzenli geri yükleme örneklemesi; tüm arşivi her seferinde indirmeden yedeğin okunabilirliğini, bütünlüğünü ve operasyon prosedürünü sınamanın pratik yoludur.
Başarılı upload ile geri yüklenebilir yedek aynı şey değildir
Yedekleme aracı HTTP isteğini başarıyla tamamlayabilir; fakat yanlış klasör seçilmiş, son tam yedek alınmamış veya retention süreci gerekli zinciri kaldırmış olabilir. Multipart yüklemenin tamamlanması da dosya içeriğinin uygulama açısından geçerli olduğunu tek başına göstermez. En güvenilir kontrol, seçilen bir yedek setini bağımsız ortama geri yükleyip içeriği doğrulamaktır.
Restore örneklemesi tam felaket kurtarma tatbikatının yerine geçmez. İki kontrol birbirini tamamlar: sık ve küçük örneklemeler günlük hataları erken yakalar; daha seyrek uçtan uca tatbikat ise sistemlerin, erişimlerin, süre hedeflerinin ve ekip koordinasyonunun tamamını sınar.
Önce yedek envanteri oluşturun
Örnekleme yapılabilmesi için hangi yedeğin neyi koruduğu bilinmelidir. Envanterde en az şu alanlar bulunmalıdır:
- Kaynak sistem, uygulama veya müşteri kimliği
- Yedek türü: tam, artımlı, dosya, veritabanı dump veya WAL/log zinciri
- Object key/prefix ve oluşturma zamanı
- Beklenen boyut ve obje sayısı
- Yedekleme aracı ve sürümü
- Sıkıştırma ve şifreleme yöntemi
- Anahtarın/kurtarma parolasının sorumlusu
- Checksum veya bütünlük manifesti
- Saklama sınıfı ve beklenen silinme tarihi
- Son başarılı restore testinin tarihi ve sonucu
Envanter yedekle aynı bucket veya aynı erişim anahtarına bağımlı tek bir dosyada tutulmamalıdır. Bir erişim olayı sırasında hem objeler hem envanter kaybolursa doğru seti bulmak zorlaşır. Envanterin erişimi sınırlandırılmış ayrı bir kopyası bulunmalıdır.
Checksum neyi kanıtlar, neyi kanıtlamaz?
Checksum, indirdiğiniz içeriğin beklenen byte dizisiyle aynı olup olmadığını kontrol eder. Yedek oluşturulurken güçlü bir hash değeri hesaplanır, manifestte saklanır ve restore sırasında yeniden hesaplanır. Eşleşme; aktarım veya depolama sürecinde içeriğin değişmediğine dair güçlü kanıt sağlar.
ETag her zaman dosyanın içerik checksum’u olarak yorumlanmamalıdır. Özellikle multipart upload senaryolarında ETag hesaplama yöntemi istemcinin beklediği tek parça hash ile aynı olmayabilir. Bu yüzden bütünlük politikasını yalnız ETag’e bağlamak yerine yedekleme aracının manifesti veya bağımsız checksum kaydı kullanılmalıdır.
Checksum eşleşmesi dosyanın mantıksal olarak kullanılabilir olduğunu kanıtlamaz. Bozuk bir veritabanı dump’ı doğru şekilde yüklenmiş ve aynı hash ile geri indirilmiş olabilir. Bu nedenle teknik bütünlük kontrolünden sonra uygulama seviyesinde açma, listeleme, sorgulama veya doğrulama yapılmalıdır.
Risk bazlı örnekleme planı kurun
Tüm objeleri her gün geri yüklemek maliyetli ve yavaş olabilir. Bunun yerine örneklemeyi risk bazlı tasarlayın. Her periyotta rastgele set seçmenin yanında kritik veri türleri zorunlu örneğe dâhil edilmelidir. Yeni eklenen yedek işi, araç sürümü değişen sistem, son dönemde hata veren kaynak ve uzun süredir test edilmemiş set daha yüksek öncelik almalıdır.
Örneklemeyi yalnız en yeni yedekle sınırlamayın. Günlük, haftalık ve daha eski saklama noktalarından örnek seçmek; yanlış retention, eski şifreleme anahtarı veya format uyumluluğu sorunlarını ortaya çıkarır. Örnekleme oranı veri hacmi, kritikliği, değişim sıklığı ve düzenleyici ihtiyaca göre belirlenmelidir; tek bir yüzde her iş yüküne uymaz.
İzole restore ortamı neden gerekir?
Yedeği doğrudan production üzerine geri yüklemek risklidir. Test için ayrı bir dizin, geçici VDS, izole veritabanı veya erişimi sınırlandırılmış çalışma alanı kullanılmalıdır. Restore kimlik bilgileri production uygulamasının sürekli kullandığı anahtarlarla aynı olmamalı; yalnız gerekli bucket/prefix erişimi ve test süresi kadar yetki verilmelidir.
Kişisel veya hassas veri içeren setlerde test ortamının güvenliği production kadar ciddiye alınmalıdır. Geçici kopyaların kim tarafından açıldığı, ne zaman silindiği ve çıktıların nerede tutulduğu kayda geçmelidir. Test tamamlandıktan sonra geçici veri güvenli biçimde kaldırılmalıdır.
Adım adım geri yükleme örneklemesi
- Envanterden risk kriterlerine göre yedek seti seçin.
- Setin obje sayısı, beklenen boyutu, tarih aralığı ve bağımlı zincirlerini kaydedin.
- İzole hedef ortamı ve süreli erişim bilgilerini hazırlayın.
- Objeleri indirirken hata, süre ve aktarılan byte miktarını ölçün.
- Manifestteki checksum değerlerini yeniden hesaplayıp karşılaştırın.
- Arşivi açın; dosya listesi, izinler ve kritik içerikleri kontrol edin.
- Veritabanı yedeğiyse boş bir instance’a restore edin; tablo sayısı, temel sorgular ve uygulama uyumluluğunu sınayın.
- Başlangıç/bitiş zamanını ölçerek gerçek restore süresini hedef RTO ile karşılaştırın.
- Sonuç, hata, kanıt bağlantısı ve takip aksiyonunu envantere yazın.
- Geçici veriyi ve test erişimlerini kaldırın.
RPO ve RTO’yu kanıtla karşılaştırın
RPO, kabul edilebilir veri kaybı aralığını; RTO, hizmetin geri dönmesi için hedef süreyi ifade eder. Yedek sıklığı teorik olarak RPO’yu karşılayabilir ancak son geçerli set beklenenden eskiyse gerçek RPO aşılmıştır. Benzer şekilde bir dosyanın indirilmesi on dakika sürse bile veritabanı açma, bütünlük kontrolü, DNS veya uygulama doğrulaması toplam RTO’yu uzatabilir.
Restore testinde yalnız indirme süresini değil; erişim onayı, anahtar temini, aktarım, açma, yeniden oluşturma ve kabul testini ayrı süreler hâlinde kaydedin. Darboğazın ağ mı, şifre çözme mi, dokümantasyon mu yoksa insan onayı mı olduğu böyle anlaşılır.
Kanıt kaydı nasıl olmalı?
“Test edildi” notu denetlenebilir değildir. Kayıtta yedek kimliği, seçilme nedeni, test tarihi, sorumlu kişi/rol, kullanılan prosedür sürümü, checksum sonucu, restore süresi, uygulama doğrulaması ve bulunan sapmalar yer almalıdır. Hassas içerik veya erişim anahtarı rapora eklenmemelidir.
Başarısız test bir raporlama kusuru değil, üretim felaketinden önce yakalanmış değerli bir bulgudur. Hata için sahip, hedef tarih ve tekrar test planı atanmalıdır. Aynı nedenle arka arkaya başarısız olan setler daha geniş kapsamlı incelemeye alınmalıdır.
S3 restore kontrol listesi
- Yedek envanteri ve bağımlı zincirler güncel mi?
- Checksum manifesti yedekten ayrı ve erişilebilir mi?
- Eski tarihlerden de örnek seçiliyor mu?
- Restore ortamı production’dan izole mi?
- Şifreleme anahtarının kurtarma prosedürü test edildi mi?
- Veritabanı veya uygulama seviyesinde mantıksal doğrulama yapıldı mı?
- Gerçek süre RPO/RTO hedefleriyle karşılaştırıldı mı?
- Test kopyaları ve geçici erişimler kapatıldı mı?
- Bulgu için sorumlu ve tekrar test tarihi belirlendi mi?
Object Storage yedeklerinizi test edilebilir tasarlayın
S3 uyumlu Object Storage, yedeklerin sunucudan ayrılması için güçlü bir katman sunar; fakat geri yüklenebilirlik süreç ve test gerektirir. Narweb S3 uyumlu Object Storage seçeneklerini inceleyebilir, beklenen veri hacmi ve trafik ihtiyacınıza uygun altyapıyı değerlendirebilirsiniz. Yedek mimarisi ve restore hedeflerinizi konuşmak için Narweb ile iletişime geçin.