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.