Add csi snapshot data mover doc

[Lyndon-Li]

Add CSI snapshot data movement doc

[codecov-commenter]

Codecov Report

Merging #6637 (1adf842) into main (6997e4a) will increase coverage by 0.07%.
Report is 107 commits behind head on main.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #6637      +/-   ##
==========================================
+ Coverage   60.36%   60.44%   +0.07%     
==========================================
  Files         239      242       +3     
  Lines       25499    26023     +524     
==========================================
+ Hits        15392    15729     +337     
- Misses       9036     9190     +154     
- Partials     1071     1104      +33     

see 39 files with indirect coverage changes

[shawn-hurley]

This looks good to me after the first glance.

[Lyndon-Li]

@sseago @shubham-pampattiwar
Could you help to review this PR?

[shubham-pampattiwar]

Overall looks good ! Added a few comments/nits here and there. Thank you @Lyndon-Li !!

[draghuram]

I just started going through the doc but one thing that is missing is changes to "Backup" spec. The fields "snapshotMoveData" and "datamover" need to be added at https://velero.io/docs/main/api-types/backup/.

[Lyndon-Li]

The fields "snapshotMoveData" and "datamover" need to be added at https://velero.io/docs/main/api-types/backup/.

Done the changes. Added them for both backup and schedule api-types.

[reasonerjt]

backup -> backup controller

[Lyndon-Li]

Done, thanks

[reasonerjt]

Shall we stress that the volume creation is done via dynamic provision, i.e. it only creates the PVC and it has dependency on storageclass on the target cluster?

[Lyndon-Li]

We have mentioned how to configure the storage class on the target in section Configure storage class on target cluster.
I have rephrased the sentence in the same section as below:
On the other hand, Velero built-in data movement creates a PVC with the same specification as it in the source cluster and expects the volume to be provisioned similarly. For example, the same storage class should be working in the target cluster

[reasonerjt]

But a user can patch a dataupload/datadownload CR's spec to cancel the action. Shall we also mention that in the doc?

[Lyndon-Li]

We don't intend to expose this approach to users officially -- when there are many datauploads/downloads in a backup/restore, users may not able to correctly take care of everyone of the datauploads/downloads, and an unexpected result may happen.
For example, a dataupload/datadownload is matched to a wrong backup/restore, as a result, the backup/restore will get to a ParitialFailed status unexpectedly.

[reasonerjt]

For both backup and restore, shall we mention how to monitor the progress of the data movement of each volume via velero backup/restore describe --details ?

[Lyndon-Li]

We have suggested the other way to watch the progress:
You can see the phase changes as well as the data upload progress by watching the DataUpload CRs

This is the most direct way, while velero backup/restore describe --details needs to retrieve data from backup store and is not timely (we have discussed this problem and the possible fix during the Async Operation PR, but not fixed it yet).