Best Practice Backing Up SQL Databases
Updated: 21 May 2010 | 9 comments
This issue has been solved. See solution.
Hi Guys,
I've recently had a phone call with Symantec support to try an diagnose a Snapshot Processing problem and during the phone call the engineer advised us to separate our SQL DB backups from our AOFO File System backups. This seems a little odd to me - so does any one have any advice or comments about doing this? We want the simplist solution - so keeping as much as possible in the one job is preferable.
Thanks in advance,
Chris
discussion Filed Under:
Comments
http://seer.entsupport.symant
http://seer.entsupport.symantec.com/docs/285757.htm
Yep, don't use AOFO when backing up SQL. We were doing this on 1 of our sites, and couldn't redirect the restore to another server. We had to create a test database on the same server, and restore to that.
If you find this is a solution, please mark it as such.
Hi, Have you come right with
Hi,
Have you come right with this?
If you find this is a solution, please mark it as such.
Yes, I am now ignoring the
Yes, I am now ignoring the advice of the Symantec Support Technician. We now no longer use AOFO as we don't need to backup files when they are in use and our SQL backups are in the same job as the file system backups. Keeping things simple and manageable is far more important to us than use a specific technology. While it would be nice to use AOFO it caused too much grief and sticking with what we know works far more reliably - it if isn't broken don't fix it. The front line Symantec engineers seem to all read from the same script and always tell you to use AOFO which just isn't the case.
Chris
Keeping things simple and
Keeping things simple and manageable is far more important to us than use a specific technology. While it would be nice to use AOFO it caused too much grief and sticking with what we know works far more reliably - it if isn't broken don't fix it.
I agree with that wholeheartedly. If you can get by without using a specific option or agent, then life tends to me much simpler without it.
IDR and AOFO - I'm looking at you!
http://www.backupexecfaq.com
RE:
I agree with that wholeheartedly. If you can get by without using a specific option or agent, then life tends to me much simpler without it.
IDR and AOFO - I'm looking at you!
Amen Brother!
If this response answers your concern, please mark it as a "solution"
Lol...glad you came right
Lol...glad you came right though, and that it's at least solved.
If you find this is a solution, please mark it as such.
Normally you would create a
Normally you would create a job with all of your SQL jobs, one for all of your Exchange, etc... Using the respective agents and NO AOFO
Then create subsequent jobs for your servers, AND AOFO, but de-selecting the databases that were done in the above step.
You can also go and group the same OS's into the same jobs too, or clusters into the same jobs.
Grouped/organized jobs, only adds to simplicity. :-)
There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."
Chris: If that solved it, can
Chris: If that solved it, can you mark it as such? Laters =)
If you find this is a solution, please mark it as such.
No prob. Done. teiva-boy - I
No prob. Done.
teiva-boy - I guess it depends on the environment - we are a fairly small setup (20 servers) so for us the fewer jobs there are the better - less to keep an eye on, fewer backups to make sure are completing - fewer tapes to manage - easier scheduling of backup jobs - most importantly fewer things to manage if we need a restore and a better understanding of when the last authoritative full backup completed successfully. If I had 10 Exchange servers, 10 SQL servers etc, then I might want to do things differently.... but your right in that the key is in being organised :)
Would you like to reply?
Login or Register to post your comment.