Hi,
Our recommendation is to backup to a local drive, and then "Copyto" to a network location. This is because the copyto option includes network resilience to retry the copy if there's a temporary loss of connection etc.
This sort of makes sense- you'd see an initial spike as the backup is done directly to the san (assuming you mean network communication to the san device?) and then the continual access following on until the end would be the file being copied.
This makes less sense to me- i'd assume the san usage to occur both with the initial backup and also the copy (assuming both the "local" and the "network" locations are actually on the san, just different sections of it)?
Our recommendation is to backup to a local drive, and then "Copyto" to a network location. This is because the copyto option includes network resilience to retry the copy if there's a temporary loss of connection etc.
| Quote: |
checked with SQL monitor the network utilization and found that 2nd option (backup to network and copy locally) has a spike in network utilization, 40% for a 10GB database, but it keeps using SAN communication for until the job ends. |
This sort of makes sense- you'd see an initial spike as the backup is done directly to the san (assuming you mean network communication to the san device?) and then the continual access following on until the end would be the file being copied.
| Quote: |
Now, when backing up to local path 1st then copy to network drive via UNC, the network utilization remains at 20% for the whole duration of the job. However, it is not until the end, than the iSCSI or SAN is used, I guess that for the verify step? |
This makes less sense to me- i'd assume the san usage to occur both with the initial backup and also the copy (assuming both the "local" and the "network" locations are actually on the san, just different sections of it)?