Epic Goal

• Improve on the hub backup design used in 2.4 and make sure we are able to backup all resources created on the hub. When the hub becomes unavailable, a new hub should be able to restore the resources backed up on the initial hub, with no lost of information.

• We require each squad to check off an item in the DoneDoneDone checklist that states they have considered and either annotated or verified that all hub resources that are required to be backed up are covered by the backup routine (see details in the scenario below)

Why is this important?

• Simplifies the backup strategy, makes sure it includes all CRD installed on the hub; and is a simple way to extend the solution

Scenarios

With this approach we expect to be able to include all CRDs installed on the hub and part of this groups 
1. *exclude resources in the NS - open-cluster-management - where MCH is installed* ( this is to avoid backing up install channel, subscriptions ) 
2. api group ends with .open-cluster-management.io
3. all CRD from these api groups :

4. EXCLUDE the following apigroups : 
```
        "admission.cluster.open-cluster-management.io",
        "admission.work.open-cluster-management.io",
        "internal.open-cluster-management.io",
        "operator.open-cluster-management.io",
        "work.open-cluster-management.io",
```

5. Excluded resources ( they are explicitly excluded here to ease the squads work ; resources can also be excluded by adding the label `velero.io/exclude-from-backup=true' - item 7 below )
```
        "clustermanagementaddon",
        "observabilityaddon",
        "applicationmanager",
        "certpolicycontroller",
        "iampolicycontroller",
        "policycontroller",
        "searchcollector",
        "workmanager",
        "backupschedule",
        "restore",
        "clusterclaim.cluster.open-cluster-management.io",
```
5. For secrets, the backup controller in 2.5 backs up secrets containing one of these labels ( so as long as the secrets contain one the labels below they are being backed up ) : [
"cluster.open-cluster-management.io/type", "hive.openshift.io/secret-type","cluster.open-cluster-management.io/backup"]
6. All other resources not contained by the above rules that must be backed up, should include this label "cluster.open-cluster-management.io/backup"  ( we ask each squad to review the resources they need to backup and make sure they are being picked up by rule 1 or 2 above; it not, they should use the label defined in the current step to annotate the resource )
7.  Resources that are included in the list above and SHOULD NOT be backed up , can be explicitly excluded by adding this label `velero.io/exclude-from-backup=true` 

Regarding the valid values for the cluster.open-cluster-management.io/backup ( step 3 above ) :

We want each team to annotate using the  cluster.open-cluster-management.io/backup:<type> label any Secrets, ConfigMap and any other CR they create - if those resources need to be backed up.

As long as the resource defines this label, it will be backed up; the value does not matter

The value of the label ( <type> ) could be used to identify what group/type of resource is this ( policy squad could use a policy label , etc ) 

Any key is a valid option, for example :

1. 1. cluster.open-cluster-management.io/backup: ''  
   2. cluster.open-cluster-management.io/backup: 'cluster'  
   3. cluster.open-cluster-management.io/backup: 'policy'  
   4. cluster.open-cluster-management.io/backup: 'anyString' 
       

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>