September 20, 2006 at 10:00 am
I know no one answered my last post yet, but I have another question...What are the pros and cons of backing up to disk using NetBackup or native sql backups? Is any one better than the other? I would think that sql backups are more reliable and easier to use- is this correct?
Thanks!
Thanks!
September 25, 2006 at 8:00 am
This was removed by the editor as SPAM
September 27, 2006 at 8:08 am
i use Veritas 5 Netbackup for a bunch of servers. Disk is still pretty expensive if you need months or years of backups. We keep 6 months of backups onsite, send out one of the backups every month offsite and routinely restore production db's to QA and other testing. Sometimes we had to restore last month's backup because we needed some data into current production like when an archive script goes haywire and deletes data without archiving it first.
We have a disk based backup system for NT and MS Exchange from Evault but it compresses the data and has other goodies to minimize disk space. Avamar is good too, but expensive.
With tape we have a lot of backups on different tapes. With disk it is possible that you can have your RAID array die on you and lose all your backups. HP's new 300GB drives, we have had half of ours go bad in the last year. Once we had 2 die in the same RAID array in one week. Luckily HP send replacements out next day air and we rebuilt the array after the first failure and just in time for the second. Otherwise it would have been a 500GB archive database down the drain.
July 12, 2007 at 6:58 am
Hi there
has anyone poseted a reply on this sbject.
I am interested on how much diskspace I will need to backup SQL databases via the netbackup agent (and any alternitives that may be better like using flatfile instead)
Thank you
Sue
July 12, 2007 at 10:39 am
Can't tell you about how much disk space would be needed by NetBackup.
I can tell you that the best practice is to use native SQL Server backup commands to back your databases up to disk and then use Netbackup (or other application) to copy the backup files to tape.
We plan on having the same amount of disk space for the backup as we have for the database.
-SQLBill
July 12, 2007 at 9:08 pm
Probably the single most important difference between disk & tape backup is the time to restore. Tape backups take "forever" compared to a restore from disk - and that's if you just happen to have the tape available onsite - worst case you might be looking at several hours to get the tape back onsite before you can even begin your restore.
I typically advocate a dump & sweep approach to database backups with a nominal retention on disk and longer term retention on tape. Reality is that most database backups are useless beyond a couple of days - would you want to have to tell the business that they have to redo several days of transactions? Me neither.
The biggest problem with most "enterprise" backup systems like Veritas is that they are only capable of taking backups of the database each night (if you're lucky) and frequently only able to take a full backup of "everything" over the weekend which is just fine if you're backing up a database that is only updated once a month but just doesn't cut it when you need to be able to recover to within a shorter timeframe (e.g. 10 minutes).
Joe
July 13, 2007 at 1:15 am
Better backup the database to disk and then move the backup file to TAPE. SO that you can restore it on need. But plan this as each file will take disk space may be you can have last 3 days backup files on disk.
Cheers,
Sugeshkumar Rajendran
SQL Server MVP
http://sugeshkr.blogspot.com
July 13, 2007 at 7:00 am
Hello,
SQL->DISK->TAPE is hardly a "best practice". It is merely one way of doing it. It can be difficult to manage and easily becomes unmanageable when there are simply too many databases and/or servers to support. It works great in small deployments and that's what I will often choose for clients if it is the right fit. It can also give you more precise control over timing, if the business need is there, so it can be useful in large envioronments as well.
NetBackup is expensive, but you get what you pay for. It is an excellent tool for SQL backups. It's difficult to get set up correctly, but it works flawlessly once it is ready. It also has the benefit of keeping all of your enterprise backups in one place, which may very well be a requirement dictated by people whose names are on the front of the building.
So, it depends. Go with what is best for your situation.
July 13, 2007 at 7:13 am
A few other points in favour of backing up to disk ...
Everywhere I've worked as a DBA, doing backups this way neatly mirrors the departmental structure in that the DBA manages the backups to disk and the Windows Server guys manage the backups to off-line media. i.e. they don't fiddle with my databases and I don't go near their tape drives !
For most network backup solutions, you will need to buy an additional item of licenced software in order to back up your SQL Server databases directly. Backing up first to disk means this is not necessary. If you have a lot of servers this can be a big saving.
It can be difficult managing your SQL Agent schedule when you have backups taking place outside of that schedule at a time which may vary from day to day. The network backup software optimises the schedule to keep the tape drives loaded appropriately and knows nothing about your servers batch workload. If you back up to disk first this dependancy is broken.
The only good reason (IMHO) to back up your databases directly with a network backup solution is if you have very large databases and the cost of disk space is an issue. I'm forced down this route with a few servers but make sure if you go this way that you carry out regular test restores (you should anyway but in this case it becomes even more important because there are more potential points of failure).
July 13, 2007 at 8:37 am
Phil's "very large database" are a great example of why compression products like SQL Safe, SQL Backup & Litespeed are usually a great addition to your toolset - they will usually pay for themselves pretty darn quickly as the compressed backups take up anywhere from 35 - 90% less space... I don't know if any of those products will work in conjunction with Netbackup or other backup software to backup direct to tape? I do know that the last time I priced Idera's product it was actually cheaper on a per machine basis than the corresponding Netbackup SQL Server agent.
Joe
July 13, 2007 at 8:43 am
LiteSpeed is another awesome product for backups. I've used it where the performance results justified the cost. It is pretty expensive, but again you get what you pay for.
IIRC, LiteSpeed will work natively with TSM, but not with NetBackup. I don't know about any of the other compression-capable products.
September 10, 2013 at 8:47 am
My environment is very large and we use Netbackup to backup a lot of servers and it works well, for the most part. One concern I do have is that we use a VTL with de-dupe and that means that you can't use naitive SQL compression when you are backing up large databases. This causes more of a network bottleneck.
Another concern is handling failed backups as the database backups are spread across three teams. Windows Admins load the Netbackup agents, DBA sets up the SQL agent scripts and the SAN/UNIX team schedules the jobs. It can make root failure analysis difficult.
January 26, 2015 at 8:10 am
I know this reply is quite a bit of time after the post, however, where can I find documentation that native SQL backup followed by copy to media using Netbackup is best practice? I agree with the idea, but the higher ups need more than my word.
January 26, 2015 at 8:32 am
I was wondering the same thing. This seems to be an ongoing issue.
February 3, 2015 at 2:11 pm
pshore73 (1/26/2015)
I know this reply is quite a bit of time after the post, however, where can I find documentation that native SQL backup followed by copy to media using Netbackup is best practice? I agree with the idea, but the higher ups need more than my word.
It's a preferred practice that I've used since SQL 4.21a in the mid(?)-'90s. It's simple, and it requires nothing more than what comes in SQL Server and the OS. If you're running a later version and certain editions of SQL Server, you can enable backup compression and save a lot of space on the backups. This method does require disk space, but it's the cleanest and simplest backup methodology. It also gives you a local copy of the database that you can do test restores with to make sure that the backup is readable.
Since database files are locked, they can't normally be backed up as a whole. SQL Server doing a database/log backup ensures transactional consistency. There are backup programs that can go in to the database and back it up while it's up and running, but I've seen performance and locking hits with these in the past and I don't really trust them. I don't know what the current state of the art are on those and whether those issues have improved. Without doing SQL backups or using an agent, your only other reasonable backup methodology would be to take the database offline and then backup the actual database files. This is not a practical solution.
My question would be what do the higher ups think is a good way do to backups? You don't need any extra money spent on additional software to do backups this way. Just make sure your backups can be restored to another database and that you're also properly doing transaction log backups.
I have been on the losing side of this argument. A previous infrastructure manager wanted to use whatever enterprise backup tool he had to back up databases directly, and eventually the IT manager sided with him. One of the things that I didn't like about that approach was I didn't have consistent backup times, which risked running at the same time as my DBCCs, and I didn't want both things running at once. In the end I really didn't care, I was on my way out the door anyway. And then my replacement quit a few months later, so I have no idea what their status is and whether or not their backups are restorable and frankly I don't care. 😉
Redgate's SQL Backup Pro is very popular among a lot of people on this site, and if I had a really big and important data store I'd definitely consider it. But most of the databases that I work with are just fine with SQL backups/OS move to media.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply