Windows Server & Linux NAS Sparse File System
Backup Compatibility Issue
BackupAssist can be used to backup data from a Windows Server file system to a Linux NAS sparse file system (ext4 or XFS). Under certain conditions these types of backups can encounter an error.
The issue is known to occur on Windows Server 2012/R2, Windows 8 and intermittently on Windows Server 2008/R2.
When using BackupAssist to perform a backup from a Windows file system to a Linux (ext4 or XFS) file system, the backup can fail if the following conditions apply.
- The backup is running a system protection job to the Linux based NAS.
- The Linux NAS has sparse file allocation turned on.
These conditions can result in two possible error messages.
Error : The version does not support this version of the file format.
Error : Unable to backup volume to a sparse file system.
Many Linux-based NAS systems will present shared folders and iSCSI targets as an NTFS destination to the user, but this error can still occur if the underlying NAS file system is ext4 or XFS.
The following Knowledge Base article provides instructions of how configure your NAS to resolve this error when it occurs.
The following section provides background information on this known issue.
Linux and Windows Server file systems
Windows NTFS and Linux (ext4 or XFS) each handle the allocation of data blocks differently when preparing to write a file. This difference is transparent to the user, but limitations can be seen when trying to write a large file across a network from a Windows client application to a Linux-based NAS. When using the default Samba configuration, writing a large file from the Windows client can result in a timeout. BackupAssist would report this timeout as a backup failure.
Windows file system
Prior to writing a file, the Windows NTFS file system will allocate, at once, all blocks required for the file. This is an important difference when compared to the "sparse" file system behavior of Linux ext4 and XFS, which allocates blocks dynamically when the file is written.
Writing a large file across a network with Windows NTFS can take some time. Because of this, the SMB/SMB2 network protocol has implemented a strategy to avoid potential write request timeouts. The strategy involves the Windows client sending a sequence of 1 byte "extension" write requests to cover the extension needed on the open file. Each of the 1 byte write requests is used to pre-allocate the empty space for the file to be written. Individually, these one byte writes are unlikely to timeout and therefore permit a file to be written or extended to an arbitrary size, avoiding network timeout issues.
Linux file system
With Windows, the file system is forced to allocate storage blocks when a file is created or extended. The default behavior on Linux is to create a sparse file. A sparse file is a specific type of file which aims to use file system space more efficiently by using metadata to represent empty blocks. In the case of a sparse file, blocks are allocated and written dynamically as the actual data is written, rather than at the time the file is created.
When writing a file from Windows (NTFS) to Linux (ext4 or XFS), the Linux file system receives the sequence of 1 byte "extension" write requests, and performs the normal 1 byte "sparse" write at the required position in the file. When the sparse file is being created, the empty space (representing pre-allocated blocks) between each 1 byte "extension" write request is represented by metadata. If the file is large, the actual disk storage blocks are not committed until the file is written.
While the sparse file system is fast and efficient when writing under normal small file conditions, a problem occurs when it begins writing actual data that comprises a large file. For example, when backing up a VHD to the Linux file system, and the physical blocks have to be allocated. At this point only the "extension" bytes and the metadata representing the pre-allocated empty space have been written to the sparse file. The actual data has not been written and the physical blocks have not yet been allocated (most likely only one block has been allocated, depending on files size and block size).
When it comes time to write the actual data, because these blocks are not allocated in order the actual writes can be time consuming, resulting in network timeouts and therefore failure of the backup job. To improve the write efficiency and overcome the problems encountered when writing a large file, the file system allocates an "extent" on the Linux file system. The "extent" is a contiguous area of storage which is reserved for the file being written.
When the 'strict allocate= yes' option is configured in the Samba configuration file (smb.conf) the Linux file system makes use of the extent-based allocation. Setting the 'strict allocate' to 'yes' configures Samba to stop creating sparse files. This forces the allocation of the requested blocks prior to the file being written and avoids potential network timeouts when writing large files.