Alright, found out he had started the df/dss logical dump long before I thought. Before I could umount the device. Sorry for all my posting. I'll be quiet for awhile, promise :).
~ Daniel [EMAIL PROTECTED] writes: > 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 >
