Video Screencast Help

Restore Error: can only be restored to an NTFS volume

Created: 23 Oct 2013 | 7 comments


I have backed up a file via a symbolic link from a storage device running FluidFS as the file system, this works fine, and was done on windows Server 2008 R2. However when I attempt to restore this file from tape on another system running windows Server 2003, back to the storage device running FluidFS I get the following error:

Restore test 1 -- The job failed with the following error: A file or directory was written in a format that is specific to NTFS running on Microsoft Windows 2000 or later, and can only be restored to an NTFS volume that is running on Microsoft Windows 2000 or later.The file or directory has been skipped.

Can anyone offer any solutions to this please?

Many thanks

Operating Systems:

Comments 7 CommentsJump to latest comment

CraigV's picture


Try restoring the data locally first and then copy onto the NAS.


Alternative ways to access Backup Exec Technical Support:

ridders's picture

I agree that your suggestion could be a solution, however in some instances the data to be restored would be larger than the storage capacity of the local machine.

CraigV's picture

Not all NAS arrays are supported by Backup Exec. Check the BE SCL for your version and see if your array is listed.

If you're simply restoring to the NAS and it runs iSCSI, why not carve out an iSCSI LUN/s from the NAS, present to the backup server and format with NTFS. Problem should then be resolved.


Alternative ways to access Backup Exec Technical Support:

ridders's picture

Unfortunately we're not in a position to re-architect the SAN, which is presented as user shares via Dell FS7500 NAS clustered head units with an iSCSI equalogic back end.

We have not identified an appropriate BE agent for the FS7500, and our data is static and read-only, so we have relied on "backup user shares" option when selecting jobs manually.

It would be great if we could use the API via powershell scripting to continue to back up user shares, but as far as we can tell, we can only select specific BE Agents via powershell scripting. As a workaround, we tested using the mklink command to create a symbolic link on the local BE server, but this has the side effect of meaning we cannot restore direct to the SAN, and means that future restores of long term archives would rely on the server at the time supporting this workaround.

Open to further suggestions - unless there's a way we've not identified to use powershell to select 'user shares' or in some other way specify a UNC path for backup, it appears that each job will have to be created with manual intervention?

pkh's picture

I don't think FluidFS is supported by BE.

Larry Fine's picture

Can the file be restored using the original Windows Server 2008 R2 that did the backup?  Maybe this is a Windows Server 2003 issue?

I see the FS7500 on the HCL for both disk/CIFS support and for NDMP support.

If you find this is a solution for the thread, please mark it as such.

ridders's picture

The file can be restored on the original server successfully. Unfortunately, the requirement is also to demonstrate restores on standalone DR server(s) which are Server 2003 based. NDMP has been ruled out because it can only be restored to an NDMP destination, ideally from the same manufacturer etc.

If backup selections are made manually, from the CIFS share on the FS7500, they can be restored anywhere, so the solution is working well in that respect.

The one remaining frustration is that with the knowledge we have so far, it doesn't seem possible to select user shares (ie CIFS from the FS7500) from the BE API, so we applied a workaround of using a mklink symbolic link on the BE server and redirecting to the UNC path of the CIFS share on the FS7500.

Unfortunately, this appears to confuse BE into believing it's backing up an NTFS file system (which is fair enough under the circumstances!) - the files are then backed up, but it appears that BE then considers them to have NTFS attributes (presumably compression, Alternate Data Streams etc) that can only be restored to an NTFS destination. This works fine if we apply the same workaround for the restore - which can only be applied on Server 2008. We've tried some 3rd party tools, but continue to get errors about NTFS attributes.

The neatest and least risk solution from our point of view would be to find a way to script selection of user shares (UNC paths on the FS7500) or in some way avoid the NTFS attributes being backed up - so that there's maximum flexibilty to restore data in a recovery environment, possibly years into the future on different equipment etc.

Keep looking at the manual, but still scratching our heads!