Friday, February 10, 2012

Backing up to a UNC path versus a local drive doesn't act the same way

Hi
I have just noticed a difference in how BACKUP works when I back up to a
local drive versu when I do it to a UNC path.
When I run the backup to a local drive, I can see that the .bak file gets
created, but then stays a 0 Kb until the backup is finished. When it's
finished, the .bak file is then being updated.
If I then run the same backup to the same location, but specify the location
as e.g. '\\Myserver\D$\MyBackupFolder\MybackupFile.bak' it acts differently.
Now the file id being updated on the fly every 3-4 seconds. I also noticed
that the latter takes significantly longer to complete the backup.
I assume that there's a reason for this difference so does any of you know
this reason? I have tried to look around so see if I could find something
that describes this but with no luck. Not that it matters, but I'm just
curious...:-).
Regards
SteenHi
With UNC paths, backup up to the local machine, the traffic has to go to the
network re-director, down the TCP/IP stack, get turned around when it finds
the host, and go up the stack again. Totally expected.
File access on networks, compared to local disk access is very different at
API level.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Steen Persson" wrote:
> Hi
> I have just noticed a difference in how BACKUP works when I back up to a
> local drive versu when I do it to a UNC path.
> When I run the backup to a local drive, I can see that the .bak file gets
> created, but then stays a 0 Kb until the backup is finished. When it's
> finished, the .bak file is then being updated.
> If I then run the same backup to the same location, but specify the location
> as e.g. '\\Myserver\D$\MyBackupFolder\MybackupFile.bak' it acts differently.
> Now the file id being updated on the fly every 3-4 seconds. I also noticed
> that the latter takes significantly longer to complete the backup.
> I assume that there's a reason for this difference so does any of you know
> this reason? I have tried to look around so see if I could find something
> that describes this but with no luck. Not that it matters, but I'm just
> curious...:-).
> Regards
> Steen
>
>|||Mike Epprecht (SQL MVP) wrote:
> Hi
> With UNC paths, backup up to the local machine, the traffic has to go to the
> network re-director, down the TCP/IP stack, get turned around when it finds
> the host, and go up the stack again. Totally expected.
> File access on networks, compared to local disk access is very different at
> API level.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "Steen Persson" wrote:
>
>>Hi
>>I have just noticed a difference in how BACKUP works when I back up to a
>>local drive versu when I do it to a UNC path.
>>When I run the backup to a local drive, I can see that the .bak file gets
>>created, but then stays a 0 Kb until the backup is finished. When it's
>>finished, the .bak file is then being updated.
>>If I then run the same backup to the same location, but specify the location
>>as e.g. '\\Myserver\D$\MyBackupFolder\MybackupFile.bak' it acts differently.
>>Now the file id being updated on the fly every 3-4 seconds. I also noticed
>>that the latter takes significantly longer to complete the backup.
>>I assume that there's a reason for this difference so does any of you know
>>this reason? I have tried to look around so see if I could find something
>>that describes this but with no luck. Not that it matters, but I'm just
>>curious...:-).
>>Regards
>>Steen
>>
>>
Thanks for the input Mike.
I know that using a UNC path involves the network, and therefore it's
also understandable that it takes longer time to do the backup.
Do you know why the file updates differently with the two scenarios? I'd
assume that it's due to the differnet ways the file is being
addressed, but do you know the correct reason?
Regards
Steen

No comments:

Post a Comment