<div dir="ltr">Hi All, Simone,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 24 January 2017 at 10:11, Simone Tiraboschi <span dir="ltr"><<a href="mailto:stirabos@redhat.com" target="_blank">stirabos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>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="m_-6832179091052571113m_-7945937269453396598gmail-"><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></span><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></div></blockquote><div><br></div><div>Given VDSM kept the VMs up whilst the HE's been down, how will the running VMs that were present before & after the backup be affected?<br></div><div><br>Many of the VMs that were present during the last backup are now on different hosts, including the HE VM. Will that cause any issues?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><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="m_-6832179091052571113m_-7945937269453396598gmail-"><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></span><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></div></div></div></blockquote><div><br></div><div>As per above, do I still only need to import the previous backup even if the all of the VMs (including the HE VM) are now on different hosts to when the backup was made?<br><br><br></div><div>And as for the future, is it going to be necessary to always keep an unused host in the cluster to allow for emergency restores? I'm a bit concerned that if we ever utilised all of our hosts for running VMs, then we'd be completely stuck if the HE ever imploded again.<br><br></div><div>Cheers,<br></div></div>-- <br><div class="m_-6832179091052571113gmail_signature" data-smartmail="gmail_signature">Doug</div>
</div></div></div>