On Wed, Jul 27, 2016 at 5:38 PM, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: Theoretically you could run engine-backup on the current engine VM, redeploy from scratch on the new storage domain and before running engine setup, inject there the backup. Something like: http://www.ovirt.org/develop/developer-guide/engine/migrate-to-hosted-eng... Unfortunately we know that migrating from HE to HE is not as simple as from physical to HE: https://bugzilla.redhat.com/show_bug.cgi?id=1240466#c21 In general the issue is that the DB backup form the old hosted-engine VM contains a lot of references to the previous hosted-engine env and you cannot simply remove/edit them from the engine since they are lock so you have to manually remove them from the DB which is quite risky/error prone. Improving engine-backup to automatically filter hosted-engine references is an RFE for 4.1. In the mean time I'd suggest, if feasible, to redeploy a new hosted-engine env and reattach there your storage domains and your hosts. This will imply a downtime.

On Thu, Jul 28, 2016 at 10:59 AM, Alexis HAUSER <alexis.hauser(a)telecom-bretagne.eu&gt; wrote: The backup and restore procedure on the same env is well testes, the issue is simply if you need to restore on a different environment (it's basically a migration) cause you have to remove all the references to the old env. Postgres is transactional so if you do it in the proper way I don't see issue but stopping the ovirt-engine service will of course help. But the issue is not that you risk data corruption, the issue is that when you import a backup of the engine DB to a different env, that backup says the hosted-engine storage domain is still the old one since it was that in the previous env and so on and you can simply edit the hosted-engine strage domain location from the engine itself since we are preventing it.