Feature Overview (aka. Goal Summary)  

Provide tools and procedures for manually backing up and restoring the MicroShift data

Goals (aka. expected user outcomes)

Customers, esp. on non-ostree deployments, need a way to manually backup/restore MicroShift state, e.g. for DR requirements.

Requirements (aka. Acceptance Criteria):

• Provide a tool to create a consistent backup of MicroShift state, esp. the etcd database. I
• It is acceptable to stop MicroShift/etc during the backup process so that the k8s API becomes unavailable and no scheduling is happing during that time.
• Taking the backup should not have any affect on the user workload. All pods should keep running, incl. ingress/egress traffic. Only calls to the k8s API initiated by pods may fail.
• The tool shall create a single tar.gz file on the device with meaningfull name (e.g. date/timestamp on when the backup was created).
• Restore is expected to happen against a fresh installation of MicroShift which has not yet been started with no previous state. Hostname/IP adress of the fresh installation might have changed. This shall be treated upon startup like a node/IP change of a regular MicroShift installation

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

Out of Scope

• Backup/Restore of workload data, i.e. PV/PVCs is out of scope. This needs to be done by external 3d party k8s backup/restore solutions.
• Moving the backup from the device to a save harbour - that has to be done by the user using regular RHEL means of remote file transfer (e.g. scp).
• rpm based rollbacks. While the manual process can be used to rollback, we do not support/test this use case. It is up to the user to validate that.

Background

For ostree bases installation, the necessary tooling has already been developed. But its not exposed to customers or document. 

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

Documentation Considerations

Manual backup/restore procedures need to be document in a seperate section. 

Interoperability Considerations

Which other projects and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.