Define live backup/restore workflow for Harbor.

[reasonerjt]

We need a solution to backup/restore Harbor without having to shut down Harbor instance.

1. We need a reliable approach to quiesc Harbor, or check if it's in a state that is ready to backup. Currently there is a readonly API but after the API is called there may be jobs running in the backend making updates to the storage such as tag retention, replication, GC. And new records of accesslog may be inserted to DB when user pulls artifacts. If that's not possible, we may need to define a "rerequisite" state only in which Harbor can be backed up.
2. We need to clarify the scope of data that will be backed up and restored. For example, the data in redis may be ignored, it may be OK to lose some records in accesslog that are not backed up during this process.
3. We need to define a test process to check the consistency of the data to verify the solution.

[Jeremy-boo]

Will the backup and restore of harbor data be put on the agenda in version 2.5? Now more and more users have requirements in this regard

[reasonerjt]

@Jeremy-boo Currently the flow has to be shut down Harbor, copy all data, and start.

We are still investigating to provide a more reliable way to quiesc Harbor. considering there can be backend jobs running to clean up/replicating data, we still need more understanding regarding what impact such inconsistency may cause.

I'm removing this from 2.5 as we will not provide a very concrete solution per the timeline.

[github-actions]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[github-actions]

This issue was closed because it has been stalled for 30 days with no activity. If this issue is still relevant, please re-open a new issue.