Thanks to "Neill, Mark" <Mark_Neill@CSX.com>
>>>Yes, it's a Y2K issue :) . There is a patch for ufsdump out there on
>>>SunSolve.
and to SunSolve for the following additional info late Thursday nite
>>>The /etc/dumpdates issue is not related to Y2K. It is related to a botched
>>>ufsdump, however. That same date, Dec 31 1969, is always seen. You won't be
>>>able to restore the most recent backup because of the date. The problem is
>>>usually seen on machines that also have vxdump on them (Veritas). I don't
>>>believe you have volume manager installed....just Disk Suite but nonetheless I
>>>believe this is a non-y2k issue. By the way, ufsdump on live filesystems is not
>>>recommended and not supported.
Thanks also to
Casper Dik who wrote...
>>>I've seen other reports about corrupted dumpdates
>>>(wild dates far into 2000) on x86 systems; we've not been able
>>>to reproduce this yet.
Yash Khemani <yash@khemani.com>
who suggested
>>>perhaps your date command is out of date? i saw this happen with gnu date
>>>some time back. is that the one in the path? if so, update to the latest
>>>sh-utils distrib from gnu. -yash
>>> "Seth Rothenberg" <SROTHENB@montefiore.org> 12/30/99 09:34AM >>>
Sun Managers,
I was wondering if anyone had this experience....
Our nightly backup is simply a script that does
ufsdump 0ucf /dev/rmt/0n xxx
for each file system we want backed up.
Operators then run a script that checks
/etc/dumpdates to make sure all dates match.
(Don't use this method, it is error-prone :-)
The last file system to be backed up
appeared to be backed up correctly, at
Thu Dec 30 01:16:18 1999, but /etc/dumpdates reports
Wed, Dec 31, 1969, 19:00
Is this a Y2K issue :-)
BTW, none of the other 9 file systems had problems,
and we followed up by backing up our second server
with no problems.
I'll try backing up again in a little while.
Thanks
Seth
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:01 CDT