What we had tried before was a physical dump, which took seconds. Tried
to figure out why, saw that MVS saw the dataset as empty and concluded
that was why.. I went back to our backup guy and tried the logical
instead of physical dump. Discovered a previous omission, we hadn't
catalogued the dataset to MVS and once we did the logical dump/restore
seemed fine for the most part. Did a logical dump, removed the "empty"
dataset in MVS, restore. Remounting the file system in linux resulted
in a "kernel: EXT2-fs warning: mounting unchecked fs, running e2fsck is
recommended" which I unfortunately didn't see immediately (after I had
made changes to the file system). When I did I umounted and ran an e2fsck:
Block bitmap differences: -80540 (through) -80847
Free blocks count wrong for group #2 (29294, counted=24634).
Free blocks count wrong (269403, counted=264743).
Free inodes count wrong (270654, counted=270655).
all fixed
I'm fairly sure i was umounted before the dump started. A tar -df
/path/to/tar_archive didn't yield any differences before the e2fsck. I
did do a fdasd to see the
-----------tracks----------
Device start end length Id System
/dev/dasdh1 2 50084 50083 1 Linux native
change to
-----------tracks----------
Device start end length Id System
2 50084 50083 unused
when the dataset was deleted in mvs. But that wouldn't have caused any
problems.
Also, it seems to me that the lack of catalogueing shouldn't have made a
difference for the physical dump. Unfortunately, backup guy's gone now.
I am so desperate to test some more and figure out what's going on
here, but can't.
Arrgh,
~ Daniel
[EMAIL PROTECTED] wrote:
>DF/DSS should work. You'll probably have to specify ALLEXCP and ALLDATA, or
>do a physical dump instead of a logical dump of the volume.
>
>Mark Post
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, April 18, 2002 10:51 AM
>To: [EMAIL PROTECTED]
>Subject: Re: Backup possibilities under the 2.2.x kernal
>
>
>[EMAIL PROTECTED] wrote:
>
>
>>above for file-level backups. Amanda is probably the best bet here as
>>well, along with using DFDSS to do full volume dumps periodically with
>>the Linux system down for consistency sake.
>>
>So DFDSS works fine? When our dasd guy tried it on a linux volume, the
>program would return with a condition code 0... but after seconds (not
>20 minutes or so). In MVS the dataset would show up, for example,
>LINUX.VOX6BC2.PART0001.NEW with all of its tracks allocated, but viewing
>the file would result in a message saying that the file was empty, which
>is why he thought DFDSS finished so quickly. So I resorted to OFFLINDR
>which works great, but if DFDSS will also work then he'd prefer to use that.
>
>Am I the only one who DFDSS didn't work for? I'm using a 2.4 kernel,
>btw, in an LPAR.
>
>~ Daniel
>
