December 29, 2011 at 10:05 am
SQLRNNR (12/29/2011)
GilaMonster (12/29/2011)
Grant Fritchey (12/29/2011)
GilaMonster (12/29/2011)
Grant Fritchey (12/27/2011)
Based on the fact that we can't get people to run good sets of backups despite Umptymillion articles, blog posts, presentations, webcasts and screaming lightning talks, I don't think you're going to be giving away the secrets of the universe.You mean like this: http://www.sqlservercentral.com/Forums/Topic1227066-146-1.aspx
It's just creepy. Seriously creepy just how often this occurs. You keep thinking that people will learn but they never seem to without having a giant wall fall on them first.
Some don't learn even after having a wall fall on them. I recall someone from SQLTeam posted a corrupt DB problem every couple of weeks, all weird and nasty corruption, never had a backup once.
Maybe the wall fell on them too many times?
They might be waiting for ‘The Great Wall of China’ (major data loss) to fall down on them.
December 29, 2011 at 10:09 am
Stefan Krzywicki (12/29/2011)
GilaMonster (12/29/2011)
Stefan Krzywicki (12/29/2011)
I don't have room on my machine either.Two words: External harddrive.
Seriously, I've had to do that once or twice.
I can't even get them to buy that. : -(
I thought SQL Server files had to be on an internal drive unless they were on a SAN. I must be mis-remembering something.
So they are saying the data isn't worth $100? 🙂
Seem to recall some kind of limitation like that too, although extra disk allows for creative workarounds.
December 29, 2011 at 10:14 am
GSquared (12/29/2011)
GilaMonster (12/29/2011)
Stefan Krzywicki (12/29/2011)
I don't have room on my machine either.Two words: External harddrive.
Seriously, I've had to do that once or twice.
I've done that too.
Once had the backups for the production database server going to a USB drive, too. Cheap, and it worked, but it was hardly "enterprise class".
And I just found out that EMC, which handles our backups and restores, can't see external drives.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
December 29, 2011 at 10:20 am
Stefan Krzywicki (12/29/2011)
GilaMonster (12/29/2011)
Stefan Krzywicki (12/29/2011)
I don't have room on my machine either.Two words: External harddrive.
Seriously, I've had to do that once or twice.
I can't even get them to buy that. : -(
I thought SQL Server files had to be on an internal drive unless they were on a SAN. I must be mis-remembering something.
You're thinking file shares (and even that works in the latest version).
External drive's not the best place to keep database files (generally slower, not redundant), but for a restore check it's better than nothing. One place I bought a drive myself (own money) and used that.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 29, 2011 at 10:28 am
Grant Fritchey (12/29/2011)
Stefan Krzywicki (12/29/2011)
GilaMonster (12/29/2011)
Stefan Krzywicki (12/29/2011)
I don't have room on my machine either.Two words: External harddrive.
Seriously, I've had to do that once or twice.
I can't even get them to buy that. : -(
I thought SQL Server files had to be on an internal drive unless they were on a SAN. I must be mis-remembering something.
I've been using my external drive for testing. What I've found is that rebooting the machine can be problematic of SQL Server starts automatically. The drive isn't always available and you get corrupt databases. Not pretty. But as long as you're just talking a testing platform, it should be fine.
Not such a big deal if SQL Server service is set to start manually instead of automatically. That's how my home computer is set up, and it works.
But, like you said, only for testing or proof-of-concept work. Wouldn't do the USB data drive thing on a real server.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 29, 2011 at 10:30 am
GilaMonster (12/29/2011)
Stefan Krzywicki (12/29/2011)
GilaMonster (12/29/2011)
Stefan Krzywicki (12/29/2011)
I don't have room on my machine either.Two words: External harddrive.
Seriously, I've had to do that once or twice.
I can't even get them to buy that. : -(
I thought SQL Server files had to be on an internal drive unless they were on a SAN. I must be mis-remembering something.
You're thinking file shares (and even that works in the latest version).
External drive's not the best place to keep database files (generally slower, not redundant), but for a restore check it's better than nothing. One place I bought a drive myself (own money) and used that.
I am sorry but I can’t control my LOL & ROFL now. :hehe:
December 29, 2011 at 10:32 am
Stefan Krzywicki (12/29/2011)
GSquared (12/29/2011)
Dev (12/29/2011)
I thought some "Magic" (recovery trick) will happen & that DB will be saved. It’s a nice learning opportunity that I missed. However the lessons learnt today (reminder actually), keep your DB and Backups in good shape & ensure it with proper restoration scenarios Else nobody (even experts here) can help.Yep. No substitute for tested backups. Simple as that.
Speaking of which, where do you all test your backups? Prod Server, Dev Server, Test Server, special server just to test backup restores?
Dev, Test, QC.
We have a daily restore to QC that contains production data for the Devs and analysts to query on if the business users report problems. Those are restored daily.
At least once a week, we restores the DBs down to the other environments as part of our SDLC and regression testing. It works pretty well for a "backup test" even though that's not what the primary purpose is. We've caught a few corrupted production backups in the process and been able to run a new, uncorrupted backup in a timely manner.
December 29, 2011 at 10:36 am
Question for those of you commenting on external drives. The few times I have tried it (both on a local db on my laptop and from a server remotely), I have been unable to get it to work. Plenty of space on the usb-connected drive, but SQL just errors out when I try to do it with a "not enough space" error.
Any thoughts on what I'm doing wrong?
December 29, 2011 at 11:17 am
Brandie Tarvin (12/29/2011)
Question for those of you commenting on external drives. The few times I have tried it (both on a local db on my laptop and from a server remotely), I have been unable to get it to work. Plenty of space on the usb-connected drive, but SQL just errors out when I try to do it with a "not enough space" error.Any thoughts on what I'm doing wrong?
What kind of I/O throughput and latency do you get on the drive?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 29, 2011 at 11:31 am
Brandie Tarvin (12/29/2011)
Question for those of you commenting on external drives. The few times I have tried it (both on a local db on my laptop and from a server remotely), I have been unable to get it to work. Plenty of space on the usb-connected drive, but SQL just errors out when I try to do it with a "not enough space" error.Any thoughts on what I'm doing wrong?
Just a few thoughts:
External drives are insufficient - think a fire in the computer room.
USB drives are slow and they represent security risk. Our prod servers have USB ports disabled even when they are kept in a secure space.
Which leaves network drives as the most viable option - if you have a fast network.
I know a place where they are using a tape drive (yes, a tape drive) that backs up the business-critical database(s) around 2 AM and then spits the tape on a stainless steel slide that goes into an adjacent room. The tape slides into a fire-proof container that is right under sprinklers and guaranteed to withstand any fire, even without sprinklers, for two hours.
December 29, 2011 at 11:34 am
Revenant (12/29/2011)
Just a few thoughts:External drives are insufficient - think a fire in the computer room.
USB drives are slow and they represent security risk. Our prod servers have USB ports disabled even when they are kept in a secure space.
Which leaves network drives as the most viable option - if you have a fast network.
I suggested them as a place to do test restores of databases when there's no other available space (even on test, dev or local machines), not as a backup solution.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 29, 2011 at 11:37 am
Revenant (12/29/2011)
Brandie Tarvin (12/29/2011)
Question for those of you commenting on external drives. The few times I have tried it (both on a local db on my laptop and from a server remotely), I have been unable to get it to work. Plenty of space on the usb-connected drive, but SQL just errors out when I try to do it with a "not enough space" error.Any thoughts on what I'm doing wrong?
Just a few thoughts:
External drives are insufficient - think a fire in the computer room.
USB drives are slow and they represent security risk. Our prod servers have USB ports disabled even when they are kept in a secure space.
Which leaves network drives as the most viable option - if you have a fast network.
I know a place where they are using a tape drive (yes, a tape drive) that backs up the business-critical database(s) around 2 AM and then spits the tape on a stainless steel slide that goes into an adjacent room. The tape slides into a fire-proof container that is right under sprinklers and guaranteed to withstand any fire, even without sprinklers, for two hours.
I once worked at a place that had the opposite of that setup.
The server room shared a wall with the kitchen. The server was on the opposite side of the wall from the stove. Backups were done randomly and infrequently and occasionally someone would take one of them home for safe-keeping.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
December 29, 2011 at 11:41 am
Stefan Krzywicki (12/29/2011)
Revenant (12/29/2011)
Brandie Tarvin (12/29/2011)
Question for those of you commenting on external drives. The few times I have tried it (both on a local db on my laptop and from a server remotely), I have been unable to get it to work. Plenty of space on the usb-connected drive, but SQL just errors out when I try to do it with a "not enough space" error.Any thoughts on what I'm doing wrong?
Just a few thoughts:
External drives are insufficient - think a fire in the computer room.
USB drives are slow and they represent security risk. Our prod servers have USB ports disabled even when they are kept in a secure space.
Which leaves network drives as the most viable option - if you have a fast network.
I know a place where they are using a tape drive (yes, a tape drive) that backs up the business-critical database(s) around 2 AM and then spits the tape on a stainless steel slide that goes into an adjacent room. The tape slides into a fire-proof container that is right under sprinklers and guaranteed to withstand any fire, even without sprinklers, for two hours.
I once worked at a place that had the opposite of that setup.
The server room shared a wall with the kitchen. The server was on the opposite side of the wall from the stove. Backups were done randomly and infrequently and occasionally someone would take one of them home for safe-keeping.
Are they still in business? :w00t:
December 29, 2011 at 11:43 am
Stefan Krzywicki (12/29/2011)
Revenant (12/29/2011)
Brandie Tarvin (12/29/2011)
Question for those of you commenting on external drives. The few times I have tried it (both on a local db on my laptop and from a server remotely), I have been unable to get it to work. Plenty of space on the usb-connected drive, but SQL just errors out when I try to do it with a "not enough space" error.Any thoughts on what I'm doing wrong?
Just a few thoughts:
External drives are insufficient - think a fire in the computer room.
USB drives are slow and they represent security risk. Our prod servers have USB ports disabled even when they are kept in a secure space.
Which leaves network drives as the most viable option - if you have a fast network.
I know a place where they are using a tape drive (yes, a tape drive) that backs up the business-critical database(s) around 2 AM and then spits the tape on a stainless steel slide that goes into an adjacent room. The tape slides into a fire-proof container that is right under sprinklers and guaranteed to withstand any fire, even without sprinklers, for two hours.
I once worked at a place that had the opposite of that setup.
The server room shared a wall with the kitchen. The server was on the opposite side of the wall from the stove. Backups were done randomly and infrequently and occasionally someone would take one of them home for safe-keeping.
Rigged correctly, you could probably use the excess heat from some server rooms to help with the cooking...
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 29, 2011 at 11:43 am
GSquared (12/29/2011)
Brandie Tarvin (12/29/2011)
Question for those of you commenting on external drives. The few times I have tried it (both on a local db on my laptop and from a server remotely), I have been unable to get it to work. Plenty of space on the usb-connected drive, but SQL just errors out when I try to do it with a "not enough space" error.Any thoughts on what I'm doing wrong?
What kind of I/O throughput and latency do you get on the drive?
That's a good question. I'm not sure. One drive is a 320 GB Toshiba USB drive (4 x 3 inches and about 1 inch thick). Another is an Edge DiskGo. Neither drive has stats on them, both plug in solely via USB.
RE: Revenant's comments about latency, etc. These are small, personal databases on my SOHO that I'm trying to move between laptop / PC (faux server) so that I can play with SQL when I'm away from home. These are not work DBs, so I don't have to worry about security, blocked USB ports, or any of those issues.
Viewing 15 posts - 32,971 through 32,985 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply