Back up exec 9 Question.

[raquetman75]

My main office purchase us a new server (os nt4) to run a certain apps. This application we call it sun system use sql 7 database. Currently everything is smoothly running. Now they purchase Backup exec ver 9 for back up software. Before I'll install, is there any issue so far between BE 9 and sql 7? Any input will be appreciated.

(I'm a little bit worried because my Boss keep telling me that I'll make sure everything will work fine after I install the BE 9.. I've been using lower version of BE for a long time but not in combo with SQL database. I've no experience in here..)

 

[SQLBill]

I don't know how well BE 9 works with SQL. However, here is some input:

Backup Exec WILL NOT backup up SQL Server without the BE SQL AGENT.

BEFORE YOU BUY IT! I prefer to do my SQL Server backups using the SQL Server backup commands. I backup the server to hard disk and then use Backup Exec to copy those files to tape. This means you don't need the SQL Agent.

The purpose of the SQL Agent is to allow Backup Exec to backup the SQL Server database(s) while it/they are still in use.

-SQLBill

 

[NortonES2]

Agree completely with SQLBill, have never worked out the benefit of buying the SQLAgent. Though think it would be useful if it could backup \ restore individual tables.

If it doesn't leak oil it must be empty!!

 

[SQLBill]

NortonES2,

The benefit of using the SQL Agent is that you can backup directly to tape.

When you don't use it, you have to backup to hard disk so for each 1 GB of database, you need 2 GB of hard disk space (1 for database and 1 for backup). And that's if you are only doing FULL Backups. Then you still have to back that file up to tape.

I prefer to use the 'native' SQL Server backup commands because I know they will work. I had a problem where I was initially using BE 8.6 SQL Agent and backing up directly to tape. No one (the vendor who sold it to me nor Veritas) ever told me there was an issue with SQL Agent and SQL Server 2000. So none of my backups worked and since only found out about it after a hardware crash, I had to send the tapes to Veritas for recovery. Luckily, the vendor who sold the product to us paid for the recovery.

By the way....you can find out about the issue I had by doing a keyword search. I posted it here before.

-SQLBill

 

[NortonES2]

SQLBill, agree that you use twice as much disk space and still have to backup to tape. Though a benefit of this is if you have to restore the database this can be done directly from disk and not tape via BackupExec which would take longer. We only use BackupExec for creating backups which can be stored offsite for our DR strategy.

-------------------------------

If it doesn't leak oil it must be empty!!

 

[raquetman75]

Thanks SQLBill and NortonES2 for the input.

I have a license extra BE 8.6 as another option and my environment is NT4 server and sql 7 and if I use sql agent, is there an issue with this combo? Is it complicated to do SQL Server backup commands, if not, then how do you envoke the commands.

SQLBill.
Do you know what's the thread number of your issues on SQL agent? I believe it's easier for you to search because you can browse your "My Threads"

Thanks

 

[SQLBill]

Check thread481-413848. This didn't affect SQL Server 7, it was only SQL Server 2000.

The SQL Server commands for backups are really simple, check out BACKUP DATABASE in the Books OnLine (I use SQL Server 2000, so I'm not familiar with SS7.0 - it may or may not have the BOL).

Basically, you set up backup device:

use master
exec sp_addumpdevice 'disk', 'dumpname', 'C:\<path>\mydatabasename.bak'

the last part of the path can be whatever you want to call the file; myfullbackup.bak myfile.bak, afullbackup.bak, afile.bak

Then to do the backup, it's basically:
BACKUP DATABASE mydatabasename to dumpname

For the dumpname, I use mydatabase name with the type of backup. MYDBFULL, MYDBDIFF, MYDBTRANS.

Then to restore you run:

RESTORE DATABASE mydatabasename
FROM dumpname

-SQLBill

 

[raquetman75]

I will try this during weekends.

Thanks