Add a manifest for backup/restore

[dsu-igeek]

Describe the problem/challenge you have We would like Velero to be able to:

• Have a dry-run option that allows users to see what Velero is going to do before it does a backup or restore
• Execute multiple backups or restores simultaneously
• Restart backups in the event of a server restart
• Order the restore of resources intelligently

Describe the solution you'd like Currently, Velero does not have a complete manifest of everything in the backup, aside from the backup tarball itself. This change introduces a new data structure to be stored with a backup in object storage which will allow for more efficient operations in reporting of what a backup contains. Additionally, this manifest should enable advancements in Velero's features and architecture, enabling dry-run support, concurrent backup and restore operations, and reliable restoration of complex applications.

Environment:

• Velero version (use velero version):
• Kubernetes version (use kubectl version):
• Kubernetes installer & version:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• :+1: for "The project would be better with this feature added"
• :-1: for "This feature will not enhance the project in a meaningful way"

[eleanor-millman]

Perhaps some helpful detail:

I asked: "the first line of the manifest issue says it will help Velero "Have a dry-run option that allows users to see what Velero is going to do before it does a backup or restore", but if you do a -oyaml on the create backup command, it will show you a yaml of the backup CR that will be created. So what will the manifest add beyond that with regards to backup dry run?"

@zubron replied: "The difference is that the manifest will show all the individual objects/resources that will be included in the backup. The backup CR states the resource type that will be included in the backup (e.g. "pods in namespace foo") but not individual objects/instances of that type. Velero doesn't know until it runs the backup and starts to iterate over the cluster contents what the actual objects in the cluster are.

My understanding of the manifest work is that Velero will look at what the Backup/Restore CRs include and generate the list of actual objects in the cluster that it will interact with before performing the backup or restore operation. This would allow a dry-run option where you could see what actual objects velero would backup or restore before it proceeds with the action. This would be helpful in situations where a user may have specified a backup based on a label selector. Until the Velero actually matches objects on that label during backup/restore, the user wouldn't know what would be included. This would help them spot issues where their selector was incorrect and didn't actually include the resources they wanted."

[eleanor-millman]

@dsu-igeek Why is this issue closed? We see that the design doc was merged, but not the work. Opening until we learn more :)