December 17, 2001 at 10:54 am
I read some of the previous questions regarding Veritas, but need a little more detailed information. Like some of the previous messages, I do not have access to the Veritas software. This is controlled by out network admin. They kept pressuring me to use Veritas' SQL backup because it was on tape and was with all the other file backups, etc. I, too, feel uncomfortable with not being able to access the backup files. In SQL EM, the Veritas backup files are shown, but I cannot select them for restore. In the past, I created backup files nightly on disk and the OS backup would backup these files. I also did a few transaction log backups to disk files during the day. We have no databases over 5GB at this time, so space isn't a major issue yet.
Questions about Veritas: What is the best way to handle transaction log backups? Can I restore a Veritas backup of the database, then restore SQL Server backups of the transaction logs? Has anyone using the Veritas transaction log backup encountered problems? Can anyone give me VERY good reasons to USE or NOT USE Veritas backups for SQL Server?
We're running SQL Server 2000 on Win 2000 on a clustered server.
December 17, 2001 at 11:12 am
Yes, you should be able to use a Full Database backup from Veritas to restore and restore subsequent SQL Log backups to it.
Two problems that I have seen really brief;
1. When backing up the System State (registry?) for the database server, it would frequently fail and then leave the last database that it backed up with Trunc. Log on Checkpoint set causing a failure the next time through.
2. When restoring from the backup to another location you had to detach and attach the database following the Veritas restore completion in order to get it to a useable state. Kind of Odd.
The ultimate problem in my opinion is that it makes the backup scenario out of your control. Far too many problems with backup to tape from what I have seen. Additionally, it is out of your control. Sorry, just my nature.
Hope this helps.
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
December 17, 2001 at 11:52 am
Haven't had too many restores with Verias and actually need to do a DR sometime, but I convinced our admin to skip it and just grab the files.
One issue with Veritas backups to tape and disk logs, if the server fails, what do you do? Go back to last night? somewhat defeats the purpose of log backups. Also, if you do need to go back, what's the tape load time? Tape find time? do the tapes go offsite?
Some ammunition to avoid the tape backup.
Also time to backup: you need to take this into account. Disk will be faster (both backup and restore), but you still need to plan for back to tape at somepoint, though this can be disk to tape.
Steve Jones
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
December 17, 2001 at 12:10 pm
If the server fails, are you assuming the disk drive containing the log files is not available, therefore you have only a tape backup of the entire database? Doesn't this scenario give an advantage to Veritas since you could set up the logs to backup periodically to tape? Then, we would be able to restore the full Veritas backup and all of the logs backed up by Veritas. We have a 'tape library' available to our server for use by Veritas(according to our net admin). I'm not a 'hardware' person, so I'm not sure if this is something that SQL Server could access directly, but wouldn't this be the ideal solution (creating SQL Server backup files to tape) until the 'time' to run backups to tape became excessive?
Haven't had too many restores with Verias and actually need to do a DR sometime, but I convinced our admin to skip it and just grab the files.
One issue with Veritas backups to tape and disk logs, if the server fails, what do you do? Go back to last night? somewhat defeats the purpose of log backups. Also, if you do need to go back, what's the tape load time? Tape find time? do the tapes go offsite?
Some ammunition to avoid the tape backup.
Also time to backup: you need to take this into account. Disk will be faster (both backup and restore), but you still need to plan for back to tape at somepoint, though this can be disk to tape.
Steve Jones
[/quote]
December 17, 2001 at 12:20 pm
You can backup the logs to tape automatically, but you still get into the "time factor".
One other issue with tape libraries. This also applies to disk. What happens if there is a fire in your building? What if your building becomes the site of a disaster? ape libraries aren't so great when you cannot phyiscally remove the tape from the site.
It doesn't happen everyday, but it does happen. It's something to be aware of with libraries. Not sure SQL can access this, but it might.
Using Veritas (or any other backup solution) isn't horrible. Wouldn't even say its a bad idea, but the opinions of most DBAs that have been working with SQL Server for some time is to backup to tape. What happens after that is the network admin's job.
Steve Jones
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
December 17, 2001 at 12:23 pm
"Wouldn't even say its a bad idea, but the opinions of most DBAs that have been working with SQL Server for some time is to backup to tape"
You mean disk right Steve?
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
December 17, 2001 at 12:33 pm
yes, sorry. thanks. I meant disk.
Most people prefer backup to disk. At TechEd 2000, a number of the sql team also recommended this. Not to disparage vendors, but unless you have a VLDB, I don't see the point.
Steve Jones
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
December 17, 2001 at 12:38 pm
Do you mean, SQL Server backups created on DISK, then the OS puts the SQL Server backup files on TAPE? With all this information, it looks to me like the best option is to use SQL Server backup to create disk files on a disk drive NOT attached to the SQL Server, immediately have the OS backup this disk file to a tape. Then, this tape should be removed and stored outside the computer room or off-site. I think this would cover most disasters, but is this overkill?
You mean disk right Steve?
David
[/quote]
December 17, 2001 at 1:34 pm
Kind of. Personally I do the following:
Backup SQL to disk locally. gives me immeditate access to restoring dbs in case of data errors and allows fast backup.
Copy to remote disk - provides some fault tolerance and gives me another place that backups are stored. This is mainly that I have a production system in another physical location and I want to move the data quickly. I pull fulls every 6 hours and logs every 15 minutes.
BAckup the remote item to tape.
Tapes leave the building every night. Doesn't help if we have a fire at 4:00pm, but I have to pick my level of fault tolerance.
You could just run SQL to remote disk. These days that shouldn't be substantially slower than a local backup. My biggest item is that if there are network issues on our T-1, I still want backups to occur, which is why I run local backups.
Hope this helps.
Steve Jones
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
December 17, 2001 at 1:55 pm
Thanks, Steve and David. I think I have enough info to make recommendations on Veritas vs. SQL server - for now!
Kind of. Personally I do the following:
Backup SQL to disk locally. gives me immeditate access to restoring dbs in case of data errors and allows fast backup.
Copy to remote disk - provides some fault tolerance and gives me another place that backups are stored. This is mainly that I have a production system in another physical location and I want to move the data quickly. I pull fulls every 6 hours and logs every 15 minutes.
BAckup the remote item to tape.
Tapes leave the building every night. Doesn't help if we have a fire at 4:00pm, but I have to pick my level of fault tolerance.
You could just run SQL to remote disk. These days that shouldn't be substantially slower than a local backup. My biggest item is that if there are network issues on our T-1, I still want backups to occur, which is why I run local backups.
Hope this helps.
Steve Jones
[/quote]
December 17, 2001 at 2:40 pm
Glad to give opinions. Keep checking back, I'm sure Andy will weigh in tonight.
Steve Jones
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
December 17, 2001 at 7:33 pm
Im just slow - have had the flu! I have not used Veritas. Perhaps Im simple minded, but I dont see any advantage to 3rd party backup. SQL native backup is fast and reliable, why complicate it? I back up to local disk, then our network dude backs up to tape. I keep 2-3 days on disk whenever possible, I have no faith in tape! For most of my production stuff I do a full backup each night. A few key ones have log backup done every 15 min or so. Because I have so many production db's and not all are active (usually 50-60 out of 250 on any given day) I use a demand based log backup system for those - whenever the log hits 50m it gets backed up. We also replicate most of our production db's to a reporting server, so I have that as an extra source of data if needed. No cluster, we rely on good hardware (Dell) with plenty of redundancy in all areas.
Andy
December 18, 2001 at 1:34 am
I currently use Veritas for the overnight backup only (and only for my sql 6.5 & 7 db's, the version we have doesn't support 2000).
Again the server support team only have access to this hence if I require a restore it needs to go via then.
It works fine most of the time, but once in a blue moon the backup exec account hangs during a sql backup and the sql service needs restarting as the veritas login won't die will the kill command hence locks the database. (This normally happens when its runs against a maint plan, no suprise there)
Restores work well, even when restoring to another server.
In saying all that I would perfer to use the sql backup, but the company want one department to be able to backup/restore the lot.
Steven
December 18, 2001 at 3:14 am
My technical controller is pushing for us to use the SQL backup part of Veritas for our SQL Server backups, despite my demonstrating that I could do all kinds of recovery from normal SQL backups at a recent DR test! Unfortunately I think I will lose the battle because I am being transferred to the Technical controller's department after Christmas because he feels he should have ultimate control over the various databases we have (SQL and others) which are currently under my control! It also gives him the opportunity to off load a load of NT and VMS management on me since he did not replace the Technical analyst who left! Sneaky, or what?!
December 18, 2001 at 8:46 am
Haven't read through the thread so may be repeating / off topic.
The backup command has to fit in with the version of sql server so whenever you change sql server versions/service packs/hot fixes you may also need to upgrade veritas and make sure that it is always compatible with the versions of sql server that you are running.
I always like to have the latest backup on disk so that it is easily transferrable to another system for testing or for recovery if necessary.
Backups to disk from sql server (not using the maint.exe) are always likely to work correctly because they are tested so often.
If you run the backup from the server it is easy to make it fit in wit hany batch processing on that server.
Basically backups are too important to allow other products to interfere with them.
Cursors never.
DTS - only when needed and never to control.
Viewing 15 posts - 1 through 15 (of 38 total)
You must be logged in to reply to this topic. Login to reply