BackupInUseException

TL;DR — 這張表上有一個相互衝突的備份控制平面操作仍在進行中：備份此刻正在被建立、刪除或恢復。這些操作是序列化的——等進行中的那個完成（透過 DescribeBackup 檢查 BackupStatus），然後重試你的操作。

這是什麼意思

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.

按需備份操作（CreateBackup、DeleteBackup、RestoreTableFromBackup）是控制平面呼叫，DynamoDB 會拒絕那些會與已在同一備份或表上執行的操作相沖突的呼叫。這是一個瞬時狀態錯誤，而不是許可權或資料問題。

為什麼會發生

刪除一個仍在建立中的備份——CreateBackup 尚未到達 AVAILABLE。
在從某備份進行恢復時刪除它——恢復操作會一直持有該備份，直到新表建立完成。
重疊的自動化——一個清理指令碼和一個備份排程器互相競爭，或者一個重試迴圈對同一張表重複觸發了 CreateBackup。
突發超過速率限制——DeleteBackup 每秒最多接受 10 次呼叫；在緊湊的迴圈中掃掉大量備份會同時觸發衝突和限流。

如何修正

檢查有什麼正在進行中，然後等待：
```
aws dynamodb describe-backup --backup-arn arn:aws:dynamodb:...:table/orders/backup/01234...
# BackupStatus: CREATING | AVAILABLE | DELETED
```
一旦狀態穩定就重試你的操作（對已完成的建立而言是 AVAILABLE；正在恢復的表會透過 describe-table 到達 ACTIVE）。
用退避重試而非直接硬失敗——備份操作耗時從數秒到數分鐘不等；在呼叫外套一個簡單的等待並重試迴圈即可吸收這種序列化。
序列化你的自動化——每張表由一個所有者負責備份生命週期操作；把刪除排在建立之後，而不是用一個可能重疊的 cron 同時執行兩者。
控制批次刪除的節奏——保持在每秒 10 次 DeleteBackup 呼叫以下，並把這個異常當作放慢速度的訊號來處理。

備份保護的是你最輸不起的資料——在刪除某張表的備份之前，先用 DynoTable 桌面應用瀏覽一下表裡實際有什麼，並用 DynamoDB 定價計算器估算恢復的讀取流量。

在 DynoTable 中定位

在刪除備份之前，請瀏覽它們保護的實時表 - 使用 ⌘K 開啟它並確認資料仍然重要。 DynoTable 可以在清理指令碼執行之前跨帳戶抽查表內容 (⌘P)。當你計劃 RestoreTableFromBackup 時，使用 pricing calculator 估計恢復讀取流量。在“設定”→“設定檔案”下為擁有備份的每個帳戶配置設定檔案“Test Connection”。參見連線 AWS和安裝。在等待正在進行的備份完成時，使用 ⌘K 瀏覽受保護的表，以確認資料仍然值得保留。每隔幾秒進行一次DescribeBackup輪詢就足夠了——備份建立通常在幾分鐘內完成，刪除也有類似的限制。

來源

DeleteBackup — Amazon DynamoDB API Reference（2026-07-13 驗證）
Restoring a DynamoDB table from a backup（2026-07-13 驗證）

參考資料

最後核實於 2026-07-13，依據上方連結的 AWS 官方文件。