Can't copy big DB files using "copy", "robocopy" or even "eseutil"

I am having a problem copying large DB files (~100GB) in an automated script I am trying to write for a Windows Server. I have tried using "copy", "robocopy", and even "eseutil".

My script is running on a Windows 2008 Server (destination of the file) and is pulling from a Windows 2003 Server (source of the file).

I have already tried changing the IRPStackSize registry setting, as well as both of the ones in the HKLM/SYSTEM/CurrentControlSet/Control/SessionManager/MemoryManagement hive. This was all done on t开发者_如何学Che 2008 server and rebooted with no effect. Does anyone have a good workaround?

Copy and Robocopy both give me this:

Not enough server storage is available to process this command.

Eseutil.exe gives me this:

H:\TempSQLBackups>eseutil /y \\SRC_SERVER\SQL_BACKUPS\BIG_DB.BAK /d H:\TempSQLBackups\BIG_DB.bak

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.01
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating COPY FILE mode...
     Source File: \\SRC_SERVER\SQL_BACKUPS\BIG_DB.BAK
Destination File: H:\TempSQLBackups\BIG_DB.bak

                      Copy Progress (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ........FAILURE: ReadFile: The specified network name is no longer available.


Operation terminated unsuccessfully after 11336.16 seconds.


H:\TempSQLBackups>

I figured out how to fix this!

Use a LINUX machine to samba mount the source and destination directories/drives and copy them via the network. Personally, I use rsync since it will recreate the directory structure and only copy files that aren't there or are different. Thus, you can stop and/or restart at anytime without losing your progress.

I can't believe we're still paying Microsoft for this trash of an OS. I had similar problems and there seems to be no fix other than this one. Its a little slow but not nearly as slow as doing on natively since it will fail EVERY TIME.

At one point I thought robocopy would surely do it using the /IPG:xx option (InterPacketGap in milliseconds). Nope. It just PROLONGS the stack overflow and remote console lockout. I thought, maybe, Microsoft got it right with this OS. So much for Win2K8 being solid. Ugh! Windoze is for workstations. For servers you need a server OS not tinkertoy code.

Use the XCOPY with the /J option to avoid network failures of large files. This will ONLY works in 2008 R2 and Windows 7 though. This solved my timeout issue.

Please check.

Have you tried to copy the files with the old fasion way of drag and drop?

I would do this once, to make sure its not your network failing. Make sure that works, and then try look at other solutions.

1) Make sure your destination drive, is NTFS and NOT Fat32.
2) Check when its failing to copy, is it always at the same point? ( IE if it always failing after 2gb )

Have you tried xcopy? It works better for large files and recursive copy. doc

Also, from my own experience working with network drives and command line is a pain and buggy. It is also a good idea to map the network drive and use drive letter such as z:\

xcopy /K /R /E /I /S /C /H /G /X /Y s:\*.* t:\

/K Copies attributes. Normal Xcopy will reset read-only attributes.

/R Overwrites read-only files.

/E Copies directories and subdirectories, including empty ones.

/I If destination does not exist and copying more than one file, assumes that destination must be a directory.

/S Copies directories and subdirectories except empty ones.

/C Continues copying even if errors occur.

/H Copies hidden and system files also.

/Y Suppresses prompting to confirm you want to overwrite an existing destination file.

/G Allows the copying of encrypted files to destination that does not support encryption.

/X Copies file audit settings (implies /O).

The format for the second part of eseutil should be:

/d\\server\folder\filename

Notice there is no space after the /d