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@xxxxxxxxxxx
www.neonova.net
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
