On 3/29/2011 11:11 PM, Richard Stovall wrote: > Don't hate me, don't kill me, don't blame me, and definitely don't quote > me, but... > > Restart your server. If it's only a problem on the SAN LUN, then your > boot volume should be OK.
That is what I(and my boss, and others on this list) think. I will do that. Tomorrow. Planning on getting to the office by 7. If the CHKDSK isn't finished by then, I will power down this server. Tell the SAN not to present the drive to this server (i.e., so this server doesn't see it at all). And then reboot this server. Since the drive doesn't exist to this server (anymore), it *should* just boot directly into Windows, normally. I hope ... :-) Means I'll have to recreate the SAN drive, and present it again. And then tell Windows to rescan and re-format the new drive, of course. If the backup problem was with the drive, hopefully, this will fix it. > I don't have any experience with Networker, but does the backup service > run on the same physical server we're talking about? No, the Networker server is a different machine. But this server is a client of that server. So the NW server initiates the job. There are services running on this machine, that communicate with the NW server. > > On Tue, Mar 29, 2011 at 10:59 PM, Mike Leone <[email protected] > <mailto:[email protected]>> wrote: > > On 3/29/2011 10:50 PM, Richard Stovall wrote: > > Who knows how long a chkdsk of a SAN (or any) volume might take? If > > someone tells you before it ends, and they're right, please ask > them if > > VCU will make it to the championship game next Monday. (I don't > want to > > know if they're going to win it all. I want to watch that much live.) > > Yeah, I figured as much. :-) > > > I'm a bit late to this party. Did you ever state what the conditions > > were that led to running chkdsk in the first place? > > My backup program is EMC Networker, and it writes the backup to this > drive, and then clones to tape. The write to disk part has been failing. > EMC Tech Support suggested running CHKDSK on the target volume, to see > if the problem is a corrupt drive. > > So this volume is just a target for the backup software; it's not the > boot volume, nor has any programs installed to it. It's just storage of > the backup, so that if we need to restore, it's available from disk > immediately, rather than waiting for tapes. And a daily script deletes > the backups from previous days, so the drive doesn't fill up. > > We do this with a dozen other servers, including nodes in clusters. It's > just this one server that has started having problems in the last week. > > Backing up directly to tape works fine. So the problem seems to be with > the drive. > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > <mailto:[email protected]> > with the body: unsubscribe ntsysadmin > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > <mailto:[email protected]> > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
