[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-390
Subject:    Re: DR backup support.
From:       Alan Altmark <Alan_Altmark () us ! ibm ! com>
Date:       2015-04-29 19:48:01
Message-ID: OF9413B443.0BC491E3-ON85257E36.00502E95-85257E36.006CC492 () us ! ibm ! com
[Download RAW message or body]

On Wednesday, 04/29/2015 at 10:16 EDT, David Boyes <dboyes@sinenomine.net>
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
Alan_Altmark@us.ibm.com
IBM Endicott

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU 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/
[prev in list] [next in list] [prev in thread] [next in thread]