Description of problem: rhevm-dwh-setup creates uncompressed backups Version-Release number of selected component (if applicable): 3.1.1 How reproducible: 100% Steps to Reproduce: 1. Run rhevm-dwh-setup 2. Check the backup in /var/lib/ovirt-engine/backups/ Actual results: an uncompressed file which consumes a large amount of filesystem space Expected results: a compressed file Additional info: rhevm-report-setup creates the same backup.
Currently we do not have a backup DB step in the 3.1->3.2 flows (and further). Please advise on preferred solution for the 3.3: * Are we interested in backing up the DB on the upgrade? * Do we need to created the compressed backup file, or it is enough to create a simple backup and instruct the user to possibly compress it?
(In reply to Alex Lourie from comment #1) > Currently we do not have a backup DB step in the 3.1->3.2 flows (and > further). Why? Is it only for DWH or also for rhevm db? > > Please advise on preferred solution for the 3.3: > > * Are we interested in backing up the DB on the upgrade? We must, how otherwise roll-backs will be performed? > * Do we need to created the compressed backup file, or it is enough to > create a simple backup and instruct the user to possibly compress it? If possible compress this is what this RFE all about - maybe backup should even be done while streaming directly through gzip filter.
(In reply to Simon Grinberg from comment #2) > (In reply to Alex Lourie from comment #1) > > Currently we do not have a backup DB step in the 3.1->3.2 flows (and > > further). > > Why? Is it only for DWH or also for rhevm db? Only dwh due to a possible huge DB size that could prolong the setup/upgrade considerably. > > > > > Please advise on preferred solution for the 3.3: > > > > * Are we interested in backing up the DB on the upgrade? > > We must, how otherwise roll-backs will be performed? > > > * Do we need to created the compressed backup file, or it is enough to > > create a simple backup and instruct the user to possibly compress it? > > If possible compress this is what this RFE all about - maybe backup should > even be done while streaming directly through gzip filter. Sure, the question was actually about that - considering large possible DB sizes (20Gb was considered 'moderate' in this case), would we agree to backup during the upgrade? What if there's not enough space in a default backup location?
As per conversation today with Alex: - Upgrade should determine expected backup size - If this expected backup size is larger then the free space then stop and ask the user if to continue without backup. - If there is enough space stop and inform the user the upgrade utility is now going to back up the database, inform the size, warn that the backup may take a lot of time depending on the DB size and system performance. Allow the user again to continue without a backup. In both questions above warn that upgrade without a backup may lead to unusable DB in case of role back.
Yaniv, Please advise the following: 1. should the compression of the file is too gz ? 2. should this be tested when upgrading from rhevm-dwh-3.3.0-2.el6ev.noarch.rpm and above ?
@David 1. What is too gz? 2. You can test it with upgrading to the latest 3.3 build.
Verified on is14 (rhevm-dwh-3.3.0-9.el6ev.noarch.rpm): Existing DB was found on the system. The size of the detected DB is 53979 Mb, free space in the backup folder /var/lib/ovirt-engine/backups is 15410145 Mb. -rw-r--r-- 1 root root 909K Sep 16 17:44 ovirt-engine-history.backup.2013_09_16_17_44_16
This bug is currently attached to errata RHEA-2013:15116. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
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-2014-0036.html