Create an informative issue (See each section, incomplete templates/issues won't be triaged)

Using the current documentation as a model, please complete the issue template.

Note: Doc team updates the current version and the two previous versions (n-2). For earlier versions, we will address only high-priority, customer-reported issues for releases in support.

Prerequisite: Start with what we have

Always look at the current documentation to describe the change that is needed. Use the source or portal link for Step 3:

• Use the Customer Portal: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.6

• Use the GitHub link to find the staged docs in the repository: https://github.com/stolostron/rhacm-docs

  Describe the changes in the doc and link to your dev story

Provide info for the following steps:

1. - [X] Mandatory Choose the documentation release (Published releases are refreshed ~weekly after publication).

• [ ] ACM 2.5
• [ ] ACM 2.6
• [ ] ACM 2.7
• [X]ACM 2.8 (upcoming release)

• [ ] MCE 2.1
• [ ] MCE 2.2
• [ ] MCE 2.3 (upcoming release)

2. - [X] Mandatory Choose the type of documentation change.

• [X] New topic in an existing section or new section
• [ ] Update to an existing topic

https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.7/html/backup_and_restore/backup-intro ??

3. - [ ] Mandatory for bugs: What is the diff? Clearly define what the problem is, what the change is, and link to the current documentation:

4. - [X] Mandatory for GA content:

• [X] Add steps and/or other important conceptual information here:

For the backup/recovery epic, we need the ability of creating extra partitions on nodes. We currently can make it by injecting custom manifests in the specific configmap that is provided for it, but the procedure is not straightforward, and it means customizing the manifests for each deployed cluster.
It would be much more desirable if we could just specify the partition schema for all nodes as part of cluster definition. What we need to specify is:

size of the partition
label that needs to get
filesystem to be added
mountpoint
start size (if may not be needed, if we just add the extra partitions starting from the end)
We are thinking about adding one partition, but it could be more depending on the needs, it would be desirable to make it flexible.

A sample manifest that we are using to customize it, is:

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 03-chrony-ntp
spec:
config:
ignition:
version: 3.2.0
storage:
disks:

device: /dev/sda
partitions:
sizeMiB: 51200
startMiB: 71680
label: recovery
filesystems:
path: /var/recovery
device: /dev/disk/by-partlabel/recovery
label: recovery
format: xfs
We curently nee

• [ ] Add Required access level for the user to complete the task here:

• [ ] Add verification at the end of the task, how does the user verify success (a command to run or a result to see?)

• [ ] Add link to dev story here: