1

I've got a server that runs a full ntbackup once a week. Every week, it will log about a dozen files with the following messages:

WARNING: Portions of "\OBJECTS\SERVER\STORAGE\DOCS101\SomeFile.000" cannot be read.  The backed up data is corrupt or incomplete.
This file will not restore correctly.
Warning: Unable to open "E:\OBJECTS\SERVER\STORAGE\DOCS101\SomeFile.001" - skipped. 
Reason: The system cannot find the file specified.

Warning: Unable to open "E:\OBJECTS\SERVER\STORAGE\DOCS101\SomeFile.002" - skipped. 
Reason: The system cannot find the file specified.

...

Warning: Unable to open "E:\OBJECTS\SERVER\STORAGE\DOCS101\SomeFile.012" - skipped. 
Reason: The system cannot find the file specified.

Could not access portions of directory E:\OBJECTS\SERVER\STORAGE\DOCS101.
You may not have permission to open the file, or the directory may be missing or damaged.
Please contact the owner or administrator.

The thing is, it's never the same files. It's always a different, seemingly entirely random group of consecutive files. And it's not new files either. I've seen documents that are from as far back as 2006 show up on this list. I've checked, and all of the files are in the paths shown in the log file, and I am able to view them without problems. Any idea why this would be happening?

EDIT: This has been an ongoing problem for almost three years now, and I'm totally stumped.

Joe M
  • 107
  • 1
  • 16
  • How much data are you backing up? – colealtdelete Feb 12 '13 at 21:11
  • Are they in use at the time of the backup? – HopelessN00b Feb 12 '13 at 21:12
  • 1
    Shadow copies enabled? Server patched and up to date (I know there were multiple VSS fixes over the years Are you backing up to disk or tape? – TheCleaner Feb 12 '13 at 21:29
  • @Cole it's about 22GB on the most recent backup. – Joe M Feb 25 '13 at 23:52
  • @HopelessN00b I don't think any of the files should be in use, as the backup is happening at night when no one is logged in. – Joe M Feb 25 '13 at 23:52
  • @TheCleaner It's Windows Server 2003 Standard on SP2. VSS isn't currently running, but it is set to automatic startup. Not sure if that's an issue. And this is a tape backup. – Joe M Feb 25 '13 at 23:53
  • "portions" sound bad. Did you chkdsk the volume recently? Also, are you indeed *using* shadow copies for backups (do you see messages indicating that a shadow copy could be created at the beginning of the backup log)? – the-wabbit Aug 23 '13 at 22:09

1 Answers1

1

Something else has those files locked. Do you have antivirus scan or is something indexing the file system (locally or over a share)? I assume chkdsk comes up clean?

The error is misleading, something has the files open. Try this right before the backup kicks off.

 net files > opensharedfiles.txt
 handle > handleList.txt

(handle.exe is a tool from sysinternals which you can download for here).

opensharedfiles.txt will show you is someone still has a file open remotely, handleList.txt will show you all handles on the machine, allowing you to locate which local process might have it open.

Shamelessly stolen from Fulgan@Arstechnica

TheFiddlerWins
  • 2,999
  • 1
  • 15
  • 22
  • This looked familiar, and I see on the server that I ran handle in April 2012 without anything that looked out of place, but I am going to see up a scheduled task for a batch file to call both of these before the backup starts tonight. I'll check in on it next week and see if there's anything in either file. Thanks. – Joe M Aug 23 '13 at 20:59
  • Well, I noticed that the backups have actually been skipping the entire E: drive for months. It looks like there was a conflict with the SQL backups, because moving the ntbackup to a different time seems to have resolved that issue. But, so far this week, backups have run without skipping anything, so I'm not sure if the original problem still exists. I'm going to check again later this week, but if I don't find anything else out by Friday, I'll go ahead and give you the bounty anyway, since I'd hate to see it go to waste. – Joe M Aug 28 '13 at 15:41
  • Glad you found the answer. I do think something had the files open, if these files are not involved in the SQL dump process you may be having IO take longer because your disk subsystem is busy. That should not cause ntbackup to fail outright but could cause this issue of other things (i.e. AV scanning) is holding on to files longer due to resource contention. – TheFiddlerWins Aug 28 '13 at 15:43
  • Well, so far so good, so I'm going to give you the bounty. But I'm going to leave this question open for now in case something comes up. – Joe M Aug 31 '13 at 02:01