So does the warning about using this kernel update on with systems that
have a certain VM PTF installed only apply to using the spin_retry
parameter?
Alan Altmark wrote:
On Friday, 07/21/2006 at 08:23 EST, Rich Smrcina [EMAIL PROTECTED]
wrote:
spin_retry Kernel parameter
With this update an
We are running both 31-bit and 64-bit SLES8 on a z9 EC as well as SLES9
64-bit.
We had to get new licenses for our new IFL's but we had gone from a z800
to a z9.
Mark is correct that Novell still charges the same price for a z9 as for
a z900- category 3.
You should contact Novell to see if you
SLES8 should have no problems running on a z9. I haven't seen Novell
update their pricing (yet) for the z9. It appears they intend on having
the same price for all the zArchitecture systems. If you have the same
number of IFLs as you do now, your licensing costs shouldn't change.
Mark Post
?? ? wrote:
Hi:
We are planning to upgrade our z900 to z9 BC. But we still have an old
system run on SLES8 (31 bits). Is there anyone had experience to run
SLES8
on z9 BC or z9-109 (z9 EC)? We tried to ask our IBM rep, but he said
there's
no official support on SLES8 running on z9 BC.
And do we
What we were told (insert obligatory grain of salt):
Future licenses (for SLES10 and onward) will be the same price
regardless of engine/machine size. Previous versions may require
upgrades to current licensing, but will permit running earlier releases
for customers with older (ie 31 bit)
Hi All
I have a problem installing SLES10 under Hercules ..
I use Hercules 3.02 and when I need to specify the partitioning and software
selection I get a message that say
No *catalog found at
http://x.x.x.x/xx/DVD1/http://x.x.x.x/autoyast/sles10-rc2/
and ERROR: No** proposal.
Same problem
I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that is
also accessed by ZOS. Backups are taken by ZOS using FDR full volume
copies on Saturday morning (low usage). When I restore a backup, it will
not boot. The backup and the restore have the same byte counts. Linux
support at
ARMONK, NY - 21 Jul 2006: IBM (NYSE: IBM) today announced the company's
mainframe and POWER-based virtualization technologies have achieved one of
the computer industry's most stringent security certifications,
illustrating IBM's virtualization leadership.
In the security certification -- known
Can you send the messages that appear at boot time?
Stahr, Lea wrote:
I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that is
also accessed by ZOS. Backups are taken by ZOS using FDR full volume
copies on Saturday morning (low usage). When I restore a backup, it will
not boot.
We use OFFLINDR which runs on the z/OS side of our box.
- Original Message -
From: Stahr, Lea [EMAIL PROTECTED]
To: LINUX-390@VM.MARIST.EDU
Sent: Monday, July 24, 2006 9:31 AM
Subject: Bad Linux backups
I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that is
also
We use DFDSS to dump CDL formatted disk at the volume level.
Rob Schwartz [EMAIL PROTECTED]
Sent by: Linux on 390 Port
LINUX-390@VM.MARIST.EDU
To
On Monday, 07/24/2006 at 08:31 EST, Stahr, Lea
[EMAIL PROTECTED] wrote:
I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that is
also accessed by ZOS. Backups are taken by ZOS using FDR full volume
copies on Saturday morning (low usage). When I restore a backup, it will
not
I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that
is
also accessed by ZOS. Backups are taken by ZOS using FDR full volume
copies on Saturday morning (low usage).
To quote Alan Altmark: Nobody listens to me. Sigh.
One more time: Unless your Linux systems *are completely
Hi,
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3) without any problem.
Linux will repair filesystems from journal after recovering your backups.
You need to be sure that there is no activity on the Linux machine, or you
might end with corrupted data.
On 7/24/06, David Boyes [EMAIL PROTECTED] wrote:
One more time: Unless your Linux systems *are completely down* at the
time of backup, full volume dumps from outside the Linux system are more
than likely to be useless.
Can you explain why is that ?
I never experimented such failure after
I shutdown my Linux system and perform a Zvm DDR volume backup. This is
a full image backup of every track on the pack.
[EMAIL PROTECTED] 07/24/06 9:02 AM
I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN
that
is
also accessed by ZOS. Backups are taken by ZOS using FDR full
This is more of a 'how do YOU do it ancillary question'...
Obviously to get a decent system backup from within Linux you should be in
single user mode, or even quiesced completely (if you're doing CDL volume
backups, for instance).
What are people doing to get a given image into single-user
I have this problem in the old days when using FDR backup VM DASDs when
Cylinder zero is not formatted... Most likely the problem is in FDR
I use VMBACKUP to backup all LINUX volumes.
Stahr, Lea
[EMAIL PROTECTED]
ternational.com
On Monday 24 July 2006 16:06, Dominic Coulombe wrote:
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3) without any problem.
Linux will repair filesystems from journal after recovering your backups.
No, that does not work, because the journal is backed
On 7/24/06, Dominic Coulombe [EMAIL PROTECTED] wrote:
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3) without any problem.
Stop dreaming. Not even in theory - at least not my theory.
Linux will repair filesystems from journal after recovering your
On Mon, Jul 24, 2006 at 04:42:10PM +0200, Christian Borntraeger wrote:
On Monday 24 July 2006 16:06, Dominic Coulombe wrote:
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3) without any problem.
Linux will repair filesystems from journal after
in *theory* you can do live backup of machines with journaled filesystems
(at least ext3) without any problem.
Rob van der Heij wrote:
Stop dreaming. Not even in theory - at least not my theory.
Well, that is what the device-mapper snapshot target is for:
a) make a snapshot, which is very
We have used DFDSS, DDR and PIPEDDR to backup VM volumes containing
Linux data. Inside the Linux systems, we use TSM for filelevel
restores.
Does Bacula support encryption of the data on tape?
/Tom Kern
/301-903-2211
From: David Boyes [EMAIL PROTECTED]
What is everyone using for Linux
For my SLES9 systems, I use 'SIGNAL SHUTDOWN FOR userx WITHIN 120' to
bring the servers down. For my older TurboLinux systems, I use SCIF to
enter a 'SHUTDOWN -H NOW' command at the server's virtual console. Once
all the Linus systems are down, I run the backups and use XAUTOLOG to
initiate each
On Monday, 07/24/2006 at 04:47 ZE2, Carsten Otte [EMAIL PROTECTED] wrote:
Well, that is what the device-mapper snapshot target is for:
a) make a snapshot, which is very fast because it does not actually
copy data
b) use dd to copy the snapshot to a backup dasd while writing to the
original
We used to have the same problem as well,
As many have stated the only safe way to do volume level recovery is to
ensure all systems are down when you take the backup.
Another potential issue though is that FDR defaults to wanting to read the
vtoc and we had issues with volumes that had been
On 7/24/06, Carsten Otte [EMAIL PROTECTED] wrote:
Well, that is what the device-mapper snapshot target is for:
a) make a snapshot, which is very fast because it does not actually
copy data
b) use dd to copy the snapshot to a backup dasd while writing to the
original disk
c) destroy the snapshot
On 7/24/06, Rob van der Heij [EMAIL PROTECTED] wrote:
Stop dreaming. Not even in theory - at least not my theory.
Hi,
I'm sorry, but we managed to do live backup of our systems without any
problem. We restored a lot of backup and all were recoverable without any
problem. Even when data
Alan Altmark wrote:
And the point here is that you are getting *Linux* to create a consistent
backup. You are not backing up from the outside. Once Linux has created
the backup copy and unmounted it, only then are you free to copy the
backup disk at your leisure from the outside. At that
Rob van der Heij wrote:
I have looked in the past at options with LVM to suspend writing dirty
pages to disk, signal something outside Linux to take the physical
backup, and tell LVM to resume writing to disk. We did not implement
it because the process appeared a bit risky.
Nice idea that
Dominic Coulombe wrote:
I'm sorry, but we managed to do live backup of our systems without any
problem. We restored a lot of backup and all were recoverable without any
problem. Even when data was stored on LVM volumes.
We stop our databases prior to do the backup, sync the filesystems, do
On 7/24/06, Dominic Coulombe [EMAIL PROTECTED] wrote:
I'm sorry, but we managed to do live backup of our systems without any
problem. We restored a lot of backup and all were recoverable without any
problem. Even when data was stored on LVM volumes.
You've been lucky. That sometimes
One more time: Unless your Linux systems *are completely down* at
the
time of backup, full volume dumps from outside the Linux system are
more
than likely to be useless.
Can you explain why is that ?
Linux performs in-memory caching to a much greater degree than most
operating systems to
On Monday, 07/24/2006 at 11:12 AST, Dominic Coulombe
[EMAIL PROTECTED] wrote:
I'm sorry, but we managed to do live backup of our systems without any
problem. We restored a lot of backup and all were recoverable without
any
problem. Even when data was stored on LVM volumes.
We stop our
On 7/24/06, Rob van der Heij [EMAIL PROTECTED] wrote:
You've been lucky. That sometimes happens.
It's hard to predict what damage occurs when the file system is
corrupt. I am not sure you would not even risk your database.
My apologies. Maybe I should not have abused your post to
We have used DFDSS, DDR and PIPEDDR to backup VM volumes containing
Linux data. Inside the Linux systems, we use TSM for filelevel
restores.
Does Bacula support encryption of the data on tape?
Recent versions of Bacula do (1.38.10 and higher) (using the crypto
support in OpenSSL, so can use
On 7/24/06, Rich Smrcina [EMAIL PROTECTED] wrote:
So does the warning about using this kernel update on with systems that
have a certain VM PTF installed only apply to using the spin_retry
parameter?
That VM63742 is about a problem with Diag308 that is revealed with
reboot of a Linux guest
No need to shut down any application. If a database has a file state
at any point in time that it cannot recover from you are in deep
problems anyway (think of power outage). Databases are supposed to be
transactional. That also applies the the general case application.
The snapshot is atomic
On Monday, 07/24/2006 at 05:16 ZE2, Carsten Otte [EMAIL PROTECTED] wrote:
No need to shut down any application. If a database has a file state
at any point in time that it cannot recover from you are in deep
problems anyway (think of power outage). Databases are supposed to be
transactional.
Indeed. Thanks for the clarification.
Rob van der Heij wrote:
On 7/24/06, Rich Smrcina [EMAIL PROTECTED] wrote:
So does the warning about using this kernel update on with systems that
have a certain VM PTF installed only apply to using the spin_retry
parameter?
That VM63742 is about a
David Boyes wrote:
One more time: Unless your Linux systems *are completely down* at
the
time of backup, full volume dumps from outside the Linux system are
more
than likely to be useless.
Can you explain why is that ?
Linux performs in-memory caching to a much greater degree than most
Hi all...
We have a SLES9 system that needs one package updated beyond what's on
the service pack CDs. I got the RPM file and went into
Yast/Software/Change source of installation and added a Local
directory entry to the directory where the RPM file lives. I said
Continue when it prompted me
Alan Altmark wrote:
If you *do* know how the application is implemented and fully understand
the relationships of all the files, then you can build customized backup
strategies.
You can just put all relevant files on a single dasd (for flashcopy)
or LVM volume (for dm-snapshot). Seems easy
Hi Lee,
You can update a single package by entering this command :
rpm -Fvh your-file.rpm
The F is for freshen, or upgrade if package is newer than the current and
do nothing if there is no such package installed on the system.
To update a bunch of packages, you can specify multiple package
It looks like you're specifying the installation server incorrectly.
The error message shows an http:// string in the middle of the directory
tree. When you specify the installation server, you don't want/need to
say http://ip.address, you just need to provide the IP address.
Mark Post
On Monday, 07/24/2006 at 06:29 ZE2, Carsten Otte [EMAIL PROTECTED] wrote:
It is just extra paranoia. If you have an application that does not
start up anymore after a power outage (or snapshot backuprestore
which is the same from the application perspective), it is plain
broken. I just remeber
True is, that on-disk data differs from data visible to the app due to
caching. But since the file system (in case of ext3 in journaling
mode) is consistent at all times, it does not affect the integrity of
a snapshot copy.
As others have described, just dumping the data actually physically
Comments: What we have down is;
1. MANUAL JOB- SHUTDOWN LINUX 4 z/VM server-AFT 7pm.
2. DDR specific volumes thru an automated exec process.
3. MANUAL JOB- STARTLINUX 4 z/VM server- AFT 7pm.
We are halting to shut down the Linux servers thru the
The Linux Web interface.
We then perform; DDR
So Bacula does NOT provide for the encryption of data on its own tapes
whether running on zSeries or x86? The encryption of off-site backup
tapes is a matter of discussion for all-platforms, not just our
mainframe.
/Tom Kern
/301-903-2211
From: David Boyes [EMAIL PROTECTED]
Does Bacula
On Jul 24, 2006, at 11:38 AM, Alan Altmark wrote:
So I'll admit that I'm obviously not getting it. If you would
summarize
the steps needed to allow a reliable, usable, uncoordinated live
backup of
Linux volumes, I for one would sincerely appreciate it.
Why is everyone so hung up on volume
Pam,
Does this data reside on a SnapShot- or FlashCopy-capable DASD
subsystem? If so, you can reduce your outage time to a couple of minutes per
image instead of an hour. I haven't been backing up our systems lately, but I
think I had it down to about two minutes -- most of which was
For my part, I do volume backups because it is pretty much all I *can*
do right now. I don't have a client for Veritas or some such, and I can't
control my tape robotics with Bacula. I am still considering other options,
and I hope to get a Veritas client license, but I'm open to
Well I'm kinda forced to do it that way here because nobody wants to commit the
time it would take to get folks comfortable with having NFS on z/OS,
so I could do that whole bacula disk-tape thing. Nor is there money for a TSM
thing. The whole bacula thing really appeals to me. I have the book.
If you build from the current sources available from www.bacula.org, you
can do this on any platform that supports OpenSSL.
What I said was that the precompiled RPMs distributed with RH/SuSE
probably are older than the Bacula release that provided this function.
Those are probably still at 1.36
On Jul 24, 2006, at 11:57 AM, Jon Brock wrote:
For my part, I do volume backups because it is pretty much all I
*can* do right now. I don't have a client for Veritas or some
such, and I can't control my tape robotics with Bacula. I am still
considering other options, and I hope to get
I don't have a client for Veritas or some such, and I
can't control my tape robotics with Bacula.
What robotics do you need support for? The tape mount widget Adam wrote
will support anything that has CMS support.
-- db
--
Why is everyone so hung up on volume backups?
It strikes me that file-level backups are generally a lot easier to
work with, and use less archival media.
Restore time in DR situations. Volume-level backups are a LOT faster to
restore, and you don't have to configure anything special -- you
For one thing, full-volume backups preserve partition information,
making recovery much simpler. If I had to recover a hundred Linux
systems, dig through the system documentation to figure out which
partitions were what size, and belonged to these particular file systems
or were LVM PVs (or md
On Jul 24, 2006, at 12:15 PM, Post, Mark K wrote:
For one thing, full-volume backups preserve partition information,
making recovery much simpler. If I had to recover a hundred Linux
systems, dig through the system documentation to figure out which
partitions were what size, and belonged to
Nice in theory, very, very hard to do in practice when supporting
multiple clients with differing needs.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Adam Thornton
Sent: Monday, July 24, 2006 3:27 PM
To: LINUX-390@VM.MARIST.EDU
Subject:
On 7/24/06, Adam Thornton [EMAIL PROTECTED] wrote:
It strikes me that file-level backups are generally a lot easier to
work with, and use less archival media.
File level backup is great for oops backup when you erased a few
files and want them back. I am not sure whether you ever tried to
Never mind my previous mail. You did. :-)
Regards,
Alan
Alan Altmark
Sr. Software Engineer
IBM z/VM Development
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with
These are standard image systems that I can clone from a master and have
in production in 2 hours. But what if its not standard? Then I have
customizations that are lost.
Lea Stahr
Sr. System Administrator
Linux/Unix Team
630-753-5445
[EMAIL PROTECTED]
-Original Message-
From: Linux on
On Jul 24, 2006, at 12:47 PM, Rob van der Heij wrote:
On 7/24/06, Adam Thornton [EMAIL PROTECTED] wrote:
It strikes me that file-level backups are generally a lot easier to
work with, and use less archival media.
File level backup is great for oops backup when you erased a few
files and
On 7/24/06, Stahr, Lea [EMAIL PROTECTED] wrote:
These are standard image systems that I can clone from a master and have
in production in 2 hours. But what if its not standard? Then I have
customizations that are lost.
Such an approach does require discipline to properly register what you
Such an approach does require discipline to properly register what you
have modified and to assure the copy of that customized file is held
somewhere.
Tripwire is a handy tool for this. Run it every night and have it
generate a list of changes in diff format. You can then turn that diff
into
On Jul 24, 2006, at 1:35 PM, David Boyes wrote:
Such an approach does require discipline to properly register what
you
have modified and to assure the copy of that customized file is held
somewhere.
Tripwire is a handy tool for this. Run it every night and have it
generate a list of changes
Our robotics are controlled by Storagetek's software on our z/OS system; we do
not have a VM version. As far as APIs go, I have no idea.
Jon
snip
What do you currently use to control your tape robotics?
We did a demo of how to use a client-server program to make Bacula
think it could drive
FWIW FDR's Upstream DR Recovery comes with a script you can use to
automate a good chunk of the due dillignce aspect of this. It's not a
panacea mind you but throw it in cron as shipped (unless running lvm then
you need to uncomment some stuff) and at least you know you have all of
the info you
On Fri, 21 Jul 2006, Carsten Otte wrote:
We do build 31bit every night, and that we do regression test as
described. Linux _runs_ on G5 and up. We _support_ GA distributions
from SuSE and RedHat.
This is good. And this is good to know.
Just keep building those 31-bit critters, Carsten.
--
Stahr, Lea wrote:
I run SuSE SLES 8 under ZVM 5.1 in an IFL. The DASD are in a SAN that is
also accessed by ZOS. Backups are taken by ZOS using FDR full volume
copies on Saturday morning (low usage). When I restore a backup, it will
not boot. The backup and the restore have the same byte counts.
If that's so, then the Yast message To make RPM packages located at the
specified location available in the packages selection, continue. is
REALLY misleading...
Lee
Paul Giordano wrote:
The packages on local disk is referring to a specific directory tree of
data as if the CD had been copied
James Melin wrote:
This is more of a 'how do YOU do it ancillary question'...
Obviously to get a decent system backup from within Linux you should be in
single user mode, or even quiesced completely (if you're doing CDL volume
backups, for instance).
What are people doing to get a given image
Post, Mark K wrote:
For one thing, full-volume backups preserve partition information,
making recovery much simpler. If I had to recover a hundred Linux
My backup script does this:
sfdisk /etc/disktab -d /dev/hda
I _could_ copy it separately to a separate repository of this info, and
I could
David Boyes wrote:
Why is everyone so hung up on volume backups?
It strikes me that file-level backups are generally a lot easier to
work with, and use less archival media.
Restore time in DR situations. Volume-level backups are a LOT faster to
restore, and you don't have to configure
Carsten Otte wrote:
As Alan said, it's a question of one system knowing what's happening on
the other system. There's no way that z/OS is going to be able to know
that the Linux system is safe (without some kind of automation on BOTH
systems to be able to signal same) so dumps taken from
Rob van der Heij wrote:
On 7/24/06, Adam Thornton [EMAIL PROTECTED] wrote:
It strikes me that file-level backups are generally a lot easier to
work with, and use less archival media.
File level backup is great for oops backup when you erased a few
files and want them back. I am not sure
It shouldn't be hard to create a tape (or something) that IPLs and
restores. Should it?
Sure -- you *could* create such an animal. On the other hand, there's a
perfectly good one shipped with VM -- the IPLable DDR utility. DDR also
handles z/OS, VSE, Linux, TPF, and pretty much any other stream
Carsten Otte wrote:
But Dominic, it has nothing to do with a journaled file system. The fact
that you stopped the application and sync'd the file system (equivalent to
unmounting it) is what makes it work, not the file system implementation.
Wrong. Due to caching, as correctly described by
Depending on the model of the library, there might be a Linux version of
the STK control software. All you need it to do is let you tell the
library to put volume A in drive B, and make drive B available to the VM
system. Bacula doesn't need more brains than that.
If you can't get the z/OS side
Dominic Coulombe wrote:
On 7/24/06, David Boyes [EMAIL PROTECTED] wrote:
One more time: Unless your Linux systems *are completely down* at the
time of backup, full volume dumps from outside the Linux system are more
than likely to be useless.
Can you explain why is that ?
To avoid the
My apologies, I misunderstood where
you were coming from. Take a look in /var/log/YaST2/y2log after you add
the directory, and see if it tells you whether it accepts the RPM package
headers. It also checks them when you Install or Remove Packages.
Paul Giordano
Technical Sales Specialist -
Dominic Coulombe wrote:
I'm sorry, but I don't get your point.
I don't mind losing data on the system filesystems as we are only
interested in the database stuff.
On 24-Jul-2006, at 19:19, John Summerfied wrote:
so you don't care that it doesn't actually work!
It might be that in your
83 matches
Mail list logo
