6 Commits

Include renames

Author	SHA1	Message	Date
Chlins ZhangandGitHub	e164dc5984	Identify the backed-up volume by CSI volume handle in the in-place restore pre-flight check (#10530) ... The pre-flight check that verifies the existing PVC is still bound to the backed-up volume compared PV names. A block data mover restore of a file system volume recreates the PV under a new name (the volumeMode field is immutable), so a second in-place restore of the same workload failed the check even though the PVC was bound to the very same volume. Record the CSI volume handle in the backup volume info (PVInfo) and compare handles when both the backup and the bound PV record one; the PV name remains the fallback for non-CSI volumes and for backups taken before the handle was recorded. The handle reaches the PVC CSI RIA through the same carrier annotation mechanism as the source size. Signed-off-by: chlins <chlins.zhang@gmail.com>	2026-09-16 16:55:27 -04:00
Chlins ZhangandGitHub	96d46c5e8f	Merge pull request #10480 from abhayrajjais01/fix/inplace-preflight-nil-check ... fix(restore): guard against nil PVC in in-place restore preflight checks	2026-09-15 16:15:50 +08:00
chlins	bb01691e6b	Add in-place restore pre-flight check: PVC must be large enough for the source volume ... Compare the existing PVC's capacity against the source volume size recorded in the backup volume info (#10506) before any side effect and skip the volume when it is too small, so the restore fails early instead of running out of space midway. For the block data mover the source size is the device size; for the file system data movers it is the logical size of the backed-up files, a lower bound since file system metadata is not accounted for. The file system path reads the size from the volume info already carried in RestoreData. The PVC CSI RIA has no access to the volume info, so the restore engine carries the size on the PVC item through a Velero-internal annotation, the same mechanism as the selected-node carrier; both carrier annotations are stripped before the item is created in the cluster. The check is skipped when the source size is unknown (backups taken before it was recorded) or the PVC's capacity is not reported. Signed-off-by: chlins <chlins.zhang@gmail.com>	2026-09-11 17:10:14 +08:00
Abhayraj Jaiswal	b51a2b20d3	fix(restore): guard against nil PVC in in-place restore preflight checks ... Signed-off-by: Abhayraj Jaiswal <abhayraj916146@gmail.com>	2026-09-10 09:54:50 +00:00
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