backup method question

hi
We are evaluating our backup plans. We currently do a live backup with a
backup exec SQL agent. Thinking about doing it to disk instead without
using veritas, just dumping the database to a file and then backing up
the file. My veritas rep is telling me it will be hard to do a restore
that way.
Is that true? Any other suggestions on backing up?
Thanks
Will
What your Veritas rep is saying is "If you backup to disk, then you won't
need to pay me for an overpriced and underfeatured SQL agent for each
server". Backup to disk and archive to tape is the preferred method for SQL
backups. Make sure you don't backup to the same disk as your data or log
files. I prefer to backup across a dedicated network link to a file server.
That file server is also my tape host so it can backup the files locally.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
> hi
> We are evaluating our backup plans. We currently do a live backup with a
> backup exec SQL agent. Thinking about doing it to disk instead without
> using veritas, just dumping the database to a file and then backing up
> the file. My veritas rep is telling me it will be hard to do a restore
> that way.
> Is that true? Any other suggestions on backing up?
> Thanks
> Will
|||Geoff N. Hiten wrote:
> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for SQL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file server.
> That file server is also my tape host so it can backup the files locally.
>
That is kinda what I thought. I am not an SQL guru by any means. I do
more of the plumging. Are there any special considerations to restoring
that file into SQL?
Thanks
Will
|||Hi
I was using backup exec to do the backup of the sql server 2000 database.
It is easy and has good GUI to restore.
But apart from that I did not find any compelling reasons to use it.
I am doing a backup on the USB attached Network drive and it takes about the
same time as taking it on tape.
Mangesh
"Geoff N. Hiten" wrote:

> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for SQL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file server.
> That file server is also my tape host so it can backup the files locally.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Will Kubly" <wkubly@.wi.rr.com> wrote in message
> news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
>
>
|||SQL backup files are self-contained and self-describing. That is, they
contain all the information required to recreate the database on the
original or any other SQL server. I strongly suggest you read the section
in BOL (Books On-Line) on Backing Up and Restoring Databases in the
Administering SQL Server section. There are some decisions you must make
when you set up a database or there will be painful consequences down the
road. Read and understand this section now, rather than when your system is
down.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:ep68s0AIFHA.560@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
> Geoff N. Hiten wrote:
won't[vbcol=seagreen]
SQL[vbcol=seagreen]
log[vbcol=seagreen]
server.[vbcol=seagreen]
locally.
> That is kinda what I thought. I am not an SQL guru by any means. I do
> more of the plumging. Are there any special considerations to restoring
> that file into SQL?
> Thanks
> Will

backup method question

hi
We are evaluating our backup plans. We currently do a live backup with a
backup exec SQL agent. Thinking about doing it to disk instead without
using veritas, just dumping the database to a file and then backing up
the file. My veritas rep is telling me it will be hard to do a restore
that way.
Is that true? Any other suggestions on backing up?
Thanks
WillWhat your Veritas rep is saying is "If you backup to disk, then you won't
need to pay me for an overpriced and underfeatured SQL agent for each
server". Backup to disk and archive to tape is the preferred method for SQL
backups. Make sure you don't backup to the same disk as your data or log
files. I prefer to backup across a dedicated network link to a file server.
That file server is also my tape host so it can backup the files locally.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
> hi
> We are evaluating our backup plans. We currently do a live backup with a
> backup exec SQL agent. Thinking about doing it to disk instead without
> using veritas, just dumping the database to a file and then backing up
> the file. My veritas rep is telling me it will be hard to do a restore
> that way.
> Is that true? Any other suggestions on backing up?
> Thanks
> Will|||Geoff N. Hiten wrote:
> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for S
QL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file serve
r.
> That file server is also my tape host so it can backup the files locally.
>
That is kinda what I thought. I am not an SQL guru by any means. I do
more of the plumging. Are there any special considerations to restoring
that file into SQL?
Thanks
Will|||Hi
I was using backup exec to do the backup of the sql server 2000 database.
It is easy and has good GUI to restore.
But apart from that I did not find any compelling reasons to use it.
I am doing a backup on the USB attached Network drive and it takes about the
same time as taking it on tape.
Mangesh
"Geoff N. Hiten" wrote:

> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for S
QL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file serve
r.
> That file server is also my tape host so it can backup the files locally.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Will Kubly" <wkubly@.wi.rr.com> wrote in message
> news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
>
>|||SQL backup files are self-contained and self-describing. That is, they
contain all the information required to recreate the database on the
original or any other SQL server. I strongly suggest you read the section
in BOL (Books On-Line) on Backing Up and Restoring Databases in the
Administering SQL Server section. There are some decisions you must make
when you set up a database or there will be painful consequences down the
road. Read and understand this section now, rather than when your system is
down.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:ep68s0AIFHA.560@.TK2MSFTNGP12.phx.gbl...
> Geoff N. Hiten wrote:
won't[vbcol=seagreen]
SQL[vbcol=seagreen]
log[vbcol=seagreen]
server.[vbcol=seagreen]
locally.[vbcol=seagreen]
> That is kinda what I thought. I am not an SQL guru by any means. I do
> more of the plumging. Are there any special considerations to restoring
> that file into SQL?
> Thanks
> Will

backup method question

hi
We are evaluating our backup plans. We currently do a live backup with a
backup exec SQL agent. Thinking about doing it to disk instead without
using veritas, just dumping the database to a file and then backing up
the file. My veritas rep is telling me it will be hard to do a restore
that way.
Is that true? Any other suggestions on backing up?
Thanks
WillWhat your Veritas rep is saying is "If you backup to disk, then you won't
need to pay me for an overpriced and underfeatured SQL agent for each
server". Backup to disk and archive to tape is the preferred method for SQL
backups. Make sure you don't backup to the same disk as your data or log
files. I prefer to backup across a dedicated network link to a file server.
That file server is also my tape host so it can backup the files locally.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
> hi
> We are evaluating our backup plans. We currently do a live backup with a
> backup exec SQL agent. Thinking about doing it to disk instead without
> using veritas, just dumping the database to a file and then backing up
> the file. My veritas rep is telling me it will be hard to do a restore
> that way.
> Is that true? Any other suggestions on backing up?
> Thanks
> Will|||Geoff N. Hiten wrote:
> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for SQL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file server.
> That file server is also my tape host so it can backup the files locally.
>
That is kinda what I thought. I am not an SQL guru by any means. I do
more of the plumging. Are there any special considerations to restoring
that file into SQL?
Thanks
Will|||Hi
I was using backup exec to do the backup of the sql server 2000 database.
It is easy and has good GUI to restore.
But apart from that I did not find any compelling reasons to use it.
I am doing a backup on the USB attached Network drive and it takes about the
same time as taking it on tape.
Mangesh
"Geoff N. Hiten" wrote:
> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for SQL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file server.
> That file server is also my tape host so it can backup the files locally.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Will Kubly" <wkubly@.wi.rr.com> wrote in message
> news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
> > hi
> >
> > We are evaluating our backup plans. We currently do a live backup with a
> > backup exec SQL agent. Thinking about doing it to disk instead without
> > using veritas, just dumping the database to a file and then backing up
> > the file. My veritas rep is telling me it will be hard to do a restore
> > that way.
> > Is that true? Any other suggestions on backing up?
> >
> > Thanks
> >
> > Will
>
>|||SQL backup files are self-contained and self-describing. That is, they
contain all the information required to recreate the database on the
original or any other SQL server. I strongly suggest you read the section
in BOL (Books On-Line) on Backing Up and Restoring Databases in the
Administering SQL Server section. There are some decisions you must make
when you set up a database or there will be painful consequences down the
road. Read and understand this section now, rather than when your system is
down.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:ep68s0AIFHA.560@.TK2MSFTNGP12.phx.gbl...
> Geoff N. Hiten wrote:
> > What your Veritas rep is saying is "If you backup to disk, then you
won't
> > need to pay me for an overpriced and underfeatured SQL agent for each
> > server". Backup to disk and archive to tape is the preferred method for
SQL
> > backups. Make sure you don't backup to the same disk as your data or
log
> > files. I prefer to backup across a dedicated network link to a file
server.
> > That file server is also my tape host so it can backup the files
locally.
> >
> That is kinda what I thought. I am not an SQL guru by any means. I do
> more of the plumging. Are there any special considerations to restoring
> that file into SQL?
> Thanks
> Will

Backup job doesn't finish.

I have a backup job that just hangs for days instead of finishing like it
should on one of our SQL servers. Its a solomon database and is using SQL
server 2000 standard. The system databases are not included in the backup its
just the solomon databases. I am not getting an error or anything because it
doesn't finish. Does anyone have any suggestions on how to troubleshoot this
sort of thing?
Thanks,
Have you done a database check to see if the database is corrupted?
I would see if the database is corrupted first before trying the backup. I
have seen this happen with databases where there are orphaned records. And
the backup will work one day and there is a corruption that causes the
database be damaged.
Thanks,
David
"D Smith" wrote:

> I have a backup job that just hangs for days instead of finishing like it
> should on one of our SQL servers. Its a solomon database and is using SQL
> server 2000 standard. The system databases are not included in the backup its
> just the solomon databases. I am not getting an error or anything because it
> doesn't finish. Does anyone have any suggestions on how to troubleshoot this
> sort of thing?
> Thanks,
|||By database check do you mean integrity check? If so then yes I ran one and
it was successful.
"david" wrote:
[vbcol=seagreen]
> Have you done a database check to see if the database is corrupted?
> I would see if the database is corrupted first before trying the backup. I
> have seen this happen with databases where there are orphaned records. And
> the backup will work one day and there is a corruption that causes the
> database be damaged.
> --
> Thanks,
> David
>
> "D Smith" wrote:

Backup job doesn't finish.

I have a backup job that just hangs for days instead of finishing like it
should on one of our SQL servers. Its a solomon database and is using SQL
server 2000 standard. The system databases are not included in the backup its
just the solomon databases. I am not getting an error or anything because it
doesn't finish. Does anyone have any suggestions on how to troubleshoot this
sort of thing?
Thanks,Have you done a database check to see if the database is corrupted?
I would see if the database is corrupted first before trying the backup. I
have seen this happen with databases where there are orphaned records. And
the backup will work one day and there is a corruption that causes the
database be damaged.
--
Thanks,
David
"D Smith" wrote:
> I have a backup job that just hangs for days instead of finishing like it
> should on one of our SQL servers. Its a solomon database and is using SQL
> server 2000 standard. The system databases are not included in the backup its
> just the solomon databases. I am not getting an error or anything because it
> doesn't finish. Does anyone have any suggestions on how to troubleshoot this
> sort of thing?
> Thanks,|||By database check do you mean integrity check? If so then yes I ran one and
it was successful.
"david" wrote:
> Have you done a database check to see if the database is corrupted?
> I would see if the database is corrupted first before trying the backup. I
> have seen this happen with databases where there are orphaned records. And
> the backup will work one day and there is a corruption that causes the
> database be damaged.
> --
> Thanks,
> David
>
> "D Smith" wrote:
> > I have a backup job that just hangs for days instead of finishing like it
> > should on one of our SQL servers. Its a solomon database and is using SQL
> > server 2000 standard. The system databases are not included in the backup its
> > just the solomon databases. I am not getting an error or anything because it
> > doesn't finish. Does anyone have any suggestions on how to troubleshoot this
> > sort of thing?
> >
> > Thanks,

Backup job doesn't finish.

I have a backup job that just hangs for days instead of finishing like it
should on one of our SQL servers. Its a solomon database and is using SQL
server 2000 standard. The system databases are not included in the backup it
s
just the solomon databases. I am not getting an error or anything because it
doesn't finish. Does anyone have any suggestions on how to troubleshoot this
sort of thing?
Thanks,Have you done a database check to see if the database is corrupted?
I would see if the database is corrupted first before trying the backup. I
have seen this happen with databases where there are orphaned records. And
the backup will work one day and there is a corruption that causes the
database be damaged.
--
Thanks,
David
"D Smith" wrote:

> I have a backup job that just hangs for days instead of finishing like it
> should on one of our SQL servers. Its a solomon database and is using SQL
> server 2000 standard. The system databases are not included in the backup
its
> just the solomon databases. I am not getting an error or anything because
it
> doesn't finish. Does anyone have any suggestions on how to troubleshoot th
is
> sort of thing?
> Thanks,|||By database check do you mean integrity check? If so then yes I ran one and
it was successful.
"david" wrote:
[vbcol=seagreen]
> Have you done a database check to see if the database is corrupted?
> I would see if the database is corrupted first before trying the backup. I
> have seen this happen with databases where there are orphaned records. And
> the backup will work one day and there is a corruption that causes the
> database be damaged.
> --
> Thanks,
> David
>
> "D Smith" wrote:
>