May 28, 2009 at 9:41 am
hi all,
I'm trying to backup some databases to a drive on another server within the same domain, the job fails and there isn't enough information in the job history to give me an insight into what might be the problem.
any ideas?
------------------------------------------------------------------------
All it takes, is a step in the right direction, your feet will manage to find the way. I didn't say it'll be easy!!![font="Comic Sans MS"]:cool:[/font]
May 28, 2009 at 10:01 am
Can you provide with the information that you currently hold, some one might have experienced the same problem in earlier stages and might have a solution 🙂
May 28, 2009 at 10:16 am
here's the information from the job history log
Executed as user: VENUS\SYSTEM. ...on 9.00.3042.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 16:46:28 Progress: 2009-05-28 16:46:29.02 Source: {158D49E3-EA46-4982-B362-01193F14316A} Executing query "DECLARE @GUID UNIQUEIDENTIFIER EXECUTE msdb..sp".: 100% complete End Progress Progress: 2009-05-28 16:46:29.22 Source: Check Database Integrity Task Executing query "USE [ALPHA_WEB] ".: 50% complete End Progress Progress: 2009-05-28 16:47:01.60 Source: Check Database Integrity Task Executing query "DBCC CHECKDB WITH NO_INFOMSGS ".: 100% complete End Progress Error: 2009-05-28 16:47:01.71 Code: 0xC002F210 Source: Back Up Database Task Execute SQL Task Description: Executing the query "BACKUP DATABASE [ATLON12] TO DISK = N'\\Avionne\E\SQL_BKps\VENUS\Bkps\ATLON12_200905281647.bak' WITH NOFORMAT, NOINIT, NAME = N'ATLON12_2009052816... The package execution fa... The step failed.
------------------------------------------------------------------------
All it takes, is a step in the right direction, your feet will manage to find the way. I didn't say it'll be easy!!![font="Comic Sans MS"]:cool:[/font]
May 28, 2009 at 10:42 am
Here is my suggestion, do your backup to a local directory, then move or copy the file to the other server. From what you posted, I couldn't tell you what the problem was either. It could be a permissions issue, a network error, who knows. If you backup to a local directory first, you eliminate those potential errors from preventing you from getting a good backup.
May 28, 2009 at 10:53 am
You'd need to log from the plan, not the job. The job doesn't log enough.
The big thing with remote backups is that any hiccup in the network will fail it. And it will fail the day your hard drives fail, if Mr. Murphy has anything to do with it. Copy across the network will retry, the backup won't.
As Lynn suggested, back up locally and copy off.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
May 28, 2009 at 10:59 am
Agreed ..........
Never backup on network share ......
copy it locally and then take it to share or tape .
This is the best practice across all database engines ...be it Oracle ..
Abhay Chaudhary
Sr.DBA (MCITP/MCTS :SQL Server 2005/2008 ,OCP 9i)
May 29, 2009 at 3:04 am
thanks all, really appreciate your advice. i already have the scenario Lynn suggested in place, i was trying to find a way to by pass the "middle man".
i'll stick to the present process.
thanks again
------------------------------------------------------------------------
All it takes, is a step in the right direction, your feet will manage to find the way. I didn't say it'll be easy!!![font="Comic Sans MS"]:cool:[/font]
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply