On Wednesday, 04/29/2015 at 10:16 EDT, David Boyes <[email protected]> wrote:
> What we recommend is to set up a Linux backup tool like Amanda or Bacula (or > your fave commercial tool) in the guests to back up to a dedicated virtual > machine used only as a backup server. Do regular file-level backups to the > backup server machine from each guest, then shut down the backup server and do > image backups of the backup server using your regular VM backup tool. During > your regular maintenance windows, arrange to shut down the production Linux > guests, log them off, and do image backups of each Linux server periodically > using your VM backup tool. Please note that David's reference to a "VM backup tool" includes tools that are running on z/OS, too. There is no magic bullet. ANYTHING that is actively reading from the disks while something else is actively writing on them has a worthless backup. It will restore correctly, and will likely even run, but the data is inconsistent and therefore untrustworthy. Hardware-based continuous disk replication doesn't read from the disks the way hosts do. After initial synchronization, only updates are sent to the backup volumes and they are done such that all of the disks in the same consistency group are consistent with respect to each other at a given point in time. Is that Good Enough? Often, yes, since such replication gives you very little loss (often none, depending on what actually failed). But it's like you lost power to the CEC. You come back up in a FORCE-start situation. Did you lose anything? Maybe. SFS will roll back uncommitted workunits. CMS disks that were being updated likewise have one or more files rolled back since the DOP may not have been flopped due to one or more open files. And it also is often good enough because frankly there's nothing better. But, still, you want file-level backups in case you need to revert a file that has had multiple updates. If you want to use a software solution, then it MUST be capable of capturing I/Os like the hardware-based replication does in order to get you "good enough" copy. Now, that's z/VM itself. The same approach can be used with Linux, but you are still going to need to do forward recoveries to replay transaction logs, etc. to get back to the last known-good disk contents. There's a lot of old-school thinking needed, even with new-school technology. One of the best visuals I've seen is at http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.antg000/gr139.htm%23gr139 . It compares continuous replication with point-in-time backups. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 [email protected] IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
