Bug 1293748

Summary:	[RFE] Satellite 5.7: help customer make sure they have db backup before upgrade / help find backup by grepping history
Product:	Red Hat Satellite 5	Reporter:	Xixi <xdmoon>
Component:	Upgrades	Assignee:	Tomáš Kašpárek <tkasparek>
Status:	CLOSED CANTFIX	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	570	CC:	bkearney, dyordano, mmello, shughes, tlestach
Target Milestone:	---	Keywords:	FutureFeature, UserExperience
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-02-20 10:05:48 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:
Embargoed:
Bug Depends On:
Bug Blocks:	260381, 1127217

Description Xixi 2015-12-23 00:34:48 UTC

Description of problem:
Oftentimes customer doesn't know they actually have a db backup: it's common to have multiple administrators for one Satellite server and one doesn't know the others have made backups of database, so the answer "we don't have a backup to restore to" in case of botched upgrades is actually not accurate.  A simple history grep helps clear this up.  Can this be built into the upgrade process to make sure customer has an available db backup in case need to restore?   

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

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Tomas Lestach 2016-01-05 11:37:15 UTC

> Oftentimes customer doesn't know they actually have a db backup: it's common
> to have multiple administrators for one Satellite server and one doesn't
> know the others have made backups of database

DB backup is part of the upgrade instructions and shall be done as part of the RH Satellite upgrade. The upgrade process should be done by one admin and he simply cannot skip a step of the upgrade instructions. Upgrade is a sensitive process and all the documentation steps need to be followed.

Comment 2 Tomas Lestach 2016-01-05 11:43:28 UTC

The other problem of this RFE is, the backup of the DB is done via db-control in case of embedded DB. In case of external DB, it's up to the DBA to do the backup and no history search helps here.

Comment 3 Tomáš Kašpárek 2017-02-20 10:05:48 UTC

Hello,

there are so many variables which are unknown to Satellite - especially for Satellites with external database there's no way how we can determine that a backup was made.
E.g. backups may be created by a cron job, or via other way than just by running db-control or pg_dump_all, e.g. lvm snapshots so simple grepping history for a 'db-control backup' won't do the job because of sheer amount of unknown variables in customer infrastructure.

Therefore I am closing this bug as CANTFIX.