Re: Backing up zLinux
3590s come in SCSI and channel-attached varieties -- they can be one or the other but not both. There is a physically different controller card installed on the drive to differentiate the two variations. If you configure the drive as SCSI, then the traditional IBM operating systems can't use it. If you configure the drive as channel-attached, TSM on Linux can't use it. Brilliant thinking, isn't it? IMHO, if you're intending to use TSM on Linux, get some AIT3 or LTO drives and FCP attach them, or use the ones that your distributed guys already have. They're higher capacity, and a LOT cheaper. From: Linux on 390 Port on behalf of Spann, Elizebeth (Betsie) Sent: Fri 10/27/2006 5:31 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backing up zLinux The TSM Administrator's Reference has a DEFINE DEVCLASS command for 3590 IBM devices. Betsie -- 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: Backing up zLinux
On Friday, 10/27/2006 at 09:48 ZE2, Carsten Otte <[EMAIL PROTECTED]> wrote: > Yea I guess so, but not by intention. The wording was not meant to > imply "simple" or "bad". I just intended to state, that due to caching > the consistent view of the data that Linux has is not permanently > reflected on disk. And that is causes trouble when backing up from > outside that guest. This is true of all operating systems. It is, in general, a Bad Idea to take a backup from the "outside" of a running operating system that is not actively helping you. In z/OS, the extents of a dataset may span multiple volumes. Only the catalog knows for sure. If z/OS is in the process of moving a dataset when you come by and copy the volumes, you will end up with junk. Or with DDR you start copying a volume, say. You have the time-of-test-to-time-of-use problem in disguise. The volume can change while you're copying. The *dataset* you're copying can change. Cache is just one example of the issues surrounding the general problem of data integrity. Alan Altmark z/VM Development 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
Re: Backing up zLinux
The TSM Administrator's Reference has a DEFINE DEVCLASS command for 3590 IBM devices. Betsie -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, October 26, 2006 10:29 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backing up zLinux > Is anyone using IBM TSM with 3490 or 3590 tape drives? > Betsie On z/OS and VM, sure. The Linux version doesn't have any concept of channel-attached drives, and the TSM people don't care to change that. We won't reopen the argument on whether this is a good thing or not. I don't need another trip to the hospital. -- 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 -- 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: Backing up zLinux
On 10/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi People We're running SLES 8 on 3 LPARs and SLES 9 on one.We're using FDR/ABR to do full volume dumps of the data. We just bring down the applications we're running (Domino) and unmount the volumes and back them up from z/OS on another LPAR. But this raises the question: How do we backup the operating system? Can we take a full volume dump while the system is running (but pretty much idle)? Is this a bad idea? Our operations staff would rather IPL once a month rather than once a week (which is what we'd like to do for disaster backups). Thanks! -- 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 We run something similar but completely automated one a week. 1) scripts to bring down zVM linux guest for zOS DF/DSS backup. 2) script to bring zVM linux guest after backup. 3) we use our company scheduler (uc4). We also run Netbackup to take backup of some file systems during the week. Oracle, same rman approach as most people. All the Oracle volumes are NOT df/dss backed up. The majority of our TBytes of data are here. -- 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: Backing up zLinux
Mark Post wrote: I think you just got yourself into trouble here. I would hardly characterize z/OS as having a "primitive" I/O stack or architecture. Lots of buffering and caching go on there, both in hardware and software. The _real_ difference is that z/OS, just like Linux or z/VM, _always_ has a consistent view of its own data. In a shared DASD environment, this is enforced via serialization techniques, either hardware reserve/release, or software such as GRS, MIM, etc. Without those, backing up one z/OS system from another one would run into similar (but perhaps not as severe) problems with inconsistent data winding up on tape. Yea I guess so, but not by intention. The wording was not meant to imply "simple" or "bad". I just intended to state, that due to caching the consistent view of the data that Linux has is not permanently reflected on disk. And that is causes trouble when backing up from outside that guest. Carsten -- 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: Backing up zLinux
On Thursday, 10/26/2006 at 01:28 AST, David Boyes <[EMAIL PROTECTED]> wrote: > We won't reopen the argument on whether this is a good thing or not. I > don't need another trip to the hospital. Oh, for the love of . Stop trying to drum up sympathy. It was an ACCIDENT, I tell you! An ACCIDENT! (We were only trying to scare you, but the vehicle swerved unexpectedly. Bad tires. Yes, that's it, bad tires.) -- The Ol' Chuckster -- 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: Backing up zLinux
> Is anyone using IBM TSM with 3490 or 3590 tape drives? > Betsie On z/OS and VM, sure. The Linux version doesn't have any concept of channel-attached drives, and the TSM people don't care to change that. We won't reopen the argument on whether this is a good thing or not. I don't need another trip to the hospital. -- 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: Backing up zLinux
>The > _real_ difference is that z/OS, just like Linux or z/VM, _always_ has a > consistent view of its own data. Key phrase: "it's *own* data." (emphasis mine) -- 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: Backing up zLinux
There is one big difference. Linux uses all available memory as a global buffer. Buffers in z/OS are more localized to the job or device. The Linux global buffering makes it difficult to impossible to find a point at which you can be sure that what is on disk is the latest consistent data. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Post, Mark K Sent: Thursday, October 26, 2006 9:43 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backing up zLinux I think you just got yourself into trouble here. I would hardly characterize z/OS as having a "primitive" I/O stack or architecture. Lots of buffering and caching go on there, both in hardware and software. The _real_ difference is that z/OS, just like Linux or z/VM, _always_ has a consistent view of its own data. In a shared DASD environment, this is enforced via serialization techniques, either hardware reserve/release, or software such as GRS, MIM, etc. Without those, backing up one z/OS system from another one would run into similar (but perhaps not as severe) problems with inconsistent data winding up on tape. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Carsten Otte Sent: Thursday, October 26, 2006 7:16 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backing up zLinux -snip- I know this is díferent with operating systems that have a more primitive IO stack like z/OS, which don't do caching and write behind. For Linux, do always use dm-snapshot or a backup client _inside_ the machine or mount read-only. -- 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: Backing up zLinux
Is anyone using IBM TSM with 3490 or 3590 tape drives? Betsie -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Post, Mark K Sent: Thursday, October 26, 2006 9:43 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backing up zLinux I think you just got yourself into trouble here. I would hardly characterize z/OS as having a "primitive" I/O stack or architecture. Lots of buffering and caching go on there, both in hardware and software. The _real_ difference is that z/OS, just like Linux or z/VM, _always_ has a consistent view of its own data. In a shared DASD environment, this is enforced via serialization techniques, either hardware reserve/release, or software such as GRS, MIM, etc. Without those, backing up one z/OS system from another one would run into similar (but perhaps not as severe) problems with inconsistent data winding up on tape. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Carsten Otte Sent: Thursday, October 26, 2006 7:16 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backing up zLinux -snip- I know this is díferent with operating systems that have a more primitive IO stack like z/OS, which don't do caching and write behind. For Linux, do always use dm-snapshot or a backup client _inside_ the machine or mount read-only. -- 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: Backing up zLinux
I think you just got yourself into trouble here. I would hardly characterize z/OS as having a "primitive" I/O stack or architecture. Lots of buffering and caching go on there, both in hardware and software. The _real_ difference is that z/OS, just like Linux or z/VM, _always_ has a consistent view of its own data. In a shared DASD environment, this is enforced via serialization techniques, either hardware reserve/release, or software such as GRS, MIM, etc. Without those, backing up one z/OS system from another one would run into similar (but perhaps not as severe) problems with inconsistent data winding up on tape. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Carsten Otte Sent: Thursday, October 26, 2006 7:16 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backing up zLinux -snip- I know this is díferent with operating systems that have a more primitive IO stack like z/OS, which don't do caching and write behind. For Linux, do always use dm-snapshot or a backup client _inside_ the machine or mount read-only. -- 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: Backing up zLinux
David Boyes wrote: Other applications, such as FTP server, NSF server, Samba server, print servers, I wouldn't think would care. You would lose what was put on them during the backup process (hence making the backups as short as possible is a good thing). See above. I'd rather engineer a solution that doesn't depend on exceptions. I would like to second David's point here. The whole story does not depend on what running is, and neither does it depend on the application. As long as you have a file system mounted read+write, you get inconsistent data when taking a snapshot from *outside* Linux. I know this is díferent with operating systems that have a more primitive IO stack like z/OS, which don't do caching and write behind. For Linux, do always use dm-snapshot or a backup client _inside_ the machine or mount read-only. cheers, Carsten -- Carsten Otte has stopped smoking: Ich habe in 5 Monate, 1 Tag und 18 Stunden schon 742,93 Euro gespart anstatt 3.095,57 Zigaretten zu kaufen. -- 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: Backing up zLinux
> Yes you can take backups when the OS is running. It depends on what > "running" is I don't like depending on exceptions. > In the case of flashcopy, when you IPL the copy, it is no different > then if the system crashed and you IPL'ed then. I like depending on recovering stuff even less. > Other applications, such as FTP server, NSF server, Samba server, print > servers, I wouldn't think would care. You would lose what was put on > them during the backup process (hence making the backups as short as > possible is a good thing). See above. I'd rather engineer a solution that doesn't depend on exceptions. > Do I recommend backing up active servers inflight? No. > Can you? Yes. Not reliably. > I don't recall that I've ever had a "copy" that couldn't IPL. You have been very, VERY lucky. -- 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: Backing up zLinux
Yes you can take backups when the OS is running. It depends on what "running" is If the backup is taken when the Linux system is fairly idle. It is also better the quicker the backup as in flashcopy. In other words, the less changes happening during the backup, the better. In the case of flashcopy, when you IPL the copy, it is no different then if the system crashed and you IPL'ed then. And then you have to consider what applications are running. If you take a DDR of an fairly active Oracle or DB2 database, forget about it. It's garbage. The log files will be out of sync with the actual data. But if you can suspend the database, you can take slower ddr type backups without problems. Other applications, such as FTP server, NSF server, Samba server, print servers, I wouldn't think would care. You would lose what was put on them during the backup process (hence making the backups as short as possible is a good thing). I do flashcopy active Linux servers all the time. In case of a problem, I normally flashcopy the server, bring up the copy, changing the IP address, and then debug what was going on, before I fix the production server. And, yes, active Oracle or DB2 servers, don't like it one bit. But inactive ones, the database recovery taken at startup, seems to fix everything. However, in saying that, I don't know what, if anything, was lost. I do know that the server comes up and the database is running, and all the tables are there and it looks like all the data is there. Don't get me wrong, in the Oracle and DB2 case, I do use their backup utilities to backup the data (a logical backup). Do I recommend backing up active servers inflight? No. Can you? Yes. I don't recall that I've ever had a "copy" that couldn't IPL. Linux seems to straighten its stuff out. It's the application that may use many dasd volumes, that is of the most concern. BTW, I'm an ext3 type guy. The filesystem you use will play a large part in what you can and cannot get away with. Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 10/25/2006 9:10 AM >>> > But this raises the question: How do we backup the operating system? Can > we take a full volume dump while the system is running (but pretty much > idle)? No. > Is this a bad idea? Very. You will not get a usable backup. -- 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: Backing up zLinux
> But this raises the question: How do we backup the operating system? Can > we take a full volume dump while the system is running (but pretty much > idle)? No. > Is this a bad idea? Very. You will not get a usable backup. We've beaten this topic pretty hard in the recent past; the list archives should have the full flogging of the topic. Summary is that you need a backup client running within the Linux environment in order to work around the caching that Linux does within the virtual machine. There are open source and commercial tools that do this. Any dumps performed from outside Linux will not be consistent and/or reliable. > Our operations staff would rather IPL once > a month rather than once a week (which is what we'd like to do for > disaster backups). The approach of having a client inside the Linux guests and doing the backups to an external server over the network avoids the need to shut down the system at all. -- 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: Backing up zLinux
FDR Upstream does a great job of backing up Domino, and z/Linux (we have done both, but our Domino is still on windows boxes so I can't claim experience in the combination). But AFAIK you should be able to reliably backup Domino and the OS with no outage to either. The "catch" (there is always a catch) is a complete Upstream only DR recovery takes some careful planning and detailed procedures since you have to get the filesystems in order prior to doing the restore. In our last couple of tests we have experimented with a hybrid recovery where we us the cold-monthly backups (FDR/ABR) and then use an Upstream recovery to "roll forward" and while there have been a couple of minor glitches (mainly procedural) that has worked quite well and saved quite a bit of time. jrw [EMAIL PROTECTED] Sent by: Linux on 390 Port 10/25/2006 07:47 AM Please respond to Linux on 390 Port To LINUX-390@VM.MARIST.EDU cc Subject [LINUX-390] Backing up zLinux Hi People We're running SLES 8 on 3 LPARs and SLES 9 on one.We're using FDR/ABR to do full volume dumps of the data. We just bring down the applications we're running (Domino) and unmount the volumes and back them up from z/OS on another LPAR. But this raises the question: How do we backup the operating system? Can we take a full volume dump while the system is running (but pretty much idle)? Is this a bad idea? Our operations staff would rather IPL once a month rather than once a week (which is what we'd like to do for disaster backups). Thanks! -- 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
Backing up zLinux
Hi People We're running SLES 8 on 3 LPARs and SLES 9 on one.We're using FDR/ABR to do full volume dumps of the data. We just bring down the applications we're running (Domino) and unmount the volumes and back them up from z/OS on another LPAR. But this raises the question: How do we backup the operating system? Can we take a full volume dump while the system is running (but pretty much idle)? Is this a bad idea? Our operations staff would rather IPL once a month rather than once a week (which is what we'd like to do for disaster backups). Thanks! -- 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
