Not all the customers understand the importance of the nightly backup of rhevm database and do not configure those. In any case of system corruption, if recent database backup is not present, it is quite impossible to restore the system. rhevm installer should recommend customers to configure nightly backups. Optimal way would be to configure the backup automatically, while the user would be able choosing the location of the back up file and the time to run the backup. However, it would be also acceptable, if the installer, after it is done running, would strongly recommend the user to configure the nightly back up, following this article, for example: https://access.redhat.com/solutions/797463 .
(In reply to Marina from comment #0) > Not all the customers understand the importance of the nightly backup of > rhevm database and do not configure those. Marina, I know you're doing this out of experience. However, we should give some credit to RHEV admins to be aware of common and practices. One thing we're trying not to do is 'nanny' the users. Yes, backups are important but the same goes for HA and other practices. If we'll need to print all of them it won't look good. Additionally, some may try unattended setup with an answer file, in which case users will not even see it. The same goes for RHEV appliance which is already installed. So I understand you mean well, but we should respect our users and provide them the best practices information as a part of product documentation. Please reconsider this request and re-open as needed with an explanation on the appliance and unattended installation.
I just had another case where customer's whole environment was down for 2 days! because they didn't have database backup. I asked the customer over the phone how would they like to have such a feature, and they said it would be awesome: having a setup suggesting automatic configuration of database back up. I am reopening this bug. I think it is a good feature to have. If we don't have resources to implement it now, we can set it for later. How to implement: - Ask the user during rhevm-setup, if interested in setting up automatic backup of the database. - Suggest default location for a daily backup. - Suggest default time to run the cron job - The cron job would only keep 1 day back of database saved.
One suggestion for this RFE. If regular ovirt engine pgdumps are will be configured by default, there should be an initial warning to ensure disk space is present to hold these pgdumps. Might be worth suggesting an external NFS share to hold pgdumps. It is also worth putting in a RHEV-M notification / alert for when disk space on the RHEV-M system is low. (whether due to increasing size of postgreSQL backend or space consumption due to pgdumps.
(In reply to Rob Washburn from comment #3) > It is also worth putting in a RHEV-M notification / alert for when disk > space on the RHEV-M system is low. (whether due to increasing size of > postgreSQL backend or space consumption due to pgdumps. Rob, I would suggest you go ahead and open a new RFE for this. Sounds like a great idea to me to cover the root case of the issue we dealt with this week.
please consider the following in addition 1) backups will be done with the engine-backup utility 2) engine-backup will be extended to record last nackup event in engine event log (audit_log table) 3) An alert will be shown in webadmin if engine was not backed up for X hours (where X is defined as a configuration value - default 24) 4) engine-notifier will be able to listen on such alert and send email to subscribers
Please explain how this will be covered by unattended installation and other setups such as rhev-appliance. This RFE will not be implemented for part of the cases as mentioned before. Also, what happens when the DB is installed remotely? As mentioned before this RFE is forcing RHEV installation to handle backups which is out of RHEV scope as many other administrative tasks which are managed by the system administrator. I still do not see this is a viable request.
Additional RFE, related to same problem: bz#1176694.
*** This bug has been marked as a duplicate of bug 1188119 ***
*** This bug has been marked as a duplicate of bug 1188147 ***