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