> Am 07.10.20 um 00:05 schrieb Nathan Stratton Treadway:
>
> $ grep 20201004123343 ../tapelist
> 20201004123343 vBE-full-001 reuse BLOCKSIZE:32 POOL:vtape STORAGE:vtape
> CONFIG:be-full
Okay, that looks correct as far as I can tell....
> > Also, what do you get when you grep log.20201004123343.0 for "srv /"?
> > (That should give you all the taper lines related to writing the
> > "missing" dump for srv / .)
>
> $ grep "svr / " log.20201004123343.0
> PART taper "ST:vtape" vBE-full-001 2 svr / 20000119 1/-1 0 [sec 43.408733
> bytes 13631488 kps 306.666403]
> DONE taper "ST:vtape" svr / 20000119000000 1 0 [sec 44.000000 bytes 13631488
> kps 302.545455 orig-kb 0]
Hmmm, the one thing that seems a little strange is the extra zeros at
the end of the datetimestamp string on the DONE line....
I don't know how well this situation of mixing dumps made in the
date-only datestamp era with vault-copies made in the datetimestamp era
has actually been tested... so if it were me that's probably what I'd
play with next.
That is, I would make a copy of the original log.20201004123343.0 file
into some other directory, then used a txt editor to edit that
particular DONE line to remove the "000000" at the end of the
datetimestamp field... and then run the "amadmin ... find" command again
to see if that edit allowed it to start finding the vaulted copies of the
dumps.
Let us know how it goes...
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
