DynamoDB Yedekleme ve Point-in-Time Recovery: Eksiksiz Rehber

DynamoDB verinizi iki şekilde korur. On-demand yedeklemeler, aldığınız ve süresiz tuttuğunuz tam anlık görüntülerdir. Zaman-noktası kurtarma (PITR), tabloyu sürekli ilerleyen bir pencere içindeki herhangi bir saniyeye geri yüklemenizi sağlayan sürekli, otomatik bir yedeklemedir. Her ikisi de yeni bir tabloya geri yükler — bunlar kurtarma araçlarıdır, bir geri alma düğmesi değil.

Denetim günlüğü için bu tartışılamaz. Değişmez bir uyumluluk kaydıdır; olayları yeniden yazan kötü bir taşıma ya da kazara bir toplu silme, hatadan önceki ana geri yüklenebilir olmalıdır.

DynamoDB yedekleme ve zaman-noktası kurtarma nasıl çalışır?

DynamoDB iki yedekleme türü sunar. Zaman-noktası kurtarma (PITR), sürekli otomatik yedeklemeler alır ve yapılandırılabilir 1-ila-35 günlük bir pencere içindeki herhangi bir saniyeye geri yüklemenizi sağlar. On-demand yedeklemeler, süresiz tutulan manuel tam anlık görüntülerdir. Her ikisi de orijinalin üzerine değil, yeni bir tabloya geri yükler, bu yüzden yerinde bir geri alma değil, kurtarma araçlarıdır.

• 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 yedeklemeler = manuel tam anlık görüntüler, PITR'nin penceresinden bağımsız olarak istediğiniz kadar tutulur.
• Geri yüklemeler yeni bir tablo oluşturur. Yeni bir ada geri yüklersiniz, sonra geçiş yaparsınız — orijinale 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 transaction günlüğü ve bir yazmada "geri alma" yoktur. Bir taşıma betiği her olayın action alanını yeniden yazarsa ya da biri amaçlanandan daha geniş bir silme çalıştırırsa, tablo basitçe yanlış durumda olur. Yedeklemeler olmadan, veri gitmiştir.

Bir denetim günlüğü için — tüm değeri güvenilir bir kayıt olmaktan gelen — "geçen Salı'nın olaylarını geri getiremiyoruz" bir uyumluluk hatasıdır, sadece bir sıkıntı değil.

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

Zaman-noktası kurtarma, bir kez etkinleştirildiğinde, sürekli otomatik yedeklemeler alır. AWS belgelerine göre, PITR size saniye başına geri yükleme ayrıntı düzeyiyle tablo verisinin tamamen yönetilen sürekli yedeklemelerini verir. Pencere, RecoveryPeriodInDays aracılığıyla 1 ila 35 gün olarak yapılandırılabilir ve içindeki herhangi bir saniyeye geri yükleyebilirsiniz — gerçek zamanın kabaca beş dakika gerisine kadar (LatestRestorableDateTime) — farklı bir bölgeye dahil.

Ö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.

PITR ayrıca yönetilen S3'e dışa aktarımı da kapılar: dışa aktarım aynı sürekli yedeklemelerden okur, dolayısıyla PITR kapalıyken ExportTableToPointInTime PointInTimeRecoveryUnavailableException ile başarısız olur.

On-demand yedeklemeler ayrıdır: açıkça oluşturduğunuz ve süresiz sakladığınız manuel, tam tablo anlık görüntüleri, taşıma öncesi bir kontrol noktası veya 35 günlük PITR penceresinin ötesinde uzun vadeli bir uyumluluk arşivi için kullanışlıdır. İstek anında işlenir ve yedekleme dakikalar içinde geri yüklenebilir hale gelir, tablonun verimliliğinden hiç tüketmez ve kaç tane sakladığınıza dair bir sınır yoktur. Belgelerden dürüst bir uyarı: on-demand yedeklemeler öğeler arasında nedensel tutarlılığı garanti etmez — güncellemeler arasındaki kayma "usually much less than a second" olsa da, bir yazma patlamasının ortasında alınan bir yedekleme tek bir donmuş an değildir.

Bir geri yüklemenin geri getirmedikleri

Bir geri yükleme, tablonun verisini ve indekslerini yeniden oluşturur — operasyonel bağlantılarını değil. AWS belgelerine göre, geri yüklenen tabloda şunları elle yeniden yapılandırmanız gerekir: otomatik ölçeklendirme politikaları, IAM politikaları, CloudWatch metrikleri ve alarmları, etiketler, stream ayarları, TTL, silme koruması ve PITR'nin kendisi. Yedeklemeden geri yükleyip PITR'yi yeniden etkinleştirmeyi unutmak, bir sonraki olayın kurtarılamaz hale gelme biçimidir.

Geri yükleme sırasında bazı ayarları bilerek değiştirebilirsiniz — faturalandırma modu, sağlanan kapasite, şifreleme anahtarları — ve ikincil indekslerin bir kısmını ya da tamamını hariç tutabilirsiniz; bunları sonradan yeniden kurabiliyorsanız geri yükleme daha hızlı ve daha ucuz olur. Geri yüklemeler farklı bir bölgeyi de hedefleyebilir ve bir geri yükleme mevcut bir tablonun asla üzerine yazmaz.

AWS Backup ile zamanlanmış yedeklemeler

DynamoDB'nin kendi on-demand yedeklemelerinin bir zamanlayıcısı yoktur. Saklama kurallarıyla birlikte yinelenen yedeklemeler için DynamoDB, AWS Backup ile yerel olarak entegre olur (AWS belgeleri): yedekleme planları size yaşam döngüsü kurallarıyla (soğuk depolama katmanlaması dahil) zamanlanmış yedeklemeler, olağanüstü durum kurtarma için otomatik hesaplar arası ve bölgeler arası kopyalar, yedekleme kasası aracılığıyla bağımsız bir KMS anahtarı ve kimsenin sessizce silemeyeceği bir WORM uyumluluk duruşu için Vault Lock verir. İki operasyonel tuzak: AWS Backup hesap ve bölge başına açıkça etkinleştirilmelidir ve oluşturduğu yedeklemeler (AWS_BACKUP türü) DynamoDB konsolundan silinemez — bunları AWS Backup içinde yönetin.

Her ikisi de mevcut olanın üzerine değil, yeni bir tabloya geri yükler:

İşlenmiş bir örnek: kötü bir taşımadan kurtarma

Bir expiresAt attribute'u eklemesi gereken bir taşıma, bunun yerine her olaydaki action'ı boş bir dizeyle üzerine yazdı. PITR 35 günlük bir pencereyle açık, bu yüzden taşımanın çalıştığı andan önceki saniyeye geri yüklersiniz:

Geri yüklemeyi doğrularken bozuk tabloya dokunulmaz — geri yüklenen olayları canlı olanlarla karşılaştırır, action değerlerinin geri döndüğünü onaylar, sonra uygulamayı yeniden yönlendirirsiniz. Kurtarmanın kendisinde hiçbir şey yok edilmez.

Kayıp, tüm tablo bozulması yerine bir avuç item olsaydı, bunun yerine canlı veriyi ve geri yüklenen kopyayı inceleyip yalnızca etkilenen satırları aktarabilirdiniz — bkz. bir DynamoDB tablosunu kopyalama.

Bunu DynoTable'da yapın

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

DynoTable, geri yüklenen tabloya diğer herhangi biri 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 herhangi bir tablo için açın.
• PITR'yi devre dışı bırakmak pencereyi sıfırlar. Onu kapatıp geri 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 yepyeni bir tablo sağlar ve boyutla orantılı zaman alır; süre ve fazladan tablo için bütçe ayırın.
• 35 gün arşivleme değildir. PITR penceresinin ötesinde saklama için, on-demand yedeklemeler alın veya 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, tepki 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 birlikte nasıl uyduğunu görmek için Operasyonlar ve Maliyet genel bakışını yeniden ziyaret edin.

DynoTable'ı indirin, geri yüklenen bir tabloya bağlanın ve ona güvenmeden önce kurtarmanızı doğrulayın.