Some were, some weren't. He learned about "no service password-recovery" and thought that was sufficient to keep people from messing with the device and so saved the config. But not all devices support that. And we don't know which are setup like that and which aren't. I'm not rolling those dice.
Nope. He was arrested for failing to return City property -- namely the password(s), but in searching his house, he still had other City property. (the facts are far more complicated than we'll ever know.) Had he simply turned over the password(s) (in person, in writing) upon termination, there'd be no story. Instead, he was an ass and refused to give the password(s) to any of his "idiot" (former) coworkers/bosses. To be fair, his boss(es) do share some of the blame for letting things get like this to begin with.
We don't know what state each device was in. He did have some systems setup with no, or minimal, boot config. Others had recovery disabled. Rebooting them is asking for trouble.
My quick back-of-napkin math... I can build a 100TB storage system in one 42U rack for ~150k -- and that's with "enterprise" 450G 15k RPM SAS drives. It'll draw around 5Kw meaning it'll cost sub-10k$ per year to run. (cooling requirements not included. but assuming 5ton would do: $30k for the system, $10k/yr to run it.)
I didn't see anything wrong with the way he handled his gun; he wasn't pointing it at anyone. However, drawing his gun, and in fact his involvement at all, were not necessary. There were marked, uniformed officers right behind him. They're on the clock; let them do the job they're being paid to do. An off duty officer, out of uniform and in his own personal car, simply put has no business getting involved. If you want to be a witness, fine, let the cops do their job; they'll come get you when they need your statement.
All the way up to the day after Oracle took over. Remember "patchPro"? "smpatch"? Yes, there were contract only patches, but they were rare and generally fixed issues few people had (or needed fixed.)
For the record, I gave up on Solaris with the bastardized crap that is "Solaris 10". SMF! "We don't use shell scripts anymore." -- bullshit, they just aren't in etc anymore. And it smells too much like the Windows Registry.
The more recent sun machines... are "PCs" -- AMD and Intel (Xeon) based. The one's actually made by Sun -- the earlier ones weren't, btw -- are nice hardware. But they aren't exactly cheap. And in the Oracle world, you need a support contract just to see a picture of one. 4 year old BIOS updates -- that had always been free -- now require a contract. Documentation of any kind now requires you login -- even for free crap.
Maybe. But I'd doubt they have a cablecard slot; almost no TVs on the market bother with it anymore -- SDV made it useless and the consumer electronics industry isn't going to play cable's game of whack-a-mole.
Nothing. The rule only states local channels have to be available. There is nothing stating they have to be free or analog (in a digital only system.) If you don't have a "digital cable ready" TV, you'll need a box. And that box is not free.
They can do this. They will do this. And there is nothing you can do to stop it.
(And only an idiot would try. Those analog stations waste a lot of space.)
The word people are omitting is "encryption". Most MSOs will encrypt everything they legally can. This means the only thing you can see without a cable box or cablecard are broadcast channels. And the FCC have been pussing out and granting wavers to encrypt those too.
There are ZERO regualtions one way or the other. Most MSOs continue to broadcast analog channels to prop up their fees for digital cable while claiming it's to not lose the "millions" of analog only subscribers (or force them to rent a box, which is exactly what's happening here.)
In fact, there is significant pressure to kill analog entirely. Those channels eat a fantastic amount of space.
NTFS is the worst option. It was NEVER intended to be a removable filesystem, even less a portable filesystem. For drives that only get used on the same computer, it'll work. However, the instant you transport any drive to other computers, you will start having problems from ACLs -- if you're using XP Home, you have no simple way to fix it. This is esp. true of systems that aren't part of the same domain since every system will have a unique set of users.
The guest OS has to have vmware tools running for the backup to work correctly. i.e. the VM has to be prepared to be backed up. And if there are things like a database running inside that VM, they have to be prepared for backup too. Simply copying the files out from under a running VM is a recipe for complete disaster.
Heh. I still have both in production -- I sometimes wish I didn't, but the feeling passes when I think about how much mess it is to replace them.
(In fact, I still have an NT 4.0 machine and a linux machine with a 2.3 kernel on it; 'tho I'm surprised their hard drives still work -- SCSI for the win.)
I have to call complete bullshit on you tape FUD. Modern enterprise class tape systems (DDS, AIT, Mammoth, DLT, SDLT, and LTO) are designed to last decades. And DO. I've never had any problems moving any of those formats between drives -- even of different ages and manufacturers. For (S)DLT and LTO, unless you throw the tapes hard enough to case physical damage to the case, the tape inside it will be 100% uneffected. 4mm and 8mm tapes aren't as sturdy, but as long as the tape isn't physically damaged, it'll still be readable.
There are and have been a lot of crap tape systems out there. However, it only takes a few minutes to figure out they're crap and avoid them. For example, QIC-80 which has all the problems you just described. In most cases, the tape is unreadable by the time you finish writing it. When it is readable, it'll only be readable in the same drive. Mere shaking can make the tape align differently on the head rendering it unreadable. That's why no one used that crap for very long.
Buy quality technology and it'll work for years. Hard drives just don't last that long -- esp. the cheap ones. The cost of sending a single drive to a data recovery house will easily pay for a tape backup system.
Yes, NASA. They had numerous tapes from the Apollo days with no drives to read them and no one who knew how they were written. The encoding is just as important as the device.
Tapes clearly have the win in longevity. However, failing to keep the hardware necessary to read them can be a huge headache.
First problem... availability. Metro-E isn't available everywhere. The second problem... cost. This is the ever moving target in the equation. I've (sadly) found traditional tariffed services to be cheaper than the non-tariffed newcomers. Of course, I live in the territory of the stupid and lazy -- Bellsouth and Timewarner. (no matter who your ISP is, one (or both) of them will be involved.)
And your problem was 100% "VXA". That's not enterprise technology -- it's just cheap all the way around. Lemme guess, their previous backup tech was QIC-80 and Travan?
That depends on what you see as a revision. SCSI-1, SCSI-2, SCSI-3, FC-1, FC-2, FC-3,... and those are just command protocols. Async, Sync 5, 10, 20, 40, 80, 160, narrow, wide,... Just in the SCSI world. How many different IDE protocols, speeds, and modes are there? PIO modes, DMA modes, Ultra DMA modes, ATA-X standards. Hard drive tech evolves just as fast as tape.
Plus, you'd be in deep sh*t when you got a drive back from storage to find it 100% completely unusable. HD are fine for online storage when coupled with periodic scrubbing, but for offline storage they are the most unreliable thing in the universe. (well, maybe not the worst, but pretty high up on the list.)
Slashdot Mirror
Some were, some weren't. He learned about "no service password-recovery" and thought that was sufficient to keep people from messing with the device and so saved the config. But not all devices support that. And we don't know which are setup like that and which aren't. I'm not rolling those dice.
Nope. He was arrested for failing to return City property -- namely the password(s), but in searching his house, he still had other City property. (the facts are far more complicated than we'll ever know.) Had he simply turned over the password(s) (in person, in writing) upon termination, there'd be no story. Instead, he was an ass and refused to give the password(s) to any of his "idiot" (former) coworkers/bosses. To be fair, his boss(es) do share some of the blame for letting things get like this to begin with.
We don't know what state each device was in. He did have some systems setup with no, or minimal, boot config. Others had recovery disabled. Rebooting them is asking for trouble.
... until you reboot the web server and don't have the password to the ssl cert. That's the beginning of a Bad Day(tm).
My quick back-of-napkin math... I can build a 100TB storage system in one 42U rack for ~150k -- and that's with "enterprise" 450G 15k RPM SAS drives. It'll draw around 5Kw meaning it'll cost sub-10k$ per year to run. (cooling requirements not included. but assuming 5ton would do: $30k for the system, $10k/yr to run it.)
I didn't see anything wrong with the way he handled his gun; he wasn't pointing it at anyone. However, drawing his gun, and in fact his involvement at all, were not necessary. There were marked, uniformed officers right behind him. They're on the clock; let them do the job they're being paid to do. An off duty officer, out of uniform and in his own personal car, simply put has no business getting involved. If you want to be a witness, fine, let the cops do their job; they'll come get you when they need your statement.
All the way up to the day after Oracle took over. Remember "patchPro"? "smpatch"? Yes, there were contract only patches, but they were rare and generally fixed issues few people had (or needed fixed.)
For the record, I gave up on Solaris with the bastardized crap that is "Solaris 10". SMF! "We don't use shell scripts anymore." -- bullshit, they just aren't in etc anymore. And it smells too much like the Windows Registry.
The more recent sun machines... are "PCs" -- AMD and Intel (Xeon) based. The one's actually made by Sun -- the earlier ones weren't, btw -- are nice hardware. But they aren't exactly cheap. And in the Oracle world, you need a support contract just to see a picture of one. 4 year old BIOS updates -- that had always been free -- now require a contract. Documentation of any kind now requires you login -- even for free crap.
Maybe. But I'd doubt they have a cablecard slot; almost no TVs on the market bother with it anymore -- SDV made it useless and the consumer electronics industry isn't going to play cable's game of whack-a-mole.
Nothing. The rule only states local channels have to be available. There is nothing stating they have to be free or analog (in a digital only system.) If you don't have a "digital cable ready" TV, you'll need a box. And that box is not free.
They can do this. They will do this. And there is nothing you can do to stop it.
(And only an idiot would try. Those analog stations waste a lot of space.)
The word people are omitting is "encryption". Most MSOs will encrypt everything they legally can. This means the only thing you can see without a cable box or cablecard are broadcast channels. And the FCC have been pussing out and granting wavers to encrypt those too.
There are ZERO regualtions one way or the other. Most MSOs continue to broadcast analog channels to prop up their fees for digital cable while claiming it's to not lose the "millions" of analog only subscribers (or force them to rent a box, which is exactly what's happening here.)
In fact, there is significant pressure to kill analog entirely. Those channels eat a fantastic amount of space.
NTFS is the worst option. It was NEVER intended to be a removable filesystem, even less a portable filesystem. For drives that only get used on the same computer, it'll work. However, the instant you transport any drive to other computers, you will start having problems from ACLs -- if you're using XP Home, you have no simple way to fix it. This is esp. true of systems that aren't part of the same domain since every system will have a unique set of users.
See Also: VMware consolidated backup
The guest OS has to have vmware tools running for the backup to work correctly. i.e. the VM has to be prepared to be backed up. And if there are things like a database running inside that VM, they have to be prepared for backup too. Simply copying the files out from under a running VM is a recipe for complete disaster.
Heh. I still have both in production -- I sometimes wish I didn't, but the feeling passes when I think about how much mess it is to replace them.
(In fact, I still have an NT 4.0 machine and a linux machine with a 2.3 kernel on it; 'tho I'm surprised their hard drives still work -- SCSI for the win.)
This is just a matter of "words". In windows a "volume" is any mounted filesystem. The underlying storage system is pretty much irrelevant.
The primary reason for keeping a snapshot online is to avoid the delay in having to go back to tape for a single file some moron deleted.
Otherwise, yes, older snapshots should eventually be deleted, just like tape cycling.
Actually, there are dozens of projects that have (most likely) already mapped your SSID.
I have to call complete bullshit on you tape FUD. Modern enterprise class tape systems (DDS, AIT, Mammoth, DLT, SDLT, and LTO) are designed to last decades. And DO. I've never had any problems moving any of those formats between drives -- even of different ages and manufacturers. For (S)DLT and LTO, unless you throw the tapes hard enough to case physical damage to the case, the tape inside it will be 100% uneffected. 4mm and 8mm tapes aren't as sturdy, but as long as the tape isn't physically damaged, it'll still be readable.
There are and have been a lot of crap tape systems out there. However, it only takes a few minutes to figure out they're crap and avoid them. For example, QIC-80 which has all the problems you just described. In most cases, the tape is unreadable by the time you finish writing it. When it is readable, it'll only be readable in the same drive. Mere shaking can make the tape align differently on the head rendering it unreadable. That's why no one used that crap for very long.
Buy quality technology and it'll work for years. Hard drives just don't last that long -- esp. the cheap ones. The cost of sending a single drive to a data recovery house will easily pay for a tape backup system.
Yes, NASA. They had numerous tapes from the Apollo days with no drives to read them and no one who knew how they were written. The encoding is just as important as the device.
Tapes clearly have the win in longevity. However, failing to keep the hardware necessary to read them can be a huge headache.
The problem with tape is finding a drive to read them. That can be a bigger job than one might imagine. *cough*NASA*cough*
The problem with hard drives is that they simply don't work after sitting on a shelf for many years. I've been to that dance too many times.
First problem... availability. Metro-E isn't available everywhere. The second problem... cost. This is the ever moving target in the equation. I've (sadly) found traditional tariffed services to be cheaper than the non-tariffed newcomers. Of course, I live in the territory of the stupid and lazy -- Bellsouth and Timewarner. (no matter who your ISP is, one (or both) of them will be involved.)
And your problem was 100% "VXA". That's not enterprise technology -- it's just cheap all the way around. Lemme guess, their previous backup tech was QIC-80 and Travan?
That depends on what you see as a revision. SCSI-1, SCSI-2, SCSI-3, FC-1, FC-2, FC-3, ... and those are just command protocols. Async, Sync 5, 10, 20, 40, 80, 160, narrow, wide, ... Just in the SCSI world. How many different IDE protocols, speeds, and modes are there? PIO modes, DMA modes, Ultra DMA modes, ATA-X standards. Hard drive tech evolves just as fast as tape.
Plus, you'd be in deep sh*t when you got a drive back from storage to find it 100% completely unusable. HD are fine for online storage when coupled with periodic scrubbing, but for offline storage they are the most unreliable thing in the universe. (well, maybe not the worst, but pretty high up on the list.)