DynamoDB BackupNotFoundException

TL;DR — DynamoDB, sağladığınız BackupArn ile eşleşen bir yedeğe sahip değil. Neredeyse her zaman yanlış veya hatalı biçimlendirilmiş bir ARN, silinmiş veya süresi geçmiş bir yedek ya da yanlış bölgeye/hesaba yöneltilmiş bir istemci. Tablonun yedeklerini listeleyin ve tam ARN'i kopyalayın.

Ne anlama gelir

BackupNotFoundException: Backup not found for the given BackupARN.

Geri yükleme ve tanımlama çağrıları (RestoreTableFromBackup, DescribeBackup, DeleteBackup), bir yedeği ARN'i ile adresler. Bu HTTP 400, kimlik bilgilerinizin çözümlendiği bölge + hesapta o ARN'de hiçbir yedeğin bulunmadığı anlamına gelir. İstemci tarafındadır ve ARN doğru olana kadar yeniden denenebilir değildir.

Neden olur

Yanlış veya hatalı biçimlendirilmiş ARN — bir yazım hatası, kesilmiş bir ARN ya da list-backups'tan kopyalanmak yerine elle oluşturulmuş bir ARN.
Yedek silindi veya süresi geçti — biri talep üzerine yedeği kaldırdı, bir AWS Backup yaşam döngüsü kuralı onu yaşlandırdı ya da bu, oluşturulmasından 35 gün sonra süresi geçen bir SYSTEM yedeğiydi (PITR etkin bir tablo silindiğinde otomatik olarak oluşturulur).
Yanlış bölge — list-backups/describe-backup bölgeseldir; yedek, oluşturulduğu bölgede (ARN'ine gömülü bölge) bulunur, dolayısıyla başka yere yöneltilmiş bir istemci onu göremez.
Yanlış hesap — kimlik bilgileri, yedeğin sahibi olandan farklı bir AWS hesabına çözümleniyor.
AWS Backup tarafından yönetilen kurtarma noktası — AWS Backup üzerinden zamanlanan yedekler, yaşam döngüsü kurallarının onları geçirebildiği ya da silebildiği bir AWS Backup kasasında kurtarma noktaları olarak saklanır; bir yedek beklediğiniz yerde değilse AWS Backup konsolunu kontrol edin.

Nasıl düzeltilir

Tablonun yedeklerini listeleyin ve gerçek ARN'i alın:
```
aws dynamodb list-backups --table-name <Table> --region <r>
```
Var olduğunu ve kullanılabilir olduğunu doğrulayın:
```
aws dynamodb describe-backup --backup-arn <arn> --region <r>
```
BackupStatus AVAILABLE olmalı — oluşturma/silme/geri yükleme aşamasındaki bir yedek, çakışan çağrıları bunun yerine BackupInUseException ile reddeder.
Bölgeyi yedeğin ARN'indekine (yedeğin oluşturulduğu bölgeye) sabitleyin.
aws sts get-caller-identity ile hesabı doğrulayın.
Yedek bir AWS Backup planıyla mı alındı? AWS Backup konsolunda (kasasının kurtarma noktalarında) arayın — oradaki yaşam döngüsü kuralları yedekleri bir zamanlamaya göre geçirebilir veya silebilir.

DynoTable'dan bağlanın

DynoTable bir yedekleme konsolu değil, bir tablo tezgahıdır; RestoreTableFromBackup'ı aramadan önce geri yükleme yapmayı planladığınız bölgede canlı tablonun mevcut olduğunu doğrulamak için bunu kullanın. Hedef bölge profilini açın (⌘P), ⌘K → tabloyu ada göre açın ve profil çipindeki kimlik bilgisi durumuyla hesabı doğrulayın.

BackupNotFoundException ile geri yükleme başarısız olursa, ARN yanlıştır veya süresi dolmuştur; Bunu AWS Yedekleme / DynamoDB Yedekleme API'lerinde düzeltin, ardından geri yüklenen tablo şemasını ve öğelerini incelemek için DynoTable'ye geri dönün. item sana calculator, geri yüklenen öğe şeklinin hâlâ kapasite planınıza uyup uymadığının kontrol edilmesine yardımcı olur.

Kaynaklar

DescribeBackup — Amazon DynamoDB API Reference (2026-07-13 tarihinde doğrulandı)
Restoring a DynamoDB table from a backup (2026-07-13 tarihinde doğrulandı)

İlgili hatalar

BackupInUseException — yedek var ama çakışan bir yedekleme işlemi hâlâ çalışıyor.
ResourceNotFoundException — tablonun kendisi bölgede/hesapta bulunamıyor.
Table already exists — geri yüklemenin hedef tablo adı alınmış.
Öğrenin: Backups & point-in-time recovery

Kaynaklar

En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı.