SUMMARY: ufsdump and December 30?

From: Seth Rothenberg (
Date: Mon Jan 03 2000 - 08:45:01 CST

Thanks to "Neill, Mark" <>
>>>Yes, it's a Y2K issue :) . There is a patch for ufsdump out there on

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 <>
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" <> 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.


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:01 CDT