AH HA! In this one particular case, the failure is on a copy of the file 
pds.exe:

* DISASTER_RECOVERY:\ System Writer - Get file attributes returned error 3 
for VSS file 
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6\windows\system32\cba\pds.exe
* DISASTER_RECOVERY:\ System Writer - Error saving file path 
C:\windows\system32\cba\pds.exe that is associated with Shadow Copy path 
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6\windows\system32\cba\pds.exe. 
The system cannot find the path specified. 

Turns out, this is a (sort of) known issue with this file, due to this 
being a 64bit OS ..

http://community.landesk.com/support/docs/DOC-9772 

Cause: The pds.exe is stored in C:\Windows\SysWOW64\cba\pds.exe instead of 
c:\windows\system32\cba\pds.exe on 64bit machines.
 
It is pretty much the same as having Program Files (for 64 bit programs) 
and Program Files (x86) (for 32 bit programs). It is designed to be 
invisible to the service, which is why it thinks it's in a different place 
than it really is. 

This is working how Windows intends for a 32 bit service to work.
 
Resolution: You can make a link to the "c:\Windows\SysWOW64\cba"
 
C:\Windows\System32>mklink /d cba c:\Windows\SysWOW64\cba

So the fix (HOPEFULLY!) is to make a symbolic link to that 64bit directory 
(that's the "/d" option on the "mklink" command).

We'll see how that works tonight. If that's the only file that it 
complains about being "missing", this should fix it. However, if it 
complains about missing .INF files (I've seen that, too, in backups of NW 
8.x client), then it's back to the drawing board ...

Fingers crossed!