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. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.
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
> -----Original Message----- > From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of Mark > Haney > Sent: den 3 november 2017 18:03 > To: centos at centos.org > Subject: Re: [CentOS] CentOS 6 P2V alternatives? > > > 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.While Hyper-V is not ideal, it's good enough for our purpose. We made a choice a few years back to either completely rehaul our vm infrastructure or just hand it over to central IT at our university. The later option won, mostly because of the cost. Since central IT uses Hyper-V, that's what we also use. Building a completely new vm and somehow restore from backup the important parts, is what I'm looking at now. Thanks for your feedback! -- //Sorin