Backup problem

Sorry if i am in wrong place. i read http://msdn2.microsoft.com/en-us/library/aa225964(SQL.80).aspx

the 1st two commond successfully executed

USE master
EXEC sp_addumpdevice 'disk', 'MyNwind_2',
'c:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\MyNwind_2.dat'

--Create the log backup device.
USE master
EXEC sp_addumpdevice 'disk', 'MyNwindLog1',
'c:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\MyNwindLog1.dat'

But following command gave me an error which is in the last of this post (red colored)

-- Back up the full MyNwind database.
BACKUP DATABASE test TO MyNwind_2

-- Update activity has occurred since the full database backup.

-- Back up the log of the MyNwind database.
BACKUP LOG test
TO MyNwindLog1

Msg 3201, Level 16, State 1, Line 11
Cannot open backup device 'MyNwind_2(c:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\MyNwind_2.dat)'. Operating system error 5(Access is denied.).

The c:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\

is valid location (i mean this folder exists)

Hi,

if you are using SQL Server Authentication you are authentication on the folder level with the Serice Account which is actually running the SQL Server Service. Make sure this one has the appropiate permissions to access the file path and create files in that folder. Using Windows Authentication will use the credentials of the current user to get access to the path, make then sure this your user has the appropiate permissions. WHat you have to keep in mind is, that the path you are provding here is a local server path, notone of the actual computer you are sending the query from (if you are using a client and do not work directly on the server). You will make sure that the path exists on the executing server.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

Backup pefromed by SQLSERVERAGENT fails

I just created five new BU devices, then a job for each
and executed the jobs to create the intial backups on a
new database.
Four of the jobs worked fine. In Event Viewer, the Source
= MSSQLSERVER and the USER = SQLEXEC.
One job failed. Source = SQLSERVERAGENT and USER = N/A
Where did I go wrong? Why does the failing job use a
different USER and Source?
TIA MikeYou need to give us more info. Without the error message, it is like saying: "My computer doesn't
work. What is the problem?".
Check the job history, check "show step details", and go to the relevant step. See what the error
message is. Also, see the Agent errorlog.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Mike Hoyt" <mhoyt@.affiliatedhealth.org> wrote in message
news:0ec301c39d9e$db5dff70$a001280a@.phx.gbl...
> I just created five new BU devices, then a job for each
> and executed the jobs to create the intial backups on a
> new database.
> Four of the jobs worked fine. In Event Viewer, the Source
> = MSSQLSERVER and the USER = SQLEXEC.
> One job failed. Source = SQLSERVERAGENT and USER = N/A
> Where did I go wrong? Why does the failing job use a
> different USER and Source?
> TIA Mike|||The Job is failing at Step 1, which was invoked by
Schedule 1. Step 1 is the only step, and it is the basic
backup syntax. The SQLAgent error log is blank for
failures and warnings, information is the usual start up
stuff.
I know the agent is running, th eother jobs run and I get
email alerts of their completion. I get the email alert
of the failure of this job.
What I'm hoping osmebody can tell me is why this job is
run by Source = SQLSERVERAGENT and USER = N/A and the
other, sucessfull jobs, are run by MSSQLSERVER and the
USER = SQLEXEC|||I haven't played with this to see if this is the case but do
the jobs have different owners?
-Sue
On Wed, 29 Oct 2003 08:55:41 -0800,
<anonymous@.discussions.microsoft.com> wrote:
>The Job is failing at Step 1, which was invoked by
>Schedule 1. Step 1 is the only step, and it is the basic
>backup syntax. The SQLAgent error log is blank for
>failures and warnings, information is the usual start up
>stuff.
>I know the agent is running, th eother jobs run and I get
>email alerts of their completion. I get the email alert
>of the failure of this job.
>What I'm hoping osmebody can tell me is why this job is
>run by Source = SQLSERVERAGENT and USER = N/A and the
>other, sucessfull jobs, are run by MSSQLSERVER and the
>USER = SQLEXEC|||Have you checked job step history? Right click the job, select history, and
check job step details.
--
Michiel Wories, SQL Server PM
This posting is provided "AS IS" with no warranties, and confers no rights.
--
<anonymous@.discussions.microsoft.com> wrote in message
news:0e5501c39e3d$7c4f95d0$a501280a@.phx.gbl...
> The Job is failing at Step 1, which was invoked by
> Schedule 1. Step 1 is the only step, and it is the basic
> backup syntax. The SQLAgent error log is blank for
> failures and warnings, information is the usual start up
> stuff.
> I know the agent is running, th eother jobs run and I get
> email alerts of their completion. I get the email alert
> of the failure of this job.
> What I'm hoping osmebody can tell me is why this job is
> run by Source = SQLSERVERAGENT and USER = N/A and the
> other, sucessfull jobs, are run by MSSQLSERVER and the
> USER = SQLEXEC

Backup log WITH NO_LOG - change recovery model to SIMPLE?

Hi,
I use FULL recovery model, SQL 2005. Is it possible this type of
backup ""change"" my recovery model to SIMPLE. I noticed when I
executed this:
BACKUP DATABSE db_name
TO DISK = 'path'
BACKUP LOG db_name WITH NO_LOG
DBCC SHRINKFILE ('db_name_log', truncateonly)
Now transact log grow very, very, very slow (this is symptom simple
model). But when executed this (different order):
BACKUP LOG db_name WITH NO_LOG
DBCC SHRINKFILE ('db_name_log', truncateonly)
BACKUP DATABSE db_name
TO DISK = 'path'
transact log grow normally
Would somebody explain me this, and tell me first statement change
(theoretically) my model to SIMPLE?
--
RegardsHi
First , read this article
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
<anxcomp@.gmail.com> wrote in message
news:1187684709.945537.84260@.g4g2000hsf.googlegroups.com...
> Hi,
> I use FULL recovery model, SQL 2005. Is it possible this type of
> backup ""change"" my recovery model to SIMPLE. I noticed when I
> executed this:
> BACKUP DATABSE db_name
> TO DISK = 'path'
> BACKUP LOG db_name WITH NO_LOG
> DBCC SHRINKFILE ('db_name_log', truncateonly)
>
> Now transact log grow very, very, very slow (this is symptom simple
> model). But when executed this (different order):
> BACKUP LOG db_name WITH NO_LOG
> DBCC SHRINKFILE ('db_name_log', truncateonly)
> BACKUP DATABSE db_name
> TO DISK = 'path'
> transact log grow normally
> Would somebody explain me this, and tell me first statement change
> (theoretically) my model to SIMPLE?
> --
> Regards
>|||This is expected. If you are in full mode and empty the log without actually doing a backup (which
is what TRUNCATE_ONLY and NO_LOG does), then subsequent real log backups would be useless. SQL
Server know this and in this situation, the database acts as if it is simple recovery (log is
auto-truncated).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
<anxcomp@.gmail.com> wrote in message news:1187684709.945537.84260@.g4g2000hsf.googlegroups.com...
> Hi,
> I use FULL recovery model, SQL 2005. Is it possible this type of
> backup ""change"" my recovery model to SIMPLE. I noticed when I
> executed this:
> BACKUP DATABSE db_name
> TO DISK = 'path'
> BACKUP LOG db_name WITH NO_LOG
> DBCC SHRINKFILE ('db_name_log', truncateonly)
>
> Now transact log grow very, very, very slow (this is symptom simple
> model). But when executed this (different order):
> BACKUP LOG db_name WITH NO_LOG
> DBCC SHRINKFILE ('db_name_log', truncateonly)
> BACKUP DATABSE db_name
> TO DISK = 'path'
> transact log grow normally
> Would somebody explain me this, and tell me first statement change
> (theoretically) my model to SIMPLE?
> --
> Regards
>|||On Aug 21, 2:52 pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> This is expected. If you are in full mode and empty the log without actually doing a backup (which
> is what TRUNCATE_ONLY and NO_LOG does), then subsequent real log backups would be useless. SQL
> Server know this and in this situation, the database acts as if it is simple recovery (log is
> auto-truncated).
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>
> <anxc...@.gmail.com> wrote in messagenews:1187684709.945537.84260@.g4g2000hsf.googlegroups.com...
> > Hi,
> > I use FULL recovery model, SQL 2005. Is it possible this type of
> > backup ""change"" my recovery model to SIMPLE. I noticed when I
> > executed this:
> > BACKUP DATABSE db_name
> > TO DISK = 'path'
> > BACKUP LOG db_name WITH NO_LOG
> > DBCC SHRINKFILE ('db_name_log', truncateonly)
> > Now transact log grow very, very, very slow (this is symptom simple
> > model). But when executed this (different order):
> > BACKUP LOG db_name WITH NO_LOG
> > DBCC SHRINKFILE ('db_name_log', truncateonly)
> > BACKUP DATABSE db_name
> > TO DISK = 'path'
> > transact log grow normally
> > Would somebody explain me this, and tell me first statement change
> > (theoretically) my model to SIMPLE?
> > --
> > Regards- Hide quoted text -
> - Show quoted text -
to change recovery model from full to simple use alter database
command for that database
alter database dbname set recovery=simple
http://msdn2.microsoft.com/en-us/library/aa275464(SQL.80).aspx
setting to simple recovery helps to minimize log file growth ,but note
you will not be able to do point in time recovery incase of failures
Thanks
VS|||On 21 Sie, 11:52, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> This is expected. If you are in full mode and empty the log without actually doing a backup (which
> is what TRUNCATE_ONLY and NO_LOG does), then subsequent real log backups would be useless. SQL
> Server know this and in this situation, the database acts as if it is simple recovery (log is
> auto-truncated).
So it is realy true, it change to SIMPLE mode, thanks.
Tibor I read your article ' Why you want to be restrictive with
shrink of database files', I understand I shouldn't use both
SHRINKFILE and SHRINKDATABASE command.
So, would you help me create good backup plan, which ENSURE me that I
shouldn't USE SHRINK* commands, please.
Main principles:
1.LOG can't grow so match (most important)
2 I can lost information max fifteen minutes back
3. I'd like use only full recovery model not SIMPLE
If you like it can be for example graphical plan - "Maintenance Plans"
on SQL 2005
Thank you
--
Regards|||> So it is realy true, it change to SIMPLE mode, thanks.
No, it doesn't change recovery model to simple. It puts the database in a state where it behaves the
same as in simple model. Important distinction.
> 1.LOG can't grow so match (most important)
OK. You handle this by doing frequent log backups since a lot backup will empty the ldf file(s).
> 2 I can lost information max fifteen minutes back
So you should do log backups at least in 15 minutes intervals. Perhaps every 10 minutes...
> 3. I'd like use only full recovery model not SIMPLE
So just keep the database in full recovery.
Above is very basic. Do a database (full) backup perhaps every day. And do a log backup every 10
minutes. This is easy thing to setup with the maint wizard.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
<anxcomp@.gmail.com> wrote in message news:1187727440.811711.299920@.a39g2000hsc.googlegroups.com...
> On 21 Sie, 11:52, "Tibor Karaszi"
> <tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
>> This is expected. If you are in full mode and empty the log without actually doing a backup
>> (which
>> is what TRUNCATE_ONLY and NO_LOG does), then subsequent real log backups would be useless. SQL
>> Server know this and in this situation, the database acts as if it is simple recovery (log is
>> auto-truncated).
> So it is realy true, it change to SIMPLE mode, thanks.
> Tibor I read your article ' Why you want to be restrictive with
> shrink of database files', I understand I shouldn't use both
> SHRINKFILE and SHRINKDATABASE command.
> So, would you help me create good backup plan, which ENSURE me that I
> shouldn't USE SHRINK* commands, please.
> Main principles:
> 1.LOG can't grow so match (most important)
> 2 I can lost information max fifteen minutes back
> 3. I'd like use only full recovery model not SIMPLE
> If you like it can be for example graphical plan - "Maintenance Plans"
> on SQL 2005
> Thank you
> --
> Regards
>|||> No, it doesn't change recovery model to simple. It puts the database in a state where it behaves the
> same as in simple model. Important distinction.
OK, I understand now.
> Above is very basic. Do a database (full) backup perhaps every day. And do a log backup every 10
> minutes. This is easy thing to setup with the maint wizard.
I've done this use Wizard and now I'm watching what happen with log :)
Thank you Tibor for all advices and other people too :)
--
Regards

Backup log - will it truncate?

According to BOL
<--
BACKUP LOG
Specifies a backup of the transaction log only. The log is backed up
from the last successfully executed LOG backup to the current end of
the log. Once the log is backed up, the space may be truncated when no
longer required by replication or active transactions.
--
Does this mean I could do something else to truncate the log or is it
saying that the backup log command may truncate the log if it feels
like it?

I want ot get a log from a client site onto my server for analysis but
I want ot make absolute certain that my backing up the log on their
server won't truncate it there.Trevor

A backup of the transaction log will truncate the transaction log. All
completed transactions will be removed.

What are you planing to do with the transaction log? There is not a lot
you can do with out a matching database. As far as I am aware,
Lumigent's Log reader is the only product that can read the transaction
log.

Regards

John

Trevor Best wrote:
> According to BOL
> <--
> BACKUP LOG
> Specifies a backup of the transaction log only. The log is backed up
> from the last successfully executed LOG backup to the current end of
> the log. Once the log is backed up, the space may be truncated when no
> longer required by replication or active transactions.
> -->
> Does this mean I could do something else to truncate the log or is it
> saying that the backup log command may truncate the log if it feels
> like it?
> I want ot get a log from a client site onto my server for analysis but
> I want ot make absolute certain that my backing up the log on their
> server won't truncate it there.|||johnbandettini@.yahoo.co.uk wrote:
> Trevor
> A backup of the transaction log will truncate the transaction log. All
> completed transactions will be removed.
> What are you planing to do with the transaction log? There is not a lot
> you can do with out a matching database. As far as I am aware,
> Lumigent's Log reader is the only product that can read the transaction
> log.

Hi John, thanks for the reply.

I do intend to view the log, I'm using SQLLog Rescue from
www.red-gate.com. I can connect to their server over a VPN but it took
hours to read the log and got a general network error during the
process. What I want to do is restore the database on my server c/w
logs so I can view them here.

I know I can grab the data files and attach them on my end but I would
have to wait until tonight when people are off line to free up the
files.|||On 9 Jun 2006 02:35:01 -0700, Trevor Best wrote:

(snip)
>I want ot get a log from a client site onto my server for analysis but
>I want ot make absolute certain that my backing up the log on their
>server won't truncate it there.

Hi Trevor,

BACKUP LOG <databasename>
TO DISK = 'x:\y\z\logbackup.bak'
WITH COPY_ONLY;

--
Hugo Kornelis, SQL Server MVP|||"Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info.INVALID> wrote in message
news:5hmi82pfl02iqnhelegm0v515dbdm1qpid@.4ax.com...
> On 9 Jun 2006 02:35:01 -0700, Trevor Best wrote:
> (snip)
> >I want ot get a log from a client site onto my server for analysis but
> >I want ot make absolute certain that my backing up the log on their
> >server won't truncate it there.
> Hi Trevor,
> BACKUP LOG <databasename>
> TO DISK = 'x:\y\z\logbackup.bak'
> WITH COPY_ONLY;

Is this a SQL 2005 specific command? I've never seen it before.

Very handy.

> --
> Hugo Kornelis, SQL Server MVP|||Greg D. Moore (Strider) (mooregr_deleteth1s@.greenms.com) writes:
> "Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info.INVALID> wrote in message
> news:5hmi82pfl02iqnhelegm0v515dbdm1qpid@.4ax.com...
>> BACKUP LOG <databasename>
>> TO DISK = 'x:\y\z\logbackup.bak'
>> WITH COPY_ONLY;
> Is this a SQL 2005 specific command? I've never seen it before.

Yes, that's a new addition (which I neither I had noticed until Hugo
posted about it). It appears to be a "NO_TRUNCATE light". That is,
NO_TRUNCATE also waives the requirement that the database should be
accessible etc and is mainly intended for emergency situations.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||On Sat, 10 Jun 2006 12:51:23 +0000 (UTC), Erland Sommarskog wrote:

>Greg D. Moore (Strider) (mooregr_deleteth1s@.greenms.com) writes:
>> "Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info.INVALID> wrote in message
>> news:5hmi82pfl02iqnhelegm0v515dbdm1qpid@.4ax.com...
>>> BACKUP LOG <databasename>
>>> TO DISK = 'x:\y\z\logbackup.bak'
>>> WITH COPY_ONLY;
>>
>> Is this a SQL 2005 specific command? I've never seen it before.
>Yes, that's a new addition (which I neither I had noticed until Hugo
>posted about it). It appears to be a "NO_TRUNCATE light". That is,
>NO_TRUNCATE also waives the requirement that the database should be
>accessible etc and is mainly intended for emergency situations.

Hi Erland,

That's right. The major advantage of COPY_ONLY over NO_TRUNCATE is (IMO)
that this option also works on full and incremental backups. It's a
great way to quickly get a backup of a DB to do some tests or
trouble-shooting on without disrupting the backup schema.

--
Hugo Kornelis, SQL Server MVP|||"Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info.INVALID> wrote in message
news:9juo821f71b7ah782onh5lbotre5qrgie1@.4ax.com...
> On Sat, 10 Jun 2006 12:51:23 +0000 (UTC), Erland Sommarskog wrote:
> >Greg D. Moore (Strider) (mooregr_deleteth1s@.greenms.com) writes:
> >> "Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info.INVALID> wrote in message
> >> news:5hmi82pfl02iqnhelegm0v515dbdm1qpid@.4ax.com...
> >>> BACKUP LOG <databasename>
> >>> TO DISK = 'x:\y\z\logbackup.bak'
> >>> WITH COPY_ONLY;
> >>
> >> Is this a SQL 2005 specific command? I've never seen it before.
> >Yes, that's a new addition (which I neither I had noticed until Hugo
> >posted about it). It appears to be a "NO_TRUNCATE light". That is,
> >NO_TRUNCATE also waives the requirement that the database should be
> >accessible etc and is mainly intended for emergency situations.
> Hi Erland,
> That's right. The major advantage of COPY_ONLY over NO_TRUNCATE is (IMO)
> that this option also works on full and incremental backups. It's a
> great way to quickly get a backup of a DB to do some tests or
> trouble-shooting on without disrupting the backup schema.

Yeah, that's why I was thinking it would be so useful.

I'll have to keep it in mind for when we upgrade to SQL 2005.

(Still have to have THAT particular debate with the finance folks who pay
the bills. :-)

> --
> Hugo Kornelis, SQL Server MVP

backup job quits without any errors

Hi

I have a job which is executed via SQL agent -it attempts to backup each database..

The only problem is that it terminates about 1/2 through (not always at the same spot) - there are about 80 databases on the server

No errors are logged.. Where do I look next ?

The commands executed are as follows:

--

DECLARE @.DB_Name varchar(32)
DECLARE @.Backup_Path varchar(255)
DECLARE @.Backup_Name varchar(255)

DECLARE DB_Cursor CURSOR FOR SELECT NAME FROM sysdatabases

OPEN DB_Cursor

FETCH NEXT FROM DB_Cursor INTO @.DB_Name

WHILE @.@.FETCH_STATUS = 0
BEGIN
IF @.DB_Name <> 'tempdb' AND @.DB_Name <> 'model'
BEGIN
print '--<< ' + @.db_name + ' >>--'
SET @.Backup_Path = N'C:\sql2005backups\nightly\' + @.DB_Name + 'Daily' + '.bak'
SET @.Backup_Name = @.DB_Name + N' backup'
BACKUP DATABASE @.DB_Name TO DISK = @.Backup_Path WITH INIT
END
FETCH NEXT FROM DB_Cursor INTO @.DB_Name
END

CLOSE DB_cursor
DEALLOCATE DB_cursor

print 'Finished backing up'

Have you tried running the TSQL code from within a management studio or a query analyzer window to see where it fails? Does it run to completion in from the Query Analyzer/Management Studio window?

The other thing that you can do is if you go into the properties of the SQL Server Agent job you can have it put the results of the commands to a text file.

In the SQL Server Management Studio or 2000 Enterprise Manager, go to the properties of the job. Edit the step and click the advanced tab. In the middle of the page there will be a text box called Output File. Just browse to where you would like the output of the commands to reside and indicate a file name.

You will be able to see what errors the SQL Server Agent job is encountering.

Drew

|||Are databases being added or removed (detatched/attached) during the backup processing maybe?

If the script quits without errors, does it write your completion message? @.@.fetch_status is a tri-state value. Either a -1 or a -2 value (any value but 0) would end your loop.

You may want to include more robust checking on that value.

In SQL Server 2005 you could throw a select from sys.dm_exec_cursors at the end of your script to see what the ending status was on the cursor down there with the completion message.

|||

thanks - I'll check it out your suggestions

no - no databases are being being detached etc and yes, it does get to the completion message..

Bruce.

backup job quits without any errors

Hi

I have a job which is executed via SQL agent -it attempts to backup each database..

The only problem is that it terminates about 1/2 through (not always at the same spot) - there are about 80 databases on the server

No errors are logged.. Where do I look next ?

The commands executed are as follows:

--

DECLARE @.DB_Name varchar(32)
DECLARE @.Backup_Path varchar(255)
DECLARE @.Backup_Name varchar(255)

DECLARE DB_Cursor CURSOR FOR SELECT NAME FROM sysdatabases

OPEN DB_Cursor

FETCH NEXT FROM DB_Cursor INTO @.DB_Name

WHILE @.@.FETCH_STATUS = 0
BEGIN
IF @.DB_Name <> 'tempdb' AND @.DB_Name <> 'model'
BEGIN
print '--<< ' + @.db_name + ' >>--'
SET @.Backup_Path = N'C:\sql2005backups\nightly\' + @.DB_Name + 'Daily' + '.bak'
SET @.Backup_Name = @.DB_Name + N' backup'
BACKUP DATABASE @.DB_Name TO DISK = @.Backup_Path WITH INIT
END
FETCH NEXT FROM DB_Cursor INTO @.DB_Name
END

CLOSE DB_cursor
DEALLOCATE DB_cursor

print 'Finished backing up'

Have you tried running the TSQL code from within a management studio or a query analyzer window to see where it fails? Does it run to completion in from the Query Analyzer/Management Studio window?

The other thing that you can do is if you go into the properties of the SQL Server Agent job you can have it put the results of the commands to a text file.

In the SQL Server Management Studio or 2000 Enterprise Manager, go to the properties of the job. Edit the step and click the advanced tab. In the middle of the page there will be a text box called Output File. Just browse to where you would like the output of the commands to reside and indicate a file name.

You will be able to see what errors the SQL Server Agent job is encountering.

Drew

|||Are databases being added or removed (detatched/attached) during the backup processing maybe?

If the script quits without errors, does it write your completion message? @.@.fetch_status is a tri-state value. Either a -1 or a -2 value (any value but 0) would end your loop.

You may want to include more robust checking on that value.

In SQL Server 2005 you could throw a select from sys.dm_exec_cursors at the end of your script to see what the ending status was on the cursor down there with the completion message.|||

thanks - I'll check it out your suggestions

no - no databases are being being detached etc and yes, it does get to the completion message..

Bruce.

Backup Job Failing

I have an SSIS package that does one simple thing: perform a FULL backup of a database.

I executed this package yesterday at 2:00. The package backs up to four individual files on a network share. The network share is accessible from the SQL Server. THe database in question is 245GB in size.

The package was running fine when I left for the day. When I got in today, there was an error in the SQL Server log:

Error: 3041, Severity: 16, State: 1.

BACKUP failed to complete the command BACKUP DATABASE ServicingODS. Check the backup application log for detailed messages.

Where is this infamous backup application log?!? The Event Viewer says the same thing. Needless to say, the error message is a bit vague.

There were no "issus" overnight (power outages, network issues, etc.)

Anyone have any ideas?

Thanks!

Hi A.M

If you check the SQL server error log, there should be another line of error above the message that you have posted.

Could you please check and post a few lines from above and below the message you have already posted.

Jag