Sure. We used to do it this way, but as some of our databases grew in size and complexity the native backup utility started taking longer to backup the transaction logs than the specified RPO. At that point we had to switch to a 3rd party SQL backup utility.
One last thing, have you done test restores to make sure everything is working the way you want? I can't stress enough the importance of this, both in the beginning and on an ongoing, go-forward basis. (Sorry KB, couldn't resist...) RS From: James Kerr [mailto:[email protected]] Sent: Tuesday, September 29, 2009 11:20 AM To: NT System Admin Issues Subject: Re: Am I backing up SQL correctly? Good to know, thanks. James ----- Original Message ----- From: Richard Stovall <mailto:[email protected]> To: NT System Admin Issues <mailto:[email protected]> Sent: Tuesday, September 29, 2009 11:14 AM Subject: RE: Am I backing up SQL correctly? That is a perfectly valid and inexpensive way to do it, though you might want to evaluate the type and frequency of your SQL-native backups to ensure that you can meet your recovery point objective. (http://en.wikipedia.org/wiki/Recovery_point_objective) RS From: James Kerr [mailto:[email protected]] Sent: Tuesday, September 29, 2009 11:09 AM To: NT System Admin Issues Subject: Am I backing up SQL correctly? I have an MS SQL 2003 database that I backup by having it run its own backup of the databases and it creates .bak files. Then later on in the evening I have BE backup those .bak files to tape. These .bak files should allow me to restore a database right? James ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
