*** DP 8.15 *** Backup failed for a volume mounted on media server

  • KM02688359
  • 22-Dec-2016
  • 22-Dec-2016

Archived Content: This information is no longer maintained and is provided "as is" for your convenience.


Problem: File System backup of Offline Stub Files from NFS mounted volume onto a Linux Disk Agent fails with 81:78 // [5] Input/output error. Solution: Perform backup via CIFS mounted volumes on Windows Disk Agents with file attributes marked offline at OS level for stub/offline files with OB2FSEBACKUPALL=0 set inside omnirc file.


Environment Details:

DP 8.15, Linux

Netapp filer in 5 locations connected to Centera via FMA appliance.

Setup is used for archiving files from Netapp filer. The Netapp filer is configured for archiving.

Flie System Backup of these Netapp filers is taken by mounting their volumes on Media Server as NFS mounts


Volume X from Netapp filer is mounted on media server

During backup, following error is reported:

/nfs_backup/hostname/X/abcd.pdf Cannot read 48128 bytes at offset 0: ([5] Input/output error).

When the volume is mounted via NFS and one tries to access the file referenced by stub, then it is not possible, however, if the volume is mounted via CIFS, stub file can be accessed.


All files reported with such a behaviour were stub files.

What is a Stub File:

When a file is archived from Netapp filer then it leaves a pointer on the filer for future reference. This pointer is called a stub.

From Support Matrix, following is documented:

Backup agents (Disk Agents) is supported on:

• additional UNIX platforms via NFS (on UNIX systems)
• additional platforms via shared disks (CIFS /SMB 1, 2, or 3 on Windows systems)

--> Above implies that NFS mounted volumes are support ONLY on *UX platforms.

Perform backup via CIFS mounted volumes on Windows Disk Agents to skip files attributes mared offline at OS level for such stub files with OB2FSEBACKUPALL=0, which is also default setting inside omnirc file.

Regarding Performance issue via CIFS, Windows client, from which DA is backing up network share, is not same as MA agent. This implies that data is transferred twice via network.
First time from storage to DA client via CIFS share. Second time from DA client to MA client. This explains the performance issue.