views:

787

answers:

2

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 the 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>
A: 

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 )

EKS
Yep, the destination is NTFS, and the failure is happening at different points in the file.
skb
And yes, drag and drop works, but since this is an automated script it won't work.
skb
A: 

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).

Yada
I don't see how any of those flags will prevent the failure from happening, but if the secret is xcopy I will try it.
skb
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:\
Yada