Problem with Network Copy / D2D Location

Compresses, encrypts, secures and monitors SQL Server backups.

Moderators: JonathanWatts, Chris Auckland, eddie davis, Colin Millerchip, Brian Harris, james.billings, RBA, petey

Problem with Network Copy / D2D Location

Postby LehighDBA » Mon Nov 19, 2012 4:24 pm

We are using SQL Backup 7.2.1.4

We are running a backup of a database to a local drive w/ network copy to a share exposed on an HP B6200 (http://h17007.www1.hp.com/inc/whatsnew/ ... 00-en.aspx). The network copy operation results in errors on the HP B6200 indicating a problem with copying the file. For instance – “[ssid1] : Too many files open file handles on NAS share Redgate:/OurDBServer_CustomerDatabase_FULL_20121113_070000.partial”. We have noted that the recommended maximum concurrent backup streams per share on the B6200 is 12.

In this case we would have expected to see one backup stream (file copy stream) open to the B6200. Is the Network Copy functionality actually breaking the backup file into segments to transfer to the remote location in order to achieve higher bandwidth? Have you seen behavior(s) like this before with copying to a location such as the B6200? If so – what possible solution(s) would you suggest other than manually staggering the backups?
LehighDBA
 
Posts: 17
Joined: Wed Jul 19, 2006 6:53 pm
Location: Allentown, PA, USA

Postby petey » Tue Nov 20, 2012 1:39 am

Is the Network Copy functionality actually breaking the backup file into segments to transfer to the remote location in order to achieve higher bandwidth?


No, SQL Backup does not split the backup file into multiple segments to copy the file.

Could you please try using the USESIMPLECOPY option in your backup command e.g.

Code: Select all
EXEC master..sqlbackup '-sql "BACKUP ... WITH USESIMPLECOPY ..."'


This causes SQL Backup to use the Windows API to copy the file, instead of its internal copy process. The difference is that if the copying fails midway, USESIMPLECOPY will restart from the beginning, while the internal copy process tries to restart from where it last failed. For the purpose of this test, we just want to know if your issue lies with the internal copy process.
Peter Yeoh
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 7
petey
 
Posts: 2230
Joined: Sun Apr 24, 2005 12:34 pm

Postby LehighDBA » Tue Nov 20, 2012 11:40 pm

We tried this - and had the same result. We did it again while watching with file monitor - I'd like to send you the output of that via email so you can see what appears to be happening.
LehighDBA
 
Posts: 17
Joined: Wed Jul 19, 2006 6:53 pm
Location: Allentown, PA, USA

Postby petey » Wed Nov 21, 2012 2:11 am

Sure, you can send me the output, at peter.yeoh@red-gate.com.
Peter Yeoh
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 7
petey
 
Posts: 2230
Joined: Sun Apr 24, 2005 12:34 pm


Return to SQL Backup 7

Who is online

Users browsing this forum: No registered users and 0 guests

cron