[CentOS] CentOS 6 P2V alternatives?

Fri Nov 3 17:02:49 UTC 2017
Mark Haney <mark.haney at neonova.net>

On 11/03/2017 12:48 PM, Robert Nichols wrote:
> On 11/03/2017 09:02 AM, hw wrote:
>> Robert Nichols wrote:
>
>>> How would you recover if that server were suddenly destroyed, let's 
>>> say by a power supply failure that fried the motherboard and all the 
>>> disks? If you can't bring up a machine on new, bare iron starting 
>>> with nothing but your backups and a CD or USB stick with a recovery 
>>> tool, you need to seriously reconsider your backup strategy.
>>
>> That´s a very good point.
>>
>> What options are there to make complete and consistent backups of 
>> machines
>> and VMs while they are running?  Just shutting down a VM to make a 
>> backup
>> is troublesome because you sometimes need to run 'virsh shutdown xx' 
>> several
>> times for the VM to actually shut down, and I have VMs that do not 
>> shut down
>> no matter how often you try.  If you manage to shut down the VM, 
>> there is no
>> guarantee that it will actually restart when you try --- and that 
>> goes for
>> non-VMs as well.  Shutting them down manually frequently to make 
>> backups is
>> not an option, either.
>
> Every backup tool that can be run on a physical machine can also be 
> run in the VM. For databases that cannot be simply copied while they 
> are active, there should be a way to generate a snapshot or other 
> consistent representation that can be backed up and restored if 
> necessary, and any database that does not provide such a capability 
> should not be considered suitable for the task at hand. Long-running 
> jobs should always have checkpoints to allow them to be continued 
> should the machine crash. (I have such a job running right now. 
> Coincidentally, it's verifying the consistency of 3 years of backups 
> that I just reorganized.)
>
> There is no "one size fits all" answer. The needs of a transaction 
> processing system that can never, ever lose a transaction once it's 
> been acknowledged are radically different from those of a system that 
> can afford to lose an hours, or days, worth of work.
>

I'll toss my two cents worth in having dealt with a similar situation 
recently (well 2015, but close enough).  If this server is /that/ 
important, I'd really consider building a completely new virtual 
instance on the hypervisor of your choice.  Though, to be completely 
honest, Hyper-V is just awful in my testing. There are far more P2V 
options for VMWare, including it's own P2V software which I've not had 
particular trouble with in a half-decade, if you insist on a P2V migration.

If we're just talking backups, Veeam for Hyper-V  (and ESXi) works 
really well and you can bring up the backed up VM on the fly if you need 
to recover data from it, or for DR/BC.  I've never had a problem with it 
and, at my last position, had it set to run the backups on a remote 
cloud in case of catastrophic damage to the office.  Of course, there's 
no such thing as too many backups, so critical data on a server like you 
have was replicated to a warm/cold site, or part of a cluster for DBs to 
make sure data integrity was kept and uptime maximized.

-- 
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.haney at neonova.net
www.neonova.net