Bug 1387785

Summary: katello-restore fails when backup created with --skip-pulp-content
Product: Red Hat Satellite Reporter: Kev <kholmes>
Component: Backup & RestoreAssignee: Christine Fouant <cfouant>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.2.2CC: bbuckingham, cfouant
Target Milestone: Unspecified   
Target Release: Unused   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-31 19:10:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Kev 2016-10-21 21:44:58 UTC
Description of problem:
katello-restore gives error:
**** Given directory does not include pulp content ****
**** Please choose a backup that contains pulp content ****


Version-Release number of selected component (if applicable):
Satellite 6.2


How reproducible:
perform a backup using --skip-pulp-content, then restore following the documentation.

Steps to Reproduce:
1.    katello-backup --skip-pulp-content /backup/

2.    katello-restore /backup/



Actual results:
**** Given directory does not include pulp content ****
**** Please choose a backup that contains pulp content ****
Usage: katello-restore /path/to/dir [options]
 eg: $ katello-restore /tmp/katello-backup
    -y, --assumeyes                  Answer yes for all questions




Expected results:
successful restore without errors



Additional info:
the undocumented fix is to manually create a file in the backup directory called pulp_data.tar to trick the restore into seeing the backup as an acceptable full restore.  An error is given, due to the corrupt pulp_data.tar file, but the restore successfully restores DB info that was backed up.

Comment 2 Brad Buckingham 2016-10-31 19:10:12 UTC
Closing this as a duplicate of 1389814.  This one is older; however, given that the other is currently tracking a higher PM score, I'd like to keep it to ensure quicker resolution.

*** This bug has been marked as a duplicate of bug 1389814 ***