Veritas Backup/Restore
-
Thanks for checking in Andy! I know how you feel, I'm fighting a terrible cold. Anyway, your plan is similar to the plan I had in place before Veritas. I don't back up my logs that often because the current databases don't have a lot of updating. But I'm working on a new database that will be updated heavily and that's part of the reason I'm looking at the backup plan. Was wondering how you backup the logs every 15 minutes? You need to keep every log since the last full backup, so what kind of naming conventions do you use? OR, do you append logs to a single device/file name? Thanks for the info, more ammunition for SQL Server backups.
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
[/quote]
-
You make a good point about the version updates. Just another point to make me nervous.
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.
[/quote]
-
Another one of my fears, the Veritas backup doesn't work. Not that long ago, I needed a restore for a particular day for a NON-SQL Server Accounting file and was told the backup didn't work that night! We had to restore from a previous day and lost more than a day's work. And that wasn't the first time I'd been told it didn't work.
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.
[/quote]
-
Hence the problem with 3rd party backups. Another link in the chain that can break. SQL to disk is the way to go.
As Steven mentioned, he does not have the capability to do 2000 backups with the 6.5 and 7.0 license they are currently using. Veritas (I believe) will support either 6.5 and 7.0 or 7.0 and 2000. If your environment is really mixed, you have an issue.
Additional selling point besides the greater stability in backup is the $$$ that will be saved by dropping the purchase of the Veritas SQL Agent license. Just tell them to add it to your leads pay check. That will complete the sale.
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
-
BOY does this sound familiar! However, if I was told to report to our Tech Mgr, I would have to quit - and I've been here for 25 years! Our SQL Server databases have been at the middle of a control battle for about 2 years now. I have control over 1 SQL Server (the old applications) and the Tech Mgr is admin over another (a new application) - it's all in 'who you know'. I hope to plead my case to my mgr and the new VP over our dept(and Tech), that I need to be the DBA over all the company databases. Good luck to you!
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?!
[/quote]
-
Excellent point, I didn't realize that the SQL backup for Veritas was an additional cost. Which means, our Tech Mgr just decided on his own that he was going to take over SQL backups, without any discussions with my group, and charged the company for it. interesting........
Hence the problem with 3rd party backups. Another link in the chain that can break. SQL to disk is the way to go.
As Steven mentioned, he does not have the capability to do 2000 backups with the 6.5 and 7.0 license they are currently using. Veritas (I believe) will support either 6.5 and 7.0 or 7.0 and 2000. If your environment is really mixed, you have an issue.
Additional selling point besides the greater stability in backup is the $$$ that will be saved by dropping the purchase of the Veritas SQL Agent license. Just tell them to add it to your leads pay check. That will complete the sale.
David
[/quote]
-
-
quote:
BOY does this sound familiar! However, if I was told to report to our Tech Mgr, I would have to quit - and I've been here for 25 years! Our SQL Server databases have been at the middle of a control battle for about 2 years now. I have control over 1 SQL Server (the old applications) and the Tech Mgr is admin over another (a new application) - it's all in 'who you know'. I hope to plead my case to my mgr and the new VP over our dept(and Tech), that I need to be the DBA over all the company databases. Good luck to you!I must admit that my first thought was 'no way will I work for the Techies'! But unfortunately I have too little experience of SQL Server to look elsewhere - I only picked up the SQL Server responsibility in July, when the previous administrator left, and I guess they only gave it to me because I was already DBA for the VMS based databases! I figure that so long as I stay as stubborn as I am now, and don't give an inch, then the NT experience I gain, as well as the SQL Server experience, should put me on a better footing for looking elsewhere should it turn out to be unbareable!
Edited by - pglover on 12/19/2001 07:46:39 AM
-
A good career move for you.Please come back and ask more questions, we love to help!!!!!!
(also visit some of our sponsors
Steve Jones
-
I have been to a number of companies where they have tried direct to tape backups and none of their backups could be restored.
Strange that this strategy seems to go along with not testing the backups - "the backup to tape worked so it must be OK".
Similar statement to "Microsoft have released it so it must work".
It seems to happen when you leave backups under control of the network department and the database people don't get involved.
I've always wondered how they get to know the correct time to take the backups.
Had a company recently who said that all maintenance of the databases was done by the web hosting company and was part of the contract. This included log shipping to a warm standby. Funny that the databases were truncating the logs - the company still didn't seem to think that the process being impossible meant that it wasn't being done. Turned out the web host didn't have any sql server expertise.
They weren't even copying backups to tape. The test for this was to take a backup of a database ask the web host to copy it to tape and then restore it on the standby server. It was only when I pointed out that the test should be to just pick a days backup to restore that they discovered they were saving them (they didn't tell us - just restored the same one as before).
Cursors never.
DTS - only when needed and never to control. -
That's funny (also not). I've used a couple hosting companies and DataReturn did it the right way. They ran a procedure to backup to disk and then grabbed these to tape. If I called for yesterday's backup, it would appear on the disk in about an hour and I could then retore it.
I completely agree about the network admins, they should be trained on SQL backups or leave it to us.
Steve Jones
-
This posting has produced a lot of good information about backups. Thanks to everyone who replied. It helps to hear from people who have had similar experiences. Hope someday I can reply to a message and help someone else. I'll be checking back now and then. Thanks again and Happy Holidays.
]
-
-
Tape backups when properly managed work great--much faster than backups to disk. We have our servers on switched 100M ethernet and tape backs are really fast. Also it logs the backup event in the SQL logs so you can tell if it is happening or not.
We still do SQL backups to disk when we are doing upgrades, updates, and moves.
Our DBAs do have access to the tape system so that helps.
-
A good career move for you.
Viewing 15 posts - 16 through 30 (of 38 total)
You must be logged in to reply to this topic. Login to reply