On Tue, Jan 24, 2017 at 1:49 PM, Doug Ingham <dou...@gmail.com> wrote:
> Hey guys, > Just giving this a bump in the hope that someone might be able to > advise... > > Hi all, >> One of our engines has had a DB failure* & it seems there was an >> unnoticed problem in its backup routine, meaning the last backup I've got >> is a couple of weeks old. >> Luckily, VDSM has kept the underlying VMs running without any >> interruptions, so my objective is to get the HE back online & get the hosts >> & VMs back under its control with minimal downtime. >> >> So, my questions are the following... >> >> 1. What problems can I expect to have with VMs added/modified since >> the last backup? >> >> Modified VMs will be reverted to the previous configuration; additional VMs should be seen as external VMs, then you could import. > >> 1. As it's only the DB that's been affected, can I skip redeploying >> the Engine & jump straight to restoring the DB & rerunning engine-setup? >> >> Yes, if the engine VM is fine, you could just import the previous backup and run engine-setup again. Please set the global maintenance mode for hosted-engine since engine-backup and engine-setup are going to bring down the engine. > >> 1. The original docs I read didn't mention that it's best to leave a >> host in maintenance mode before running the engine backup, so my plan is >> to >> install a new temporary host on a separate server, re-add the old hosts & >> then once everything's back up, remove the temporary host. Are there any >> faults in this plan? >> 2. When it comes to deleting the old HE VM, the docs point to a >> paywalled guide on redhat.com...? >> >> To add a bit more info to 4), I'm referring to the following... > > Note: If the Engine database is restored successfully, but the Engine >> virtual machine appears to be Down and cannot be migrated to another >> self-hosted engine host, you can enable a new Engine virtual machine and >> remove the dead Engine virtual machine from the environment by following >> the steps provided in https://access.redhat.com/solutions/1517683. >> > Source: http://www.ovirt.org/documentation/self-hosted/ > chap-Backing_up_and_Restoring_an_EL-Based_Self-Hosted_Environment/ > > If you are re-importing the backup in place on the initial engine VM you don't have to. The point is just if you are migrating to a new engine VM and so you have to remove the entry of the previous one to let the auto-import process trigger again. > CentOS 7 >> oVirt 4.0.4 >> Gluster 3.8 >> >> * Apparently a write somehow cleared fsync, despite not actually having >> been written to disk?! No idea how that happened... >> >> Many thanks, >> -- >> Doug >> > > Cheers, > -- > Doug > > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > >
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users