Problem with Network Copy / D2D Location
LehighDBA
Posts: 24
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?
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?
Comments
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.
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.
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8