DynamoDB Yedekleme ve Point-in-Time Recovery

DynamoDB verilerinizi iki yolla korur. On-demand yedekler, alıp süresiz sakladığınız tam anlık görüntülerdir. Point-in-time recovery (PITR), tabloyu kayan bir pencere içindeki herhangi bir saniyeye geri yüklemenizi sağlayan sürekli, otomatik yedeklemedir. İkisi de yeni bir tabloya geri yükler — bunlar kurtarma araçlarıdır, geri-al düğmesi değil.

Denetim günlüğü için bu tartışmaya kapalıdır. Bu, değiştirilemez bir uyumluluk kaydıdır; olayları yeniden yazan kötü bir geçiş ya da kazara yapılan bir toplu silme, hatadan önceki ana kadar kurtarılabilir olmak zorundadır.

DynamoDB yedekleme ve point-in-time recovery nasıl çalışır?

DynamoDB iki yedekleme türü sunar. Point-in-time recovery (PITR), sürekli otomatik yedekler alır ve yapılandırılabilir 1-ila-35-gün penceresi içindeki herhangi bir saniyeye geri yüklemenizi sağlar. On-demand yedekler ise süresiz saklanan manuel, tam anlık görüntülerdir. İkisi de orijinalin üzerine değil, yeni bir tabloya geri yükler; bu yüzden yerinde bir geri-al değil, birer kurtarma aracıdırlar.

• PITR = sürekli yedekleme, herhangi bir saniyeye geri yükleme — yapılandırılabilir 1 ila 35 günlük bir pencere içinde (eskiden sabit 35 idi).
• On-demand yedekler = istediğiniz kadar saklanan manuel tam anlık görüntüler, PITR'nin penceresinden bağımsız.
• Geri yüklemeler yeni bir tablo oluşturur. Yeni bir ada geri yükler, sonra geçiş yaparsınız — orijinaline dokunulmaz.
• PITR tablo boyutuna göre fiyatlandırılır, geri yükleme noktalarının sayısına göre değil — bunu DynamoDB Fiyatlandırma Hesaplayıcısı ile tahmin edin.

Sorun: yerinde geri alamayacağınız bir hata

DynamoDB'nin geri alabileceğiniz bir işlem günlüğü ve bir yazma üzerinde "geri-al" yoktur. Bir geçiş betiği her olayın action alanını yeniden yazarsa ya da biri amaçlanandan geniş bir silme çalıştırırsa, tablo basitçe yanlış durumdadır. Yedekler olmadan veri yok olur.

Bir denetim günlüğü için — ki tüm değeri güvenilir bir kayıt olmasıdır — "geçen salının olaylarını geri getiremiyoruz" sadece bir rahatsızlık değil, bir uyumluluk başarısızlığıdır.

Yedekleme ve PITR nasıl çalışır

Point-in-time recovery, etkinleştirildiğinde sürekli otomatik yedekler alır. AWS dokümanlarına göre PITR "saniye düzeyinde granülerlikte 35 güne kadar kurtarma noktasıyla tablo verisinin tamamen yönetilen, otomatik sürekli yedeklerini sağlar." Pencere, RecoveryPeriodInDays aracılığıyla 1 ila 35 gün arasında yapılandırılabilir ve içindeki herhangi bir saniyeye — farklı bir bölgeye dahil — geri yükleyebilirsiniz.

Önemli bir uç durum: kurtarma süresini azaltmak en erken geri yükleme noktasını hemen düşürür ve PITR'yi devre dışı bırakıp yeniden etkinleştirmek kurtarılabilir başlangıç zamanını sıfırlar — önceki sürekli geçmişi kaybedersiniz.

On-demand yedekler ayrıdır: açıkça oluşturduğunuz ve süresiz sakladığınız manuel, tam tablo anlık görüntüleridir; geçiş öncesi bir kontrol noktası ya da 35 günlük PITR penceresinin ötesinde uzun vadeli bir uyumluluk arşivi için kullanışlıdır.

İkisi de var olanın üzerine değil, yeni bir tabloya geri yükler:

Çalışılmış bir örnek: kötü bir geçişten kurtarma

expiresAt özniteliği eklemesi gereken bir geçiş, bunun yerine her olaydaki action'ı boş bir dizeyle üzerine yazdı. PITR 35 günlük pencereyle açık, bu yüzden geçişin çalıştığı saniyenin öncesine geri yüklersiniz:

Bozuk tablo, geri yüklemeyi doğrularken dokunulmadan kalır — geri yüklenmiş olayları canlı olanlarla karşılaştırır, action değerlerinin geri geldiğini doğrular, sonra uygulamayı yeniden yönlendirirsiniz. Kurtarmanın kendisinde hiçbir şey yok edilmez.

Kayıp, bir tablo bütünündeki bozulma yerine birkaç öğeyse, bunun yerine canlı veriyi ve geri yüklenmiş kopyayı inceleyip yalnızca etkilenen satırları kopyalayabilirsiniz — bkz. bir DynamoDB tablosunu kopyalama.

DynoTable'da yapın

Bir geri yükleme, ancak onu doğrulamanız kadar iyidir. audit-log-restored'a geri yükledikten sonra, kurtarılmış olaylara gerçekten bakmanız ve hatadan önce olması gerekenle eşleştiklerini doğrulamanız gerekir.

DynoTable, geri yüklenen tabloya tıpkı diğerleri gibi bağlanır, böylece etkilenen kiracının olaylarını sorgulayabilir, action değerlerinin doğru olduğunu onaylayabilir ve geçiş yapmadan önce canlı tabloyla karşılaştırabilirsiniz — bir geri yüklemeyi bir inanç sıçramasından doğrulanmış bir kurtarmaya dönüştürerek.

Kurtarılan olayları çevrimdışı bir uyumluluk kaydı için dışa da aktarabilirsiniz — bkz. DynamoDB'yi CSV'ye dışa aktarma.

Tuzaklar ve sonraki adımlar

• PITR'yi ihtiyaç duymadan önce etkinleştirin. Yalnızca açık olduğu andan itibaren korur — geriye dönük kurtarma yoktur. Verisini kaybetmeyi göze alamayacağınız her tablo için açın.
• PITR'yi devre dışı bırakmak pencereyi sıfırlar. Kapatıp tekrar açmak sürekli geçmişi siler; kurtarılabilir başlangıç zamanı yeniden etkinleştirmeden itibaren yeniden başlar.
• Geri yüklemeler anlık ya da ücretsiz değildir. Bir geri yükleme tamamen yeni bir tablo sağlar ve boyutla orantılı zaman alır; süreyi ve ek tabloyu bütçeleyin.
• 35 gün arşivleme değildir. PITR penceresinin ötesindeki saklama için on-demand yedekler alın ya da S3'e dışa aktarın — PITR bir kurtarma penceresidir, uzun vadeli depolama değil.

Bu, denetim günlüğü operasyonları döngüsünü kapatır: tutarlılık için transaction'lar, reaksiyon için Streams, süre dolumu için TTL, maliyet için doğru kapasite modu, bölge dayanıklılığı için global tablolar ve veri kurtarma için PITR. Bunların nasıl bir araya geldiğini görmek için Operasyonlar ve Maliyet genel bakışını yeniden ziyaret edin.

Kurtarmanıza güvenmeden önce geri yüklenmiş bir tabloya bağlanıp doğrulamak için DynoTable'ı indirin.