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.