I've told DPM to continue the backup, and it's still failing, and
there are no other jobs writing to tape.

DPM mounts the tape, writes a bit of data, then emits the error
message and sends the tape back to its slot in the robot.

I am now officially baffled.

I'm going to wait for this weekend, and see what the next iteration of
this job does.

Kurt

On Wed, Sep 16, 2015 at 11:41 AM, J Harris <[email protected]> wrote:
> Okay since you are taking stabs in the dark, I had an issue a long time ago 
> where I had two different backups going to the same tape.  One of the backups 
> "blocked" the other one from using the tape drive.  The fix was to stagger 
> the backups by 30 minutes, at least in my case.  I was not using DPM, long 
> before that came out is when this happened.  I have seen on an AS400 recently 
> that this can still occur but that is a different OS/technology.
>
> Jon
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> On Behalf Of Kurt Buff
> Sent: Tuesday, September 15, 2015 7:21 PM
> To: ntsysadm
> Subject: Re: [NTSysADM] DPM 2012 error on one job
>
> On Tue, Sep 15, 2015 at 2:25 PM, James Button <[email protected]> 
> wrote:
>> OK -  another stab in the dark
>
> Of course - that's what sysadmins do! :)
>
>> Any filenames too long for the filesystem and the API that is handling the 
>> files - as in the 250 (approx max) for normal windows 'stuff'
>> That one used to get me (ages ago) when files with long names  had been 
>> moved, and their foldernames made more user-understandable by changing them 
>> from the 11 chars (8.3) to something with the users full name and location.
>
> I don't think so. This is a fairly vanilla box, running a small set of 
> specialized apps (including an Access database and Optio print processing). 
> But it's worth a check.
>
>> Other possibility - access restrictions, or MFT corruption such that names 
>> of files returned by a 'directory' listing are not actually accessible.
>
> Access restrictions, no, but MFT corruption? That's something to investigate.
>
>> Both are reminiscent of dealing with wild piglets - well hidden and you'll 
>> have to get down and root around in the muck to find and deal with them.
>> And then you'll get attacked by their 'owners' for interfering with them!
>
> Well, I'm not too worried about upsetting anyone.
>
> And, if all else fails, we'll see what happens this coming weekend.
>
> Kurt
>
>
>
>
>


Reply via email to