Description of problem: The official documentation here: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.9/html/upgrading_and_updating_red_hat_satellite/cloning_satellite_server#sec-Pulp_Data_Considerations Advises that /var/lib/pulp can be omitted from the backup process and rsync'd to the target server independently. We have rsync'd the /var/lib/pulp directory to the target server prior to running satellite-clone. When Satellite-clone is run the 800GB of pulp data that was rsync'd is wiped out by the process. If there are additional steps required to utilize the rsync'd data they are either not present in the documentation for satellite-clone or not obvious. Version-Release number of selected component (if applicable): 2.0.3-1 How reproducible: Follow the documented instructions for satellite-clone Steps to Reproduce: 1.Create a backup of the satellite using satellite-maintain backup and include the option --skip-pulp 2.Synchronize the contents of /var/lib/pulp from the source Satellite to the target server 3.Run satellite-cone Actual results: during the satellite-clone process the transferred contents of /var/lib/pulp are deleted. Expected results: The contents of /var/lib/pulp are recognized and used by the process Additional info: The deletion of the contents of /var/lib/pulp occurs during the execution of the task "restore using foreman-maintain" from /usr/share/satellite-clone/roles/satellite-clone/tasks/main.yml If the option --skip-pulp is used <backup dir>/pulp_data.tar is not created. Both the satellite-clone role and foreman-maintain ruby gem seem to use the presence of pulp_data.tar as a flag. This is impacting an active consulting engagement with a Red Hat customer.
Following the documentation as currently written leads one to use rsync to restore the Pulp filesystem BEFORE running the satellite-clone utility. That procedure will never work, because satellite-clone uses `foreman-maintain restore ...` to import the data, and `foreman-maintain restore ...` first calls `satellite-installer --reset-data` which resets all databases and the Pulp filesystem (presumably this is done to import the data onto a "blank slate"). If rsyncing the Pulp filesystem is preferable for large deployments vs. collecting that data in the backup, it must be performed after `satellite-clone` has imported other data. I'll change the component of this BZ to "documentation" for now. Please report back if the alternate ordering of the steps resolved the issue, and in that case it should be relatively straightforward to update the documentation with proper ordering of the steps. In case there is some other issue with the modified order, please report back for further evaluation. Thank you,
Still trying to simulate the alternate order of steps. Will report back when I have an answer.
The fix is already available in downstream satellite versions. Moving to on_qa for verification.