[CentOS] CentOS 6 P2V alternatives?
Mark Haney
mark.haney at neonova.net
Fri Nov 3 17:02:49 UTC 2017
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
More information about the CentOS
mailing list