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:
> 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.
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.
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.