Post reply

Cann't take backup on Network Drive

  • April 29, 2008 at 12:49 am

    #808138

    Hi

    The details around what we did is as follows:

    Step 1 of a SQL Job is to create a map of the drive letter Q using:

    net use q: \\172.16.10.96\sfs p@ssword /user:jhb_sfs_xp\sfsjhb

    the above works in our environment - you may need to substitute your IP address and folder name.

    Step 2 of a SQL Job is to run the Package that we created.

    The package points to drive letter Q as the output on the local server

    Remember that when the Job executes - it is executed as the user who is setup under:

    SQL Server Agent - service on the server.

    The user who is setup for this server needs the relevant security to the server/folder etc

    The error you are getting is because the syntax of the NET USE - is not 100% - see above

    Let us know

    Thanks

    Kevi

  • April 29, 2008 at 12:54 am

    #808139

    Hello Kevin,

    In net use q: \\172.16.10.96\sfs p@ssword /user:jhb_sfs_xp\sfsjhb

    What is sfs, p@ssword, user:jhb_sfs_xp\sfsjhb

    my user name is rohit and password is rohit

    I'm not getting the syntax.

    Rohit

  • April 29, 2008 at 1:00 am

    #808140

    Sorry for the confusion, let me explain:

    net use q: \\172.16.10.96\sfs p@ssword /user:jhb_sfs_xp\sfsjhb

    sfs - this is the folder that has been shared - if you browse to \\172.16.10.96 - then you will see a folder called sfs - this is where our text file lives.

    p@ssword - this is the password (there is no need for a prefix to specify password)

    /user:jhb_sfs_xp\sfsjhb - this is the username - because the PC is not on the same domain you need to use the machines name and username as apposed to the usual domain name \ username

    I hope this helps clarify

    Thanks

    Kevin

  • April 29, 2008 at 5:35 am

    #808241

    Ok, you have stand alone servers (not in a domain).

    You have SQL logging in using the local administrator account.

    Is the administrator password on the file server (backup destination) the same as the administrator account on the SQL Server?

    If they don't match it won't work.

    If you can't change the passwords so they match, create a new local account on the SQL server, make it an administrator, set SQL to use it for its service account (make sure you do this for ALL SQL services that are running, expecially SQL Server agent) and restart SQL after changing the credentials.

    On the file server, create an account with identical username and password and give it permission to the backup destination share.

    If it still isn't working, log into your SQL server using the service account credentials to test connectivity to your file server.

  • April 30, 2008 at 3:47 am

    #808886

    Guys, guys, guys

    Everything posted here is a technical workaround to a problem, and the problem with workarounds is that they're inherently less robust. This is a routine for taking backups that we're talking about here, and that needs to be rock solid. Rewind a page or so to Steve's post, where he says, paraphrased, to take your backups to local disc and then copy elsewhere using standard OS processes (scheduled script, for instance). It's nice and easy, maximises your chances of getting a successful backup (even if you suffer a network glitch) and is inherently straightforward to both monitor and troubleshoot.

    Semper in excretia, suus solum profundum variat

  • April 30, 2008 at 5:24 am

    #808934

    Thanks Guys.....

    I followed the below steps and its working fine.

    1. I created two users with same name and p/w's on both the machines and added them to local administrators group

    2. Only SQL Server Agent service need to be run through that a/c.

    3. In the same job where I'm taking backup's I added three more steps first one to delete the destination backup file, second one to copy backup file directly to the backup server and last one to delete the backup file from database server.

    Rohit

  • May 2, 2008 at 2:04 am

    #809956

    Red Gate Software has a couple of tools to help you with copying your local files to a remote location. Offers full error logging, has email notification on failure, and is free.

    ftp://support.red-gate.com/Patches/SQL_Backup/CopyTool.zip

    ftp://support.red-gate.com/Patches/SQL_Backup/FTPTool.zip

    SQL BAK Explorer - read SQL Server backup file details without SQL Server.
    Supports backup files created with SQL Server 2005 up to SQL Server 2017.

  • November 22, 2008 at 1:22 pm

    #902083

    Folks, good news.

    I am able to take SQL Backup to a mapped network drive.

    I have my SQL Server and Backup server connected in the same domain.

    (1) SQL service starting account I defined it as

    This account : Domain Administrator Account

    (2) I have also added under Database > Users the Domain Administrator account.

    (3) Windows : I created a mapped drive (V:) from a shared folder from another backup server.

    (4) SQL Enterprise Manager : I added a backup device/File from this map drive.

    (4) SQL Enterprise Manager : I started the backup, it is able to backup the contents into the backup device creaed using the mapped drive.

    Hope it can help, Thanks

    Vish

  • November 24, 2008 at 1:28 am

    #902314

    OK, Vishacad.

    Now your only real problem is that the drive mapping only exists in that session. To get the drive mapped BEFORE anyone logs into a session, so that it's always available for the service, you might want to take a look at AutoExNT.

    Semper in excretia, suus solum profundum variat

  • November 24, 2008 at 11:29 pm

    #902926

    yeah thanks for your caution.

    we did away with a Auto Logon using Registry Key Winlogon.

    merci bkcp ami

    Vish

  • November 24, 2008 at 11:33 pm

    #902929

    one more thing folks, on the backup speed

    It used to take 8hrs to backup the DB size of 300GB to a local drive and + 6hrs for copying it to another backup server on the network.

    We did the direct ackup to a mapped drive on the another backup server on the network (on the same switch). It took only 5 hours. May be it had some effect from the Reindex I did on all the tables also.

    Thanks

    Vish

  • November 25, 2008 at 6:22 am

    #903070

    vishacad (11/24/2008)

    one more thing folks, on the backup speed

    It used to take 8hrs to backup the DB size of 300GB to a local drive and + 6hrs for copying it to another backup server on the network.

    We did the direct ackup to a mapped drive on the another backup server on the network (on the same switch). It took only 5 hours. May be it had some effect from the Reindex I did on all the tables also.

    Thanks

    Vish

    A reindex will not affect your backup times, unless you're running it during backup, in which case you'll experience a longer backup time (not sure why you'd want to do that in the first place). Also, for a local backup to take 8 hours and then 5 hours to a mapped drive, what are you local disk speeds? Any I/O issues with the local drives? I assume you're using the same backup software/routines? Are you certain the backup to the mapped drive is complete and usable? I would never guess you'd see a decrease in time of backup using a mapped drive, maybe about the same but not a reduction of 33% (more or less). I beleive there is something else causing the scenario you've described - IMO

    -- You can't be late until you show up.

  • November 26, 2008 at 7:39 am

    #903724

    Benjamin Lotter (11/26/2008)

    It probably has nothing to do with permissions and everything to do with the fact that you can't point a native SQL backup to a UNC path.

    I believe that to be totally false statement. I always take a backup to a UNC path if I'm doing a remote backup using native SQL. I do not use backup devices, a simple path statement in my backup command. Without proper write permissions, at a minimum, the backup will fail. Backing up to a remote path is not a recommended "best practice" as a blip on the wire can corrupt your backup and you may not know it until it's too late (like when trying to recover production!). I have done it from time to time myself, however, for a quick reload of a dev or test environment.

    -- You can't be late until you show up.

  • November 26, 2008 at 9:36 am

    #903884

    tosscrosby (11/26/2008)

    Benjamin Lotter (11/26/2008)

    It probably has nothing to do with permissions and everything to do with the fact that you can't point a native SQL backup to a UNC path.

    I believe that to be totally false statement. I always take a backup to a UNC path if I'm doing a remote backup using native SQL. ....

    To which version of SQL Server are you referring? I think we're talking about different versions here.

    Benjamin Lotter
    http://BenjaminLotter.info/[/url]
    http://www.LinkedIn.com/in/BenjaminLotter
    Delight thyself also in the LORD and He shall give thee the desires of thine heart.
    ~Psalm 37:4

  • November 26, 2008 at 9:44 am

    #903891

    Benjamin Lotter (11/26/2008)

    tosscrosby (11/26/2008)

    Benjamin Lotter (11/26/2008)

    It probably has nothing to do with permissions and everything to do with the fact that you can't point a native SQL backup to a UNC path.

    I believe that to be totally false statement. I always take a backup to a UNC path if I'm doing a remote backup using native SQL. ....

    To which version of SQL Server are you referring? I think we're talking about different versions here.

    Well, I could never do it on 7.0 but I can on 2000 sp4 and 2005 sp2 (current forum - 2005).

    Edit - IP works as well on SQL200. I have't tried 2005 yet, we only installed it two weeks ago, but I assume it does there as well.

    -- You can't be late until you show up.

Viewing 15 posts - 16 through 30 (of 38 total)

You must be logged in to reply to this topic. Login to reply