<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 24, 2017 at 1:49 PM, Doug Ingham <span dir="ltr"><<a href="mailto:dougti@gmail.com" target="_blank">dougti@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hey guys,<br></div> Just giving this a bump in the hope that someone might be able to advise...<br></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hi all,<br></div> 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.<br>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.<br></div><br>So, my questions are the following...<br><ol><li>What problems can I expect to have with VMs added/modified since the last backup?</li></ol></div></blockquote></span></div></div></div></blockquote><div>Modified VMs will be reverted to the previous configuration; additional VMs should be seen as external VMs, then you could import.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><ol><li>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?</li></ol></div></blockquote></span></div></div></div></blockquote><div><br></div><div>Yes, if the engine VM is fine, you could just import the previous backup and run engine-setup again.</div><div>Please set the global maintenance mode for hosted-engine since engine-backup and engine-setup are going to bring down the engine.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><ol><li>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?</li><li>When it comes to deleting the old HE VM, the docs point to a paywalled guide on redhat.com...?<br></li></ol></div></blockquote></span><div> To add a bit more info to 4), I'm referring to the following...<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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
<a href="https://access.redhat.com/solutions/1517683" target="_blank">https://access.redhat.com/<wbr>solutions/1517683</a>.<br></blockquote>Source: <a href="http://www.ovirt.org/documentation/self-hosted/chap-Backing_up_and_Restoring_an_EL-Based_Self-Hosted_Environment/" target="_blank">http://www.ovirt.org/<wbr>documentation/self-hosted/<wbr>chap-Backing_up_and_Restoring_<wbr>an_EL-Based_Self-Hosted_<wbr>Environment/</a><br><br></div></div></div></div></blockquote><div><br></div><div>If you are re-importing the backup in place on the initial engine VM you don't have to.</div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>CentOS 7<br></div><div>oVirt 4.0.4<br></div><div>Gluster 3.8<br><br></div><div>* Apparently a write somehow cleared fsync, despite not actually having been written to disk?! No idea how that happened...<br><br></div><div>Many thanks,<span class="gmail-m_-4351421178922271323gmail-HOEnZb"><font color="#888888"><br></font></span></div><span class="gmail-m_-4351421178922271323gmail-HOEnZb"><font color="#888888"><div>-- <br><div class="gmail-m_-4351421178922271323gmail-m_-4460158654694414927gmail_signature">Doug</div>
</div></font></span></div></div></div>
</blockquote></span></div><br></div><div class="gmail_extra">Cheers,<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></div><span class="gmail-HOEnZb"><font color="#888888"><div class="gmail_extra">-- <br><div class="gmail-m_-4351421178922271323gmail_signature">Doug</div>
</div></font></span></div>
<br>______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
<br></blockquote></div><br></div></div>