Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 973275

Summary: Unable to restore from 3.1 LogCollector DB backup file
Product: Red Hat Enterprise Virtualization Manager Reporter: Idith Tal-Kohen <italkohe>
Component: ovirt-engineAssignee: Eli Mesika <emesika>
Status: CLOSED ERRATA QA Contact: Ilanit Stein <istein>
Severity: unspecified Docs Contact:
Priority: urgent    
Version: 3.2.0CC: acathrow, bazulay, cpelland, emesika, iheim, istein, jbiddle, jkt, lpeer, pstehlik, Rhev-m-bugs, sgrinber, yeylon, yzaslavs
Target Milestone: ---Keywords: ZStream
Target Release: 3.2.1Flags: istein: needinfo+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Previously, the log collector collected database schema and data in TAR files using the PG pg_dump utility. This caused the pg_dump to add redundant DROP statements for all objects, and so when a restore was run on the TAR file it generated error messages for the redundant DROP statements. Now, the code has been altered so that redundant DROP statements no longer affect the TAR file and restoring a database using the log collector backup file is successful.
Story Points: ---
Clone Of: 960760 Environment:
Last Closed: 2013-07-16 13:43:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 960760    
Bug Blocks:    
Attachments:
Description Flags
restore output none

Comment 3 Ilanit Stein 2013-06-27 13:28:37 UTC
Failed on sf18.2:

[root@istein-32 tmp]# /usr/share/ovirt-engine/dbscripts/restore.sh -u postgres -d engine -f /tmp/00579652_221211073824_pgdump.tar -r -o
Restore of database engine from /tmp/00579652_221211073824_pgdump.tar started...
/tmp/00579652_221211073824_pgdump.tar: tar archive
chcon: can't apply partial context to unlabeled file `/tmp/00579652_221211073824_pgdump.tar_dir'
Failed to restore SELinux default settings for /tmp/00579652_221211073824_pgdump.tar_dir.

** /tmp/00579652_221211073824_pgdump.tar is a 3.1 DB backup in tar format

Eli,

Can you please advise?

Comment 4 Eli Mesika 2013-06-27 14:05:43 UTC
(In reply to Ilanit Stein from comment #3)

what does getenforce return on your machine ?

Comment 5 Ilanit Stein 2013-07-01 05:43:21 UTC
(In reply to Eli Mesika from comment #4)
[root@istein-32 ~]# getenforce 
Disabled

Comment 6 Ilanit Stein 2013-07-02 08:56:43 UTC
The restore works once selinux is enforced/permissive. Opened a separate bug for that https://bugzilla.redhat.com/show_bug.cgi?id=980042.
During the restore there was error "psql:restore.sql:282: ERROR:  language "plpgsql" does not exist", which I am inquiring (full restore output attached). Turning this bug to verified.

Comment 7 Ilanit Stein 2013-07-02 08:57:39 UTC
Created attachment 767665 [details]
restore output

Comment 8 Jodi Biddle 2013-07-08 23:41:36 UTC
Can someone please help me write the tech note for this bug? It's not clear whether or not the issue is in fact caused by the TAR file, or whether this is an SELinux issue as described in BZ #980042.

Comment 9 Eli Mesika 2013-07-08 23:54:53 UTC
(In reply to Jodi Biddle from comment #8)
> Can someone please help me write the tech note for this bug? It's not clear
> whether or not the issue is in fact caused by the TAR file, or whether this
> is an SELinux issue as described in BZ #980042.

This is not a SELinux bug, the bug is caused exactly as reported in the Description above.

In short:

1) Log collector collect DB schema and data in TAR file using PG pg_dump utility
2) pg_dump adds redundant DROP staements for all objects 
3) When restore is run on the TAR it generates error on those DROP statements
4) We had in this fix to open the TAR and do some sed magic to fix its content
5) The restore utility was modified to do this change all together in its code

Comment 11 errata-xmlrpc 2013-07-16 13:43:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1048.html