2 Commits

Include renames

Author	SHA1	Message	Date
chlins	fa717d4e48	Add in-place restore pre-flight check: PVC must be bound to the backed-up PV ... An in-place restore onto a different volume than the one backed up is unsafe: an incremental (CBT) restore computes deltas against a different volume lineage, and even a full restore would patch and write into an unrelated volume. Verify the existing PVC is bound and still bound to the PV recorded at backup time before any side effect, on both the CSI data mover path (using the backed-up PVC's volume name) and the file system path (using the PVC-to-PV mapping from the backup volume info). The PV comparison is skipped for namespace-mapped restores, where the target PVC is necessarily bound to a different PV (the documented cross-namespace clone-and-restore workflow). Signed-off-by: chlins <chlins.zhang@gmail.com>	2026-09-03 13:59:42 +08:00
Chlins ZhangandGitHub	efc69c61aa	Add in-place restore pre-flight check: target PVC must not be in use (#10419) ... Check the target PVC is not used by any active pod before any side effect, on both the CSI data mover path and the file system path. The in-use semantics align with the pvc-protection controller: terminal-phase pods don't block, terminating pods block with a wait hint. On the file system path, pods gated by this restore's restore-wait init container (identified by the restore UID in its args, and not yet terminated) are exempted: they must mount the PVC for the node-agent to restore the data and cannot write to the volume until the PodVolumeRestores complete. Leftover pods, controller-recreated pods, and pods gated by a different restore still block. Signed-off-by: chlins <chlins.zhang@gmail.com>	2026-09-01 17:08:25 +08:00