BackupInUseException

TL;DR — Auf dieser Tabelle läuft noch eine kollidierende Backup-Control-Plane-Operation: Das Backup wird gerade erstellt, gelöscht oder zurückgespielt. Diese Operationen laufen seriell — warte, bis die laufende fertig ist (prüfe BackupStatus per DescribeBackup), und wiederhole deine dann.

Was es bedeutet

BackupInUseException: There is another ongoing conflicting backup control
plane operation on the table. The backup is either being created, deleted
or restored to a table.

On-Demand-Backup-Operationen (CreateBackup, DeleteBackup, RestoreTableFromBackup) sind Control-Plane-Aufrufe, und DynamoDB weist solche ab, die mit einer bereits laufenden Operation gegen dasselbe Backup oder dieselbe Tabelle in Konflikt stünden. Es ist ein vorübergehender Zustandsfehler, kein Berechtigungs- oder Datenproblem.

Warum es passiert

Löschen eines Backups, das noch erstellt wird — das CreateBackup hat AVAILABLE noch nicht erreicht.
Löschen eines Backups, während eine Wiederherstellung daraus läuft — die Wiederherstellung hält das Backup, bis die neue Tabelle fertig erstellt ist.
Überlappende Automatisierung — ein Cleanup-Skript und ein Backup-Scheduler, die sich gegenseitig behindern, oder eine Retry-Schleife, die CreateBackup doppelt auf dieselbe Tabelle feuert.
Überschreiten des Rate-Limits — DeleteBackup akzeptiert höchstens 10 Aufrufe pro Sekunde; das Durchgehen vieler Backups in einer engen Schleife löst Konflikte und Throttling zugleich aus.

So behebst du es

Prüfe, was in Bearbeitung ist, und warte dann:
```
aws dynamodb describe-backup --backup-arn arn:aws:dynamodb:...:table/orders/backup/01234...
# BackupStatus: CREATING | AVAILABLE | DELETED
```
Wiederhole deine Operation, sobald sich der Status stabilisiert hat (AVAILABLE für ein abgeschlossenes Create; eine wiederherzustellende Tabelle erreicht ACTIVE via describe-table).
Wiederhole mit Backoff, statt hart zu scheitern — Backup-Operationen dauern Sekunden bis Minuten; eine einfache Warten-und-Wiederholen-Schleife um den Aufruf fängt die Serialisierung ab.
Serialisiere deine Automatisierung — ein Owner pro Tabelle für Backup-Lifecycle-Operationen; stelle Deletes hinter Creates in eine Warteschlange, statt beide auf einem Cron laufen zu lassen, der überlappen kann.
Drossle Massen-Deletes — bleibe unter 10 DeleteBackup-Aufrufen/Sekunde und behandle diese Exception als Signal zum Verlangsamen.

Backups schützen die Daten, die du dir am wenigsten leisten kannst zu verlieren — durchsuche mit der DynoTable-Desktop-App, was tatsächlich in einer Tabelle steckt, bevor du ihre Backups beschneidest, und schätze den Read-Traffic der Wiederherstellung mit dem DynamoDB-Preisrechner.

In DynoTable erkennen

Bevor du delete backups, browse die Live-Tabelle, die sie schützen — open it with ⌘K and bestätige, dass die Daten noch relevant sind. DynoTable macht es praktisch, Tabelleninhalte über Accounts hinweg zu spot-checken (⌘P) bevor ein Cleanup-Script läuft.

Schätze Restore-Read-Traffic mit dem Pricing-Rechner wenn du plan a RestoreTableFromBackup. Konfiguriere Profile unter Einstellungen → Profile with Verbindung testen für jeden Account, der Backups besitzt. Siehe Mit AWS verbinden und Installation. Während waiting for an in-flight backup to finish, browse protected tables with ⌘K um zu bestätigen, dass die Daten Retention rechtfertigen. Ein DescribeBackup-Poll alle paar Sekunden reicht — Backup-Creates sind typischerweise in Minuten fertig, und Deletes sind ähnlich begrenzt.

Quellen

DeleteBackup — Amazon DynamoDB API Reference (verifiziert 2026-07-13)
Restoring a DynamoDB table from a backup (verifiziert 2026-07-13)

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.