Bug 1589100

Summary:	After restore from engine-backup data inconsistency are not handled well in engine.
Product:	[oVirt] ovirt-engine	Reporter:	Roman Hodain <rhodain>
Component:	Backup-Restore.Engine	Assignee:	Tal Nisan <tnisan>
Status:	CLOSED DUPLICATE	QA Contact:	Guilherme Santos <gdeolive>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.2.3.5	CC:	bugs, eshenitz, frolland, gdeolive, rhodain
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-08-23 10:51:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Roman Hodain 2018-06-08 12:06:51 UTC

Description of problem:
The restore procedure restores the entire engine DB. Even if the engine would be backed up every day there still will be some inconsistency between the DB and the actual storage. The restore process should provide a way to get rid of these inconsistencies or engine should be able to sync up.

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

How reproducible:
100%

Steps to Reproduce:
1. Take the backup
2. Create a VM snapshot
3. Restore from backup 

Actual results:
The VM will be missing the snapshot bu the storage will contain it. This will cause failure of the VM if it is restarted.

Expected results:
Engine or the tool should deal with this issue. It is currently not possible to deal with this issue without a deep knowledge of the product.

Comment 1 Yedidyah Bar David 2018-06-10 05:57:52 UTC

(In reply to Roman Hodain from comment #0)
> Description of problem:
> The restore procedure restores the entire engine DB. Even if the engine
> would be backed up every day there still will be some inconsistency between
> the DB and the actual storage. The restore process should provide a way to
> get rid of these inconsistencies or engine should be able to sync up.

The restore _procedure_? That's a doc bug.

The restore _tool_? Do you expect it to go over all the storage and sync? I do not think so. I think you want a restore to be quick, and the engine to handle mismatches on the go.

Please explain exactly what change you want in the tool, or close this bug. Thanks. See also bug 1218674.

> 
> Version-Release number of selected component (if applicable):
> 4.2
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. Take the backup
> 2. Create a VM snapshot
> 3. Restore from backup 
> 
> Actual results:
> The VM will be missing the snapshot bu the storage will contain it. This
> will cause failure of the VM if it is restarted.

I suggest to open a bug specifically about this flow and attach all relevant logs.

Comment 2 Roman Hodain 2018-10-04 09:22:31 UTC

My apologies for the long delay.

I do not really care where this will be handled. If it will be on the restore tool side or the engine side. That is up to you.

Let's take one simple issue that cannot be handled via documentation and manual modification.

1) We take a backup in the morning.
2) Then we remove one snapshot from a VM
3) Then we do DB restore due to DB corruption.
4) We see the snapshot again
5) We try to remove the snapshot and the operation failed as the volume is already gone.

This is an unrecoverable situation for the customer. So due to DB corruption, the VM has to be recreated from scratch.

This should not happen. The RHV should recover. Automatically or providing tooling for that.

Comment 4 Michal Skrivanek 2021-08-20 08:27:44 UTC

This bug/RFE is more than 2 years old and it didn't get enough attention so far, and is now flagged as pending close. 
Please review if it is still relevant and provide additional details/justification/patches if you believe it should get more attention for the next oVirt release.

Comment 5 Eyal Shenitzky 2021-08-23 10:51:17 UTC


*** This bug has been marked as a duplicate of bug 1991122 ***