Yedek almak ile geri dönebilmek arasındaki fark

Önce hangi kaybı karşılayacağınızı tanımlayın

Disk arızası, yanlışlıkla silme, erişim hesabının ele geçirilmesi ve binanın kullanılamaması aynı olay değildir. İkinci bir sunucu ilk sorunu azaltabilir; iki cihaz aynı odadaysa son sorunu çözmez. Bu yüzden tasarıma cihaz sayısıyla değil, kayıp senaryolarıyla başlıyoruz.

RPO, kabul edilebilir veri kaybı aralığını; RTO, hizmetin geri dönüşü için hedeflenen süreyi ifade eder. Bunlar teknik ekibin tek başına seçtiği sayılar olmamalıdır. İş akışının durması, tekrar veri girme maliyeti ve kurtarma bütçesi birlikte değerlendirilmelidir.

Kaynak: AWS Well-Architected · Kurtarma hedefleri ve test yaklaşımı

Çalışan veritabanında tutarlı bir kopya oluşturun

Uygulama veri yazarken dosyayı kopyalamakla veritabanının desteklediği yedekleme yöntemini kullanmak aynı şey değildir. SQLite için Online Backup API, çalışan veritabanından bir anlık görüntü üretmek üzere tasarlanmıştır. Yöntem seçerken kullanılan veritabanının resmî dokümantasyonunu esas almak gerekir.

Kendi SQLite uygulamamızda çevrimiçi kopyadan sonra ayrı bir dosyaya geri yükleme yapıyoruz. Bütünlük kontrolünün yanında beklenen tabloların okunabilmesini de kontrol ediyoruz. Böylece yalnız dosyanın oluştuğunu değil, veritabanı olarak açıldığını da doğruluyoruz.

Kaynak: SQLite · Online Backup API

Şifreleme ve silme yetkisi ayrı kararlardır

Şifreli bir arşiv okunmaya karşı koruma sağlar; aynı hesabın tüm arşivleri silmesini kendiliğinden engellemez. Yedek oluşturan, alan ve geçmiş kopyaları yöneten hesapların yetkilerini bu nedenle ayrı ele alıyoruz.

İç altyapı çalışmamızda alıcı hesabın geçmiş korunan arşivleri silememesi hedeflendi. Bu, mutlak değiştirilemezlik iddiası değildir: sunucunun tam yetkili yöneticisi hâlâ farklı bir güven sınırındadır. Tasarımın hangi hesabı, hangi eyleme karşı sınırlandırdığı açık yazılmalıdır.

Anahtar da kurtarma planının parçasıdır

Arşiv sağlam olsa bile şifre çözme anahtarına erişilemiyorsa geri dönüş yapılamaz. Anahtarı yalnız kaybedilecek sunucuda tutmak bu yüzden yeterli değildir. Anahtarın saklandığı yer, erişebilecek kişi ve kayıp halinde izlenecek yol önceden belirlenmelidir.

Ayrı lokasyondaki ek kopya, aynı fiziksel olaydan etkilenme riskini azaltır. Ancak dizüstü bilgisayar gibi bazen kapalı olan bir hedef, kesintisiz kopyalama sistemi gibi sunulmamalıdır. Kopyanın ne zaman güncellendiği ayrıca izlenmelidir.

Kurtarma denemesini uygulama seviyesine taşıyın

Pratik kabul listemiz aşağıdaki adımları içerir. Kontrollerin sonucu ve zamanı kaydedilir; bir kez başarıyla yapılan deneme gelecekteki her arşiv için garanti oluşturmaz.

• Arşivin bütünlüğünü ve şifre çözmeyi doğrula.
• Canlı sistemden ayrı bir alana geri yükle.
• Veritabanını aç, beklenen tabloları ve ilişkileri kontrol et.
• Uygulamanın kritik okuma ve yazma akışını örnek veriyle çalıştır.
• Harcanan süreyi, eksik erişimleri ve düzeltilecek adımları kaydet.

Bu çalışmadan çıkan karar

İç sistemimizde farklı konumlarda şifreli kopyalar ve izole veritabanı geri yükleme denemeleri uygulandı. Bir müşterinin kurtarma planında ise bunlara iş akışına özgü kabul senaryoları eklenmesi gerekir. “Yedek başarılı” bildirimi ile “iş yeniden çalışıyor” sonucu arasındaki farkı bu senaryolar kapatır.