| Author |
Topic |
|
rb1373
Yak Posting Veteran
93 Posts |
 Posted - 2005-04-05 : 11:29:31
|
| Does anyone have anything (e.g., Microsoft link) stating that network backups are not recommended by Microsoft? I'm trying to convince my boss that we need to create a backup locally then copy the BAK file across the network, especially for a VLDB.Thanks,Ray |
|
|
mr_mist
Grunnio
1870 Posts |
Posted - 2005-04-05 : 11:35:37
|
| Just set it up. It will fail, and that's about all the justification you should need.-------Moo. :) |
 |
|
|
jason
Posting Yak Master
164 Posts |
Posted - 2005-04-05 : 18:06:42
|
It won't necessarily fail. It's not reliable though. Try to define in terms of your time in $$ should something go wrong. It's hard enough troubleshooting a backup problem locally let alone across the OSI model. If you expect large databases, you can bet you'll run across backup window issues as well.  uphttp://support.microsoft.com/default.aspx?scid=kb;en-us;555128 |
|
|
|
jason
Posting Yak Master
164 Posts |
Posted - 2005-04-05 : 18:13:24
|
| Thought I'd add this.If your backup does fail and you have to call Microsoft (disaster!), it's not like they'll pay for any lost revenue. There's a reason UNC paths aren't enabled by default. |
|
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2005-04-05 : 20:07:44
|
| ?? What are you talking about Homer? UNC paths are enabled by default. You just need the appropriate permissions to access the network share. Didn't you read that article link? I'm going to disagree with everyone here. There are times when backups over the network make sense. If you have a LOT of backups spread throughout the environment, they are much more difficult to manage and provide space for. This is especially true when you consider the enterprise need to backup, audit, move to tape, etc. There's no reason that traffic for backups can't be managed over a network effectively and well though. It cost some time and planning; however, long-term it can solve a lot of issues and be a much more costly solution that's just as reliable.MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
|
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2005-04-05 : 21:56:14
|
| For a VLDB, backing up to disk and then going across the network is going to be much faster and more reliable. Like the others have said, there's a good reason why it's not easy to do, because MS doesn't want you to do it.Michael<Yoda>Use the Search page you must. Find the answer you will.</Yoda> |
|
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2005-04-05 : 23:49:12
|
| It's not that hard to do. I agree that in a best case scenario you back up to local disk, especially if it's a VLDB. It's not practical though in every environment. That's all I was trying to point out. And, I disagree that backing up to local disk is ALWAYS "much faster" and more reliable. With the proper network setup for a SQL Server environment, you get just as much reliability by having a really good disk/server system to back up to. With a proper switch/network configuration you're going to be looking at very minimal time differences in backup over network. In cases where there are 20,30, or even hundreds of disparate servers in a data center, having a consolidated place to manage, collect, integrate with tape solutions, etc can make a LOT of sense. In addition, the cost of maintaining this vs. maintaining seperate disks systems on every single disparate system makes the any small loss in speed (and it is small with the right setup) easily worth the price.Just think about this before you reply. It's easy to use our blanket replies and just say people are thoughtless idiots. Not every situation is the same though, and sometimes the blanket statements we've heard need to at least be thought about from an object view.And, last I'm going to disagree with "there's a good reason why it's not easy to do, because MS doesn't want you to do it."That's a BS answer with no founding. It's not that hard. Matter of fact, it's extremely easy. If you want to prove a point don't throw crap out there like that. You have some good points, but make the points.MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
|
|
|
jen
Master Smack Fu Yak Hacker
4110 Posts |
Posted - 2005-04-06 : 01:19:43
|
| why don't you try it for yourself,monitor a network backup against a file backup then network copythen decide, each need is different, we have mixed backups, network and disk Network: because the disk space is not enough for the backups and adding disks is not the solution, i don't really trust direct tape backups. Also less work and if backup file is smaller than 5 GB- had some problems where connection is not stable and ofcourse the backup will failDisk: for servers which can afford disk backups (2 weeks worth of backup files) and need to restore the fastest--------------------keeping it simple... |
|
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2005-04-06 : 01:23:53
|
| I've done it different in every environment that I have managed. Each time, it was based on tests, costs, and overall business need. Good point Jen. I really like the consolidated environment when you look at large enterprises though.MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
|
|
|
jason
Posting Yak Master
164 Posts |
Posted - 2005-04-06 : 10:32:41
|
I use the network in some situations as well. I agree it can be more cost effective. That's why Microsoft allows it. Duh.Even with a GB Ether though, large databases will cause issues backing up accross network. I don't think I got that wrong BartO.  Also, there's nothing wrong with a backup strategy that keeps it simple and predictable. Right? |
|
|
|
|
info on unsupported network backups