date:20080731

File level backup of a z/Linux guest from z/OS

2008-07-31 Thread Jan Vanbrabant

Hi,

I came across David Boyes' append (Wed, 14 Jul 2004 11:47:30 -0700)
where David mentions a paper by his hand on using DASDtape with Amanda and 
z/OS DFHSM.
http://www.mail-archive.com/linux-390@vm.marist.edu/msg24490.html

David, if you happen to read this, pls tell me where I can still find it.
Anyone of you, listeners, can let me know too, of course. ;-)

1°
David's append is 4 years old now.
4 years being an eternity in our IT world, and certainly in the zLinux world, 
is DASDtape with Amanda and z/OS DFHSM still a viable solution?
Have the insights about file level backup changed since then? Are there other 
solutions or approaches?

2° The z/OS perspective
I just checked the z/OS R9 DFHSM Storage administration manuel
http://publibz.boulder.ibm.com/epubs/pdf/dgt2s661.pdf
which still says:
Appendix C. Linux-z/OS DFSMShsm Dump or Restore HOW-TO(pag. 655-669)
pag.656 … In order for z/OS to process the Linux volumes, they must be 
formatted in the Compatible Disk Layout (CDL) using dasdfmt version 1.0 or 
later and partitioned using fdasd version 1.0 or later. … Volumes in the 
original format, Linux Disk Layout (LDL), are not compatible with the z/OS 
system and cannot be accessed and backed up by z/OS. …

So, from a z/OS perspective (HSM and/or DFDSS), we can dump the entire volume. 
If one needs to restore a mini-disk, one may do a restore using the TRACKS 
parameter. Of course, this means one needs to know the starting and ending 
cylinder of each mini-disk. But that is in the VM directory.

So, yes, this definitely works, but it's not highly automated.


3°
The VM pêrspective
I'm not very acquainted (anymore) with the VM environment. Has the VM scene 
evolved in this file_level_backup area since then?

4°
The ECKD-LUN perspective
Any papers, articles, experiences with going from ECKD mdisks towards FCP LUN's 
which can be backed up with TSM?
Performance figures available comparing a ECKD solution with a LUN solution?

Performance figures available comparing a z/OS solution with a non-z/OS 
solution?
Any stress testing done?

Regards,
Jan




--
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

Re: File level backup of a z/Linux guest from z/OS

2008-07-31 Thread David Boyes

I came across David Boyes' append (Wed, 14 Jul 2004 11:47:30 -0700)
where David mentions a paper by his hand on using DASDtape with Amanda
and z/OS DFHSM.
http://www.mail-archive.com/linux-390@vm.marist.edu/msg24490.html

David, if you happen to read this, pls tell me where I can still find it.
Anyone of you, listeners, can let me know too, of course. ;-)

http://www.sinenomine.net/sites/default/files/MainframeLinuxBackupsWithoutTape-20040126.pdf

Watch for word wrap in the URL, but it's there.

David's append is 4 years old now.
4 years being an eternity in our IT world, and certainly in the zLinux
world, is DASDtape with Amanda and z/OS DFHSM still a viable solution?
Have the insights about file level backup changed since then? Are there
other solutions or approaches?

The general idea is still the same -- to get a consistent backup without
shutting down the Linux guest, you need something inside the Linux guest, and
none of the tools outside a virtual machine (commercial OR open source)
understands the disk format within the Linux minidisks.

I would probably use Bacula (www.bacula.org) instead of Amanda these days, but
essentially, nothing has really changed.

3°
The VM pêrspective
I'm not very acquainted (anymore) with the VM environment. Has the VM
scene evolved in this file_level_backup area since then?

Not at all, unfortunately. The few vendors in this space just aren't doing
anything other than minimal maintenance to keep their products running with new
CP releases.

If you use the open source tools like Amanda or Bacula, then giving a tape
drive to the VM LPAR and sharing your tape robot is certainly a viable
approach, and would save the unutterably painful process of setting up a
hipersocket network between z/OS and the VM LPAR.

4°
The ECKD-LUN perspective
Any papers, articles, experiences with going from ECKD mdisks towards FCP
LUN's which can be backed up with TSM?
Performance figures available comparing a ECKD solution with a LUN
solution?

Snide remarks about TSM's general cluelessness in the mainframe space aside,
FCP LUNs are very nice for apps that demand large data areas ( a few mod 54s).
Performance has a lot to do with your hardware and how you configure the path
management, switches, etc, so it's hard to say.

In terms of backup, FCP LUNs in this scenario have all the good and bad points
they have on any other platform, so if you have this setup for other reasons in
your shop, it'll work just like it does on the other boxes, with roughly
similar performance.

Performance figures available comparing a z/OS solution with a non-z/OS
solution?
Any stress testing done?

Key points are to avoid having to send the backup data over a real network
(that seems to be the largest hurdle for file-level backup) and getting the
data onto offline storage.

If you can employ the in-box networks (vswitch, hipersocket, glan), that's a
much better solution than physical Ethernet. If you do a non-z/OS solution, you
will bottleneck on the transmission to the external backup server. Also plan to
have a dedicated network interface for that purpose if you value your
production traffic -- backups will swamp normal traffic easily.

In terms of the offline storage, there are lots of factors, but the z/OS tape
is usually a) paid for, and b) well managed. If you go off-z/OS, you have to
invent a management solution and buy pretty much all new hardware. That
hardware is generally cheap and fast, but the management is non-trivial, even
with TSM or another commercial product. Often the management capability of
DFSMS and the fact that you just don't have to worry about it once it's working
pays for the offset in speed/capacity.

Drop me a note off-list if you want to go into more detail.

-- db

--
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

Re: Adding a logical volume to a RedHat volume group

2008-07-31 Thread Bauer, Bobby (NIH/CIT) [E]

Thanks Mauro and Mark. No luck, went with the backups. I'll take this up
with RedHat

Bobby Bauer
Center for Information Technology
National Institutes of Health
Bethesda, MD 20892-5628
301-594-7474



-Original Message-
From: Mauro Souza [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 11:16 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Adding a logical volume to a RedHat volume group

You can take a look at /etc/lvm dir... There's a dir named backup and
another named archive, you could use those dirs.

So, let's restore it:
First of all, make a copy of the original /etc/lvm, just in case of
messing
things down
After that, bring the old configuration back to life using vgcfgrestore:
*vgcfgrestore -f /etc/lvm/backup/VolGroup00 VolGroup00*

Try to mount the VG, and see if it's all ok. If is, rejoice. If not,
well,
there's always a backup...

I agree with Mark... everything looks ok with your commands, looks like
a
bug. I always run a vgscan after extending a LVM, to update the metadata
cache, just in case, because a sysadmin don't seems to lose anything
being
paranoid.

Good luck, you'll need!

On Wed, Jul 30, 2008 at 11:34 PM, Mark Post [EMAIL PROTECTED] wrote:


 I don't think anyone would be able to give you a step-by-step set of
 instructions to fix it, since (in my experience) a lot of recovering
from
 things like this requires a lot of hmm, why don't we try... type
stuff,
 even when you think you know what you're doing.  About the only thing
I
 could suggest would be do an lvremove of the new LV, followed by a
pvremove
 of the new PV.


 Mark Post

 --
 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




--
Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.

--
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 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

Re: Hotplug agents

2008-07-31 Thread Neale Ferguson

Thanks. I added the class registration and the devices appeared.

Neale


On 7/31/08 1:06 AM, Christian Borntraeger [EMAIL PROTECTED] wrote:
 Yeah, right. I forgot. That was changed in 2006 or so. The devt was in struct
 class_device in older kernels.So you have to register the class device as
 well.

--
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

Re: File level backup of a z/Linux guest from z/OS

2008-07-31 Thread Romanowski, John (OFT)

Jan,
We've had good results using TSM's backup-archive client to backup/restore our 
Linux guests. Use it for ECKD and LUN-based guests. Our Linux guest's backups 
were simply added to the schedule of TSM backups of existing physical servers.  
We're fortunate to have a separate LAN dedicated to TSM backup/restore traffic.

Can't speak to performance comparisons with z/OS, but I've found being able to 
do nightly TSM incremental file level backups is far, far faster than taking 
image backups of a whole disk. 

 

This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments.  Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.


-Original Message-

 From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
 Jan Vanbrabant
 Sent: Thursday, July 31, 2008 7:00 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: File level backup of a z/Linux guest from z/OS
 
   ... snip 

 4°
 The ECKD-LUN perspective
 Any papers, articles, experiences with going from ECKD mdisks towards FCP
 LUN's which can be backed up with TSM?
 Performance figures available comparing a ECKD solution with a LUN
 solution?
 
 Performance figures available comparing a z/OS solution with a non-z/OS
 solution?
 Any stress testing done?
 
 Regards,
 Jan

--
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

VDISK-SWAP-SWAPGEN ???

2008-07-31 Thread Huegel, Thomas

I'm the VM guy not the LINUX guy, so be gentle.

I am trying to use VDISK for swap space for the first time and it doesn't seem 
to work.
These are the messages I get.


From SWAPGEN
 FBA SWAP DISK DEFINED AT VIRTUAL ADDRESS 151 (12498 4K PAGES OF SWAP SPACE)

During the LINUX boot:

 ACTIVATING SWAP-DEVICES IN /ETC/FSTAB...
  
 [1A..FAILED
  
 CHECKING ROOT FILE SYSTEM...FSCK 1.38 (30-JUN-2005)[/SBIN/FSCK.EXT3 (1) 
--

When LINUX finishes there is no active swap disk. 

Once LINUX is booted I can do swapon -a and it starts up. 


Any ideas?

Thanks
Tom

--
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

27 matches

Mail list logo