Feature Overview: This feature has arose due to recent engine database corruptions where users did not have any database backup. The goal here is to cause users to do backup and review their backup options and thus reduce engine downtime on engine corruptions cases. Raising awareness to the necessity of backups and providing simple options using existing tools or recommending using more advanced solutions. This is the most pressing matter at hand Scope of this Specification: In scope: - Ensuring users follow best practice. - Enhancing that best practice as necessary. - Backup of engine database remote\local. - Backup of essential configuration files. Out of scope: - Creating a VM backup solution. - automatic backup options. User Characteristics: - Small scale deployments that don’t have a backup solution. - Backup of simpler usage cases. - User that don’t have external database management. Assumptions: - Engine-backup already provides part of the needed functionality. - We need to support cases where remote DB is used. - Raising awareness of user to backups will cause increase usage of backup. Constraints: - Engine must not have downtime for backup if possible. - Sufficient disk storage can be provided by user. - DWH\Reports also need to be optionally backed up and would require more disk space. - I\O and network performance best practices may be limited and cause issues. - Detailed documentation is critical to allow users to make the right choices. - We do not want to support complex backups since it is out of the oVirt scope. Dependencies: In order to allow external backup for other providers, we need to provide the backup tool as the start point of backup process. Performance: - The backup process should not cause failures in connections to hosts or storage and should not cause failure of tasks (even if performance is affected). Stress testing should be done to define minimal requirements to backup over the network and this should be added to best practices. - Backup process should have a low priority in the system (low nice). - Lower footprint should be a priority over fast completion. - Restore time should also be a priority in default backup formats and options. Capacity: - The backup should not start if disk size is not sufficient for it’s completion. - Two backup instances may not run at the same time.
*** Bug 1169965 has been marked as a duplicate of this bug. ***
*** Bug 1058522 has been marked as a duplicate of this bug. ***
Yaniv, we never discussed this subject specifically, or even engine-backup in general, for cases where dwh and/or reports are on their own machines. Also our current (3.5) solution for that is less than perfect, and was barely, if at all, tested/documented/etc. Probably worth another bug. For the current bug, I assume that all its dependencies should treat the engine machine only. dwh/reports backups are not monitored/alerted upon/etc. if done separately. Another question (should probably be done in bug 1188124 but anyway) is what should we report, if at all, if engine-backup finished successfully, but scope was not 'all' (but one of 'files', 'db', 'dwhdb', 'reportsdb').
(In reply to Yedidyah Bar David from comment #3) > Yaniv, we never discussed this subject specifically, or even engine-backup > in general, for cases where dwh and/or reports are on their own machines. > > Also our current (3.5) solution for that is less than perfect, and was > barely, if at all, tested/documented/etc. > > Probably worth another bug. > > For the current bug, I assume that all its dependencies should treat the > engine machine only. dwh/reports backups are not monitored/alerted upon/etc. > if done separately. Yes, standalone dwh\reports backups should not be monitored. > > Another question (should probably be done in bug 1188124 but anyway) is what > should we report, if at all, if engine-backup finished successfully, but > scope was not 'all' (but one of 'files', 'db', 'dwhdb', 'reportsdb'). The generated success event should list what was done or not done. For example: "Engine partial backup completed successfully (Done: database, files. Excluded: data warehouse, reports)"
(In reply to Yaniv Dary from comment #4) > (In reply to Yedidyah Bar David from comment #3) > > The generated success event should list what was done or not done. > For example: > "Engine partial backup completed successfully (Done: database, files. > Excluded: data warehouse, reports)" That's easy to do for me, but do we expect the engine to parse this? "Note, $user, that you didn't backup the db in the last 7 days, although you did backup the files last night"
(In reply to Yedidyah Bar David from comment #5) > (In reply to Yaniv Dary from comment #4) > > (In reply to Yedidyah Bar David from comment #3) > > > > The generated success event should list what was done or not done. > > For example: > > "Engine partial backup completed successfully (Done: database, files. > > Excluded: data warehouse, reports)" > > That's easy to do for me, but do we expect the engine to parse this? > > "Note, $user, that you didn't backup the db in the last 7 days, although you > did backup the files last night" No, engine should only notify user on engine not being backed up, so if you backup report\dwh, but not engine, do not update the backup date.
(In reply to Yaniv Dary from comment #6) > (In reply to Yedidyah Bar David from comment #5) > > That's easy to do for me, but do we expect the engine to parse this? > > > > "Note, $user, that you didn't backup the db in the last 7 days, although you > > did backup the files last night" > > No, engine should only notify user on engine not being backed up, so if you > backup report\dwh, but not engine, do not update the backup date. What about engine db vs files? Both are required for a successful restore, although files change less often.
(In reply to Yedidyah Bar David from comment #7) > (In reply to Yaniv Dary from comment #6) > > (In reply to Yedidyah Bar David from comment #5) > > > That's easy to do for me, but do we expect the engine to parse this? > > > > > > "Note, $user, that you didn't backup the db in the last 7 days, although you > > > did backup the files last night" > > > > No, engine should only notify user on engine not being backed up, so if you > > backup report\dwh, but not engine, do not update the backup date. > > What about engine db vs files? Both are required for a successful restore, > although files change less often. not sure why we separate this, can we merge this to one option?
(In reply to Yaniv Dary from comment #8) > (In reply to Yedidyah Bar David from comment #7) > > What about engine db vs files? Both are required for a successful restore, > > although files change less often. > > not sure why we separate this, can we merge this to one option? files are common. In the past it was difficult to separate them, because some dwh/reports stuff was in /etc/ovirt-engine. It might be easier today, I can check that. Other than that, some users probably backup their files using other means, so would not want to do this twice. That's probably not a big deal, because we try to backup only files that are really needed, which does not take much space.
All dependant items verified.
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one.