Backup device

Hi all,
I tried to create the new backup device with UNC path on the remote server
\\remoteserver\share on the sql server. But, I got "can not verify the
path" message and I have no problem to access the share through the sql
server. I checked the share and file security on the share and file and they
are fine.
I can not verify why I can not create UNC backup device on this sql server.
(windows 2003 R2 SP2 and sql 2000)
Can anyone help?
Try using sp_addumpdevice directly. It might just be the GUI which try to "assist" you.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"John" <John@.discussions.microsoft.com> wrote in message
news:75486005-3FAB-499B-9C38-7C128149BFF9@.microsoft.com...
> Hi all,
> I tried to create the new backup device with UNC path on the remote server
> \\remoteserver\share on the sql server. But, I got "can not verify the
> path" message and I have no problem to access the share through the sql
> server. I checked the share and file security on the share and file and they
> are fine.
> I can not verify why I can not create UNC backup device on this sql server.
> (windows 2003 R2 SP2 and sql 2000)
> Can anyone help?
|||> I have no problem to access the share through the sql
> server.
How did you access the share through the SQL instance?
Linchi
"John" wrote:

> Hi all,
> I tried to create the new backup device with UNC path on the remote server
> \\remoteserver\share on the sql server. But, I got "can not verify the
> path" message and I have no problem to access the share through the sql
> server. I checked the share and file security on the share and file and they
> are fine.
> I can not verify why I can not create UNC backup device on this sql server.
> (windows 2003 R2 SP2 and sql 2000)
> Can anyone help?

Backup device

Hi all,
I tried to create the new backup device with UNC path on the remote server
\\remoteserver\share on the sql server. But, I got "can not verify the
path" message and I have no problem to access the share through the sql
server. I checked the share and file security on the share and file and they
are fine.
I can not verify why I can not create UNC backup device on this sql server.
(windows 2003 R2 SP2 and sql 2000)
Can anyone help?Try using sp_addumpdevice directly. It might just be the GUI which try to "assist" you.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"John" <John@.discussions.microsoft.com> wrote in message
news:75486005-3FAB-499B-9C38-7C128149BFF9@.microsoft.com...
> Hi all,
> I tried to create the new backup device with UNC path on the remote server
> \\remoteserver\share on the sql server. But, I got "can not verify the
> path" message and I have no problem to access the share through the sql
> server. I checked the share and file security on the share and file and they
> are fine.
> I can not verify why I can not create UNC backup device on this sql server.
> (windows 2003 R2 SP2 and sql 2000)
> Can anyone help?|||> I have no problem to access the share through the sql
> server.
How did you access the share through the SQL instance?
Linchi
"John" wrote:
> Hi all,
> I tried to create the new backup device with UNC path on the remote server
> \\remoteserver\share on the sql server. But, I got "can not verify the
> path" message and I have no problem to access the share through the sql
> server. I checked the share and file security on the share and file and they
> are fine.
> I can not verify why I can not create UNC backup device on this sql server.
> (windows 2003 R2 SP2 and sql 2000)
> Can anyone help?sql

BACKUP DATABASE

DECLARE @.Name varchar(50)
DECLARE @.Disk varchar(255)
SET @.Name='Databasename'
SET @.Disk = 'Drive:\path\' + @.Name +'.bak'
BACKUP DATABASE @.Name to DISK = @.Disk
BACKUP LOG @.Name
WITH
NO_LOG
DBCC SHRINKDATABASE (@.Name, TRUNCATEONLY)
I plan to run this sort of logic on a wly schedule. Does truncating the
log pose any problems? If so, how do I manage the log size.Wes
http://www.karaszi.com/sqlserver/info_dont_shrink.asp
"Wes" <Wes@.discussions.microsoft.com> wrote in message
news:374F9E8B-2BF5-46E1-BDD5-6AFA580F8849@.microsoft.com...
> DECLARE @.Name varchar(50)
> DECLARE @.Disk varchar(255)
> SET @.Name='Databasename'
> SET @.Disk = 'Drive:\path' + @.Name +'.bak'
> BACKUP DATABASE @.Name to DISK = @.Disk
> BACKUP LOG @.Name
> WITH
> NO_LOG
> DBCC SHRINKDATABASE (@.Name, TRUNCATEONLY)
> I plan to run this sort of logic on a wly schedule. Does truncating
> the
> log pose any problems? If so, how do I manage the log size.
>|||In addition to the link Uri posted you almost never want to do a truncate on
the log as it makes the log useless for a restore. Either backup the log on
a regular basis or set the recovery mode to simple.
Andrew J. Kelly SQL MVP
"Wes" <Wes@.discussions.microsoft.com> wrote in message
news:374F9E8B-2BF5-46E1-BDD5-6AFA580F8849@.microsoft.com...
> DECLARE @.Name varchar(50)
> DECLARE @.Disk varchar(255)
> SET @.Name='Databasename'
> SET @.Disk = 'Drive:\path' + @.Name +'.bak'
> BACKUP DATABASE @.Name to DISK = @.Disk
> BACKUP LOG @.Name
> WITH
> NO_LOG
> DBCC SHRINKDATABASE (@.Name, TRUNCATEONLY)
> I plan to run this sort of logic on a wly schedule. Does truncating
> the
> log pose any problems? If so, how do I manage the log size.
>

Backup /Restore options

I'm trying to decide what path to take in implementing Backup & Restore
processes in my VB6/MSDE application.
Either (a) create and execute Maintenance Plans or (b) use the BACKUP /
RESTORE / DBSHRINK commands in the program.
Can anybody explain to me the pros/cons of using one of the other?
TIA
Jim K
Hi Jim,
This depends upon the type of client in my opinion. A scheduled backup to a
file (for example) is great for small sites (followed by an operating system
backup of that file) but ONLY if they're going to check that the file
date/time keeps changing. If the SQL Agent stops (for example), they'll
blissfully keep backing up the same file and not actually have a backup
(apart from an old one). Maintenance plans have the same issues.
If that's a problem, I'd rather have an option in the program because you
are more likely to have those sorts of places carry out a "procedure" than
to look for something more subtle.
HTH,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Jim K" <krusej@.megsinet.net> wrote in message
news:OcvVvds5EHA.4072@.TK2MSFTNGP10.phx.gbl...
> I'm trying to decide what path to take in implementing Backup & Restore
> processes in my VB6/MSDE application.
> Either (a) create and execute Maintenance Plans or (b) use the BACKUP /
> RESTORE / DBSHRINK commands in the program.
> Can anybody explain to me the pros/cons of using one of the other?
> TIA
> Jim K
>

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