Highly Reliable Systems: Removable Disk Backup & Recovery

Monthly Archives: February 2018

Never use ISP’s DNS for a Windows machine in a Domain environment

February 2nd, 2018 by

Some customers have problems with a Netswap joining a domain, or with drive shares not coming back online after a drive swap.  We believe some of these problems may indicate Windows “Name resolution problems” which classically are either DNS or WINS related.  Both the Windows domain controller and the windows PC in a domain should have ALL  DNS records point to the Windows domain controller only.  Also if WINS is configured it should ONLY point to the domain controller.

There is a tendency to want to point DNS2 to the ISP’s DNS or to the local router, or to Google or another authoritative DNS server on the Internet.  We highly recommend you do not do this as it can produce strange name resolution problems, authentication issues, or disappearing shares.

In the article linked above Microsoft seems to say best practice is use native IP address then loopback like this:
DNS1:    (for example if your server network card is
DNS2:  (Just a way of pointing to yourself again – optional )

 Now for the next question. But can you or Should you point DNS2 to ISP as a “fallback” position?  We believe this is a no no.  Look about halfway down in this article for the txt below

Do not configure the DNS client settings on the domain controllers to point to your Internet Service Provider’s (ISP’s) DNS servers. If you configure the DNS client settings to point to your ISP’s DNS servers, the Netlogon service on the domain controllers does not register the correct records for the Active Directory directory service. With these records, other domain controllers and computers can find Active Directory-related information. The domain controller must register its records with its own DNS server.

To forward external DNS requests, add the ISP’s DNS servers as DNS forwarders in the DNS management console. If you do not configure forwarders, use the default root hints servers. In both cases, if you want the internal DNS server to forward to an Internet DNS server, you also must delete the root “.” (also known as “dot”) zone in the DNS management console in the Forward Lookup Zones folder.

Also see this article https://serverfault.com/questions/682819/best-practices-for-secondary-dns-in-case-of-a-single-active-directory   Note the last line



Finally if you’re not convinced refer to this article.  The first DNS error re-iterates never to point Windows machines to public DNS servers




Posted in Blog

2 Minute Delay to browse after a media swap

February 2nd, 2018 by

Case study:  User swapped stand alone drive on a High-Rely Netswap 400 (non-raid) and new media with same friendly name showed up after 10 seconds in HTML interface.

However, Windows file explorer indicated drive share was inaccessible.  After 2 minutes of waiting the user was able to browse the files on the new drive.

Please allow time for Windows master browser to update file list before using the drive.

Posted in Blog

Sparse Files – Problems writing 500GB and larger files with StorageCraft VEEAM and similar backup programs

February 2nd, 2018 by

Nature of problem:  When moving a hard drive from Netswap to Windows, large files appear to be corrupted under Windows.

Suggested Fix:  Install Netswap version 2.15e

If you remove a hard drive from High-Rely tray formatted and used with imaging software in a Netswap, then you install media (or raw drive) into a Windows environment (such as a High-Rely USB or esata device like a slimline), it can appear as if there is an incompatibility or corruption on the NTFS hard drive.  However, when reinstalling the drive back into the Netswap environment, the large files are OK and can be restored.

This is an apparent compatibility problems with large files (i.e >500GB).  For example files created by storagecraft or similar software as would occur when backing up a disk to a full to an image.   If the hard drive is NTFS formatted by any Netswap (version 2.15d and below) and you move the hard drive from a High-Rely tray to a stand alone USB or sata port on a Windows machine it appears as if large files are corrupt.  The file shows up in explorer as only being 32KB in size on disk.  The file will not restore and if you attempt to do anything with the file (rename, copy  etc). Windows will give an error.

Please leave Sparse files OFF for compatibility with large files between Windows and Netswap environments.

By default versions 2.15d and before stored files as sparse files and those files when large became highly fragmented, leading to the apparent compatibility problem.  Version 2.15e corrects this problem by both storing files as standard file (not sparse) and also updated the NTFS driver to properly handle sparse files.  See graphic under Disk properties.   If you don’t need sparse files leave the new feature turned off.  You also have the option of switching from the default NTFS driver to the NTFS-3G driver if you have further compatibility or other issues.   For best performance and support you should leave the NTFS-3G option unchecked unless you have reason to believe there are issues with the High-Rely native NTFS driver.

If you are concerned about compatibility of large files created with versions prior to 2.15e you may wish to proactively re-create those files by doing a new full backup.  However, many customers may elect to take not action at this time because the files are not technically corrupt and will work as long as they are used or restored in the Netswap environment.  The only issue is when the drives are removed from the Netswap and installed directly in a windows machine (sata or usb port).  If the end user anticipates an emergency situation where restore may be done from a natively connected high-rely drive we advise recreating any files larger than about 500GB to be safe.

Posted in Blog

Using Netswap with Acronis – The Strict Allocate feature

February 2nd, 2018 by

If you experience difficulty backing up with Acronis, you may need to go to the “Strict Allocate” feature under Windows networking (Advanced, Global options) and type in “No”.    Save the settings to change.  Version 2.15b of the software Changed Windows networking default settings to set strict-allocate to ‘no’ to fix backup failures using Acronis backup.  This setting may be “yes” on other versions of the software so should be checked if you’re using Acronis or have backup failures with any other software.


If you’d like more explanation on this setting, which is intended to increase Linux Samba performance here is an excerpt from the Samba performance documentation:

Strict Allocate set to No

When a Windows client application sends a request to write one byte at position 500MB on a newly opened (empty) file, the SMB/SMB2 client redirector has to ensure that 500MB+1 bytes are really allocated on the target system. However, sending a simple SMBwriteX/SMB2_WRITE request with an offset of 500MB could easily cause a client timeout. An assumption built into the SMB/SMB2 protocol is that the target file system behaves like a Windows server, so the NTFS driver on the server would have to allocate 500MB worth of file system blocks in order to complete this request, which may take longer than the 30 seconds usually allowed for an SMB request.

What the Windows client redirector does in this case is to send a sequence of 1 byte requests, to cover the extension needed on the open file. In the reply to an NTCreateX/SMB2_CREATE call, the SMB server returns a value called the “allocation size”, which is equivalent to the file system block size on a UNIX/Linux style file system. The “allocation size” is more flexible than the underlying file system block size, as (at least for Samba) it can be specified on a per-share basis.

This allocation size is used by the client redirector to specify the space between each 1 byte write call used to pre-allocate the empty space when a file is being extended. For example, if the allocation size is set to 1MB (the default in Samba) then when extending a file by 500MB the client redirector will issue 500 intermediate 1-byte SMBwriteX/SMB2_WRITE requests before issuing the real write request (at 500MB+1 byte) to complete the application write request.

Each of these one byte writes is unlikely to time out, thus allowing SMB/SMB2 to deal with writes that extend a file to an arbitrary size (within the limits of the file system and the protocol) without having to worry about network time outs.

Making writes efficient on Linux  By default, when Samba receives these 1 byte “extension” write requests, it simply does a normal one-byte “sparse” write at the required position in the file. This is very fast, but only causes one file system block (the block “dirtied” by the one byte write) to be allocated. When the real data is finally written into the file, the blocks then have to be allocated for real on the file system. Because these blocks are not then allocated “in order” on the file system, as it were, these actual writes can be quite slow.

The most efficient way to allocate file system blocks when data is to be written into all of the file (for example, a streaming video write) is to allocate what is called an “extent” on the file system. The requested blocks are then laid out by the underlying file system (ext4 or XFS) in a very efficient way which causes the actual writes to be much faster than having to allocate them dynamically.

How does a Linux application (Samba) get access to this new extent-based allocation call ? Simple, it’s built into glibc on modern Linux distributions via the posix_fallocate() call. In the new patch that has gone into Samba 3.5.7 (and also all future versions of Samba), when the smb.conf parameter:

“strict allocate = yes”

is set on a share, whenever a file is extended by an SMBwriteX/SMB2_WRITE call, call Samba calls posix_fallocate() to ensure the file extends to at least the size given as the offset in the SMBwriteX/SMB2_WRITE request, then does the actual write. In tests done on an ext4 file system, changing to “strict allocate = yes” and using the posix_fallocate() call in this way increased the write performance of Samba by 2/3 on a NETGEAR ReadyNAS box as tested by the Intel NASPT test tool, available here: http://software.intel.com/en-us/articles/intel-nas-performance-toolkit/

The specific tests used to measure the performance increase were the “File Copy to NAS” and the “HD Video Record” tests.

Posted in Blog