Backup Strategy : Microsoft Backup or Veritas

I am trying to decide if we should use Microsoft Backup (Database Maintenance
Plans) or use Veritas. We already own Veritas, and the SQL clients.
Option 1. Do Not use Veritas SQL client. Use Microsoft Backup to produce a
.BAK file on the SAN. Use the Network install of Veritas (not on SQL svr) to
backup the .BAKs from the SAN. Downside: disk space on SAN is required.
Upside: using standard Microsoft tools. Downside: Need to store more than one
.BAK on the SAN for safety.
Option 2. Use Veritas SQL client. Do not use standard Microsoft backup
tools. Veritas SQL client will backup directly to tape. No space on the SAN
is required.
I am looking for a pros and cons of each to help me make my decision
thank you
ChrisChris
I have no experience with this vendor so I can tell you nothing but based
on lots of years of experience with MS BACKUP strategy I can tell that I
had never problems with it , I mean if you have a proper .BAK (using BACKUP
DATABASE...) file and you attempt to do a RESTORE command you are going to
get a healthy database always
"Chris" <Chris@.discussions.microsoft.com> wrote in message
news:0DA2F41F-8CF7-4EAB-B0E3-C368D403A947@.microsoft.com...
>I am trying to decide if we should use Microsoft Backup (Database
>Maintenance
> Plans) or use Veritas. We already own Veritas, and the SQL clients.
> Option 1. Do Not use Veritas SQL client. Use Microsoft Backup to produce a
> .BAK file on the SAN. Use the Network install of Veritas (not on SQL svr)
> to
> backup the .BAKs from the SAN. Downside: disk space on SAN is required.
> Upside: using standard Microsoft tools. Downside: Need to store more than
> one
> .BAK on the SAN for safety.
> Option 2. Use Veritas SQL client. Do not use standard Microsoft backup
> tools. Veritas SQL client will backup directly to tape. No space on the
> SAN
> is required.
>
> I am looking for a pros and cons of each to help me make my decision
> thank you
> Chris|||Uri Dimant wrote:
> Chris
> I have no experience with this vendor so I can tell you nothing but based
> on lots of years of experience with MS BACKUP strategy I can tell that I
> had never problems with it , I mean if you have a proper .BAK (using BACKUP
> DATABASE...) file and you attempt to do a RESTORE command you are going to
> get a healthy database always
>
>
> "Chris" <Chris@.discussions.microsoft.com> wrote in message
> news:0DA2F41F-8CF7-4EAB-B0E3-C368D403A947@.microsoft.com...
>> I am trying to decide if we should use Microsoft Backup (Database
>> Maintenance
>> Plans) or use Veritas. We already own Veritas, and the SQL clients.
>> Option 1. Do Not use Veritas SQL client. Use Microsoft Backup to produce a
>> .BAK file on the SAN. Use the Network install of Veritas (not on SQL svr)
>> to
>> backup the .BAKs from the SAN. Downside: disk space on SAN is required.
>> Upside: using standard Microsoft tools. Downside: Need to store more than
>> one
>> .BAK on the SAN for safety.
>> Option 2. Use Veritas SQL client. Do not use standard Microsoft backup
>> tools. Veritas SQL client will backup directly to tape. No space on the
>> SAN
>> is required.
>>
>> I am looking for a pros and cons of each to help me make my decision
>> thank you
>> Chris
>
I agree with Uri. It's quite easy to let SQL server handle the backup in
any way you like and then just backup the backup file. In this way it's
only a regular file backup you need to do and you'll always have a
native SQL server backup file at hand.
An extra plus is that you save the cost of a Veritas SQL server backup
Agent. It might not the the case for you, but in many cases you have to
pay extra to get this agent - just like if you need the Exchange server
Agent.
Regards
Steen

Backup Strategy : Microsoft Backup or Veritas

I am trying to decide if we should use Microsoft Backup (Database Maintenance
Plans) or use Veritas. We already own Veritas, and the SQL clients.
Option 1. Do Not use Veritas SQL client. Use Microsoft Backup to produce a
..BAK file on the SAN. Use the Network install of Veritas (not on SQL svr) to
backup the .BAKs from the SAN. Downside: disk space on SAN is required.
Upside: using standard Microsoft tools. Downside: Need to store more than one
..BAK on the SAN for safety.
Option 2. Use Veritas SQL client. Do not use standard Microsoft backup
tools. Veritas SQL client will backup directly to tape. No space on the SAN
is required.
I am looking for a pros and cons of each to help me make my decision
thank you
Chris
Chris
I have no experience with this vendor so I can tell you nothing but based
on lots of years of experience with MS BACKUP strategy I can tell that I
had never problems with it , I mean if you have a proper .BAK (using BACKUP
DATABASE...) file and you attempt to do a RESTORE command you are going to
get a healthy database always
"Chris" <Chris@.discussions.microsoft.com> wrote in message
news:0DA2F41F-8CF7-4EAB-B0E3-C368D403A947@.microsoft.com...
>I am trying to decide if we should use Microsoft Backup (Database
>Maintenance
> Plans) or use Veritas. We already own Veritas, and the SQL clients.
> Option 1. Do Not use Veritas SQL client. Use Microsoft Backup to produce a
> .BAK file on the SAN. Use the Network install of Veritas (not on SQL svr)
> to
> backup the .BAKs from the SAN. Downside: disk space on SAN is required.
> Upside: using standard Microsoft tools. Downside: Need to store more than
> one
> .BAK on the SAN for safety.
> Option 2. Use Veritas SQL client. Do not use standard Microsoft backup
> tools. Veritas SQL client will backup directly to tape. No space on the
> SAN
> is required.
>
> I am looking for a pros and cons of each to help me make my decision
> thank you
> Chris
|||Uri Dimant wrote:
> Chris
> I have no experience with this vendor so I can tell you nothing but based
> on lots of years of experience with MS BACKUP strategy I can tell that I
> had never problems with it , I mean if you have a proper .BAK (using BACKUP
> DATABASE...) file and you attempt to do a RESTORE command you are going to
> get a healthy database always
>
>
> "Chris" <Chris@.discussions.microsoft.com> wrote in message
> news:0DA2F41F-8CF7-4EAB-B0E3-C368D403A947@.microsoft.com...
>
I agree with Uri. It's quite easy to let SQL server handle the backup in
any way you like and then just backup the backup file. In this way it's
only a regular file backup you need to do and you'll always have a
native SQL server backup file at hand.
An extra plus is that you save the cost of a Veritas SQL server backup
Agent. It might not the the case for you, but in many cases you have to
pay extra to get this agent - just like if you need the Exchange server
Agent.
Regards
Steen

Backup Strategy : Microsoft Backup or Veritas

I am trying to decide if we should use Microsoft Backup (Database Maintenanc
e
Plans) or use Veritas. We already own Veritas, and the SQL clients.
Option 1. Do Not use Veritas SQL client. Use Microsoft Backup to produce a
.BAK file on the SAN. Use the Network install of Veritas (not on SQL svr) t
o
backup the .BAKs from the SAN. Downside: disk space on SAN is required.
Upside: using standard Microsoft tools. Downside: Need to store more than on
e
.BAK on the SAN for safety.
Option 2. Use Veritas SQL client. Do not use standard Microsoft backup
tools. Veritas SQL client will backup directly to tape. No space on the SAN
is required.
I am looking for a pros and cons of each to help me make my decision
thank you
ChrisChris
I have no experience with this vendor so I can tell you nothing but based
on lots of years of experience with MS BACKUP strategy I can tell that I
had never problems with it , I mean if you have a proper .BAK (using BACKUP
DATABASE...) file and you attempt to do a RESTORE command you are going to
get a healthy database always
"Chris" <Chris@.discussions.microsoft.com> wrote in message
news:0DA2F41F-8CF7-4EAB-B0E3-C368D403A947@.microsoft.com...
>I am trying to decide if we should use Microsoft Backup (Database
>Maintenance
> Plans) or use Veritas. We already own Veritas, and the SQL clients.
> Option 1. Do Not use Veritas SQL client. Use Microsoft Backup to produce a
> .BAK file on the SAN. Use the Network install of Veritas (not on SQL svr)
> to
> backup the .BAKs from the SAN. Downside: disk space on SAN is required.
> Upside: using standard Microsoft tools. Downside: Need to store more than
> one
> .BAK on the SAN for safety.
> Option 2. Use Veritas SQL client. Do not use standard Microsoft backup
> tools. Veritas SQL client will backup directly to tape. No space on the
> SAN
> is required.
>
> I am looking for a pros and cons of each to help me make my decision
> thank you
> Chris|||Uri Dimant wrote:
> Chris
> I have no experience with this vendor so I can tell you nothing but bas
ed
> on lots of years of experience with MS BACKUP strategy I can tell that I
> had never problems with it , I mean if you have a proper .BAK (using BACKU
P
> DATABASE...) file and you attempt to do a RESTORE command you are going
to
> get a healthy database always
>
>
> "Chris" <Chris@.discussions.microsoft.com> wrote in message
> news:0DA2F41F-8CF7-4EAB-B0E3-C368D403A947@.microsoft.com...
>
I agree with Uri. It's quite easy to let SQL server handle the backup in
any way you like and then just backup the backup file. In this way it's
only a regular file backup you need to do and you'll always have a
native SQL server backup file at hand.
An extra plus is that you save the cost of a Veritas SQL server backup
Agent. It might not the the case for you, but in many cases you have to
pay extra to get this agent - just like if you need the Exchange server
Agent.
Regards
Steen

Backup Oddity

A client needed to put in there own backup (without using
the Database Maintence Plan) I won't go into the reasons
but it was correct.
Anyway they asked us to find a safe way of deleting the
internal records and the files, hence me.
I have found something pretty odd. The sp_dropdevice does
not delete the records in the msdb tables backupset or
backupmediafamily why is this the case ?
Thanks
JYou would have to ask the MS programmers that wrote sp_dropdevice why it
doesn't delete the backup history. It might have been a conscious decision,
it might have been that they just didn't do this when backup history tables
changed structure between 6.5 and 7.0. It is always difficult to answer
"why" question if you weren't present MS design. :-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Julie" <anonymous@.discussions.microsoft.com> wrote in message
news:ed7d01c40c36$12470cb0$a401280a@.phx.gbl...
> A client needed to put in there own backup (without using
> the Database Maintence Plan) I won't go into the reasons
> but it was correct.
> Anyway they asked us to find a safe way of deleting the
> internal records and the files, hence me.
> I have found something pretty odd. The sp_dropdevice does
> not delete the records in the msdb tables backupset or
> backupmediafamily why is this the case ?
> Thanks
> J|||Thanks Tibor,
Now I don't need to trawl though BOL to see if I have
missed anything :-D
J

>--Original Message--
>You would have to ask the MS programmers that wrote
sp_dropdevice why it
>doesn't delete the backup history. It might have been a
conscious decision,
>it might have been that they just didn't do this when
backup history tables
>changed structure between 6.5 and 7.0. It is always
difficult to answer
>"why" question if you weren't present MS design. :-)
>--
>Tibor Karaszi, SQL Server MVP
>http://www.karaszi.com/sqlserver/default.asp
>
>"Julie" <anonymous@.discussions.microsoft.com> wrote in
message
>news:ed7d01c40c36$12470cb0$a401280a@.phx.gbl...
using
does
>
>.
>|||A tip, Julie:
Read the source code for the procedure in question. Reading the source code
for sp_dropdevice, I see that there is no code in there to remove backup
history, so there is no need to look any further. :-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Julie" <anonymous@.discussions.microsoft.com> wrote in message
news:ecfd01c40c39$8ee0e8b0$a301280a@.phx.gbl...
> Thanks Tibor,
> Now I don't need to trawl though BOL to see if I have
> missed anything :-D
> J
>
>
> sp_dropdevice why it
> conscious decision,
> backup history tables
> difficult to answer
> message
> using
> does|||Again thanks Tibor,
J

>--Original Message--
>A tip, Julie:
>Read the source code for the procedure in question.
Reading the source code
>for sp_dropdevice, I see that there is no code in there
to remove backup
>history, so there is no need to look any further. :-)
>--
>Tibor Karaszi, SQL Server MVP
>http://www.karaszi.com/sqlserver/default.asp
>
>"Julie" <anonymous@.discussions.microsoft.com> wrote in
message
>news:ecfd01c40c39$8ee0e8b0$a301280a@.phx.gbl...
reasons
the
or
>
>.
>