connected, video out that can go to a projector... decodes all sorts of
digital signals...
nah. green sux. even paperwhite (which in the end was just bright green) sux. Amber rox da house.
/etc/X11/app_defaults/*XTerm-color :
*VT100*pointerColor: yellow
*VT100*cursorColor: yellow
*VT100*XtDefaultForeground: red
*VT100*foreground: orange
"Hmm, I think I should like to rip this Russian DVD (which I cannot even watch on my DVD player) to a video file on my computer."
It took longer to reboot into Ubuntu than it did to find and install an app and start making AVIs.
The windowlist applet started sticking to the wrong monitor.
I'd drag it back, it would stay for 1 second then pop back to the other/wrong monitor.
What the fuck I say. I started hunting around google but then thought the better of it, time to reboot.
So I did.
Then the really most fucked up thing happened. My vmware vms didn't start up, saying it required a driver recompile. Oh no not again. But wait. I never ever ever upgrade linux anymore for fear of that problem (really it's time I switch to vbox).
Then I notice that my mail only goes to september.
Something very not cool going on.
I look at df and get this: I'm booted on a raid-0 device
Real interesting since I blew away the drive and reinstalled a non-raid setup from scratch a while ago... like september.
Ahhh... I see the problem. BIOS booted off the wrong drive.
So I go to the bios and as I have to two identical drives, it's hard to tell which is the right one, but I switched to the other and voila I got my machine back.
I can't tell you the feeling of dread that goes through my stomach when I see my machine doesn't boot right.
So now I'm wondering how do I blow away the mbr on the second drive so it never boots again without killing the partition table?
You can use gparted and change the 'bootable' flag on the partion. But....shouldn't you edit the grub configuration instead?
So when it booted off that drive it came up in broken raid 0 mode and ran happily waiting for me to replace the first broken drive.
I have long since thought better of the idea and blew away the first drive and installed OS from scratch, but left second drive alone thus (as never occurred tome) it was still a viable functioning half of a raid 0 setup.
So I had a better idea. I invented raid minus 1.
Rather than have the OS manage live mirroring I decided to remove everything off the second drive and write a script to dd drive 1 to drive 2 once a week.
It's like raid 0 but not live. I have daily incremental backups to cover the span between dd script runs.
What I realized is that it's not just my data that's important, but the OS setup as well. I get such a sick feeling in my stomach when I realize I have no working machine and I have to do nothing but install configure install configure fight with vmware (which is really the worst of it) just so I can work from home and get my mail and such.
So my mirroring the drive once a week, if the first drive fails, I just change my bios and voila working machine, no installing of anything.
"BUT!" you say, "if you run dd on an active partition, it's not in any real state that should be backed up. It's a useless backup."
"NAY!" I retort.
I read an article a few years ago suggesting that you don't shut down your machine, you just power it off. Why wait for it to fuck around flushing buffers and what not, when really, the OS has so many layers of transaction log and whatnot, it generally can recover pretty well most of the time (esp ext 3 and ext 4) so really, if my live partition dd backup isn't usable it's a failing of ext4 not my backup mechanism.
Of course I haven't tried this out yet....
you should use LVM and snapshots to get that steady state ;-)
but in general a drdb via loopback probably would be the same as online.
But I realy like your idea of having the two drives wearing of in a different time frame; since one of the biggest fails of any raid is, that the drives age at the same pace, so you end up
By the way, did I mention it takes EIGHT HOURS to dd 650gig.
I gotta think there's a batch size setting I can set somewhere.
So Dez 19 2010 15:28:07 EST von Ford II @ Uncensored Betreff: Re:I was thinking of powering down the second drive (if i can) except for the once a week do do the dd.
By the way, did I mention it takes EIGHT HOURS to dd 650gig.
I gotta think there's a batch size setting I can set somewhere.
basicaly i'm not a friend of dd here. if your filesystem is inconsistent or broken, you will copy the brokenness.
also reading the full disk stresses your system and the disk.
i'd rather prefer sort of a monthly backup with tar over the full range, and incremental ones on a daily basis.
ok, tar has one real big disadvantage: you can't mount it.
but its probably also a good (and faster - less stressing ) solution.
ok, gzipping effectiveness and incremental tar effectiveness affects the amount and the quality of my sugestion...
otoh, i'd rather do it via tar | nc to another box. if you've got a problem with your memory, or your disk controller, that backup also will break. if you have a second box around,
I had a situation where I created an ext2 filesystem, copied everything over with tar |tar, put other disks into the hardware raid, bootet a newer kernel, and the backup was totaly broken, the filesystem totaly fucked up.
since then I prefer to have tcp in the line of my backups.
"RAID Minus 1." Now I've heard everything. :)
Ok, well to get the kernel to stop recognizing a RAID volume, you need to change its partition type back to regular Linux, and you also have to clear the md signature on the partition.
I don't know how to do that. Sorry.
Somebody said dd will copy broken filesystem. True, but tar won't be able to tar off a broken filesystem either if it's broken enough.
The idea is hopefully to notice whatever problem it is before I do a mirror copy so I still have a good image. I guess that would require that I reboot the machin every week before the backup to make sure the machine's in a good state before I back it up.
why oh why is this so hard.
I guess next time the system gets messed up, I'll have to come up with something simpler to recover with.
I would boot of an SD-Card, a thumb drive or something like that.
separate your system from the payload.
the tar will give you a snapshot of your actual data. More precise than the dd.
unless you have several disks to dd to.
why oh why is this so hard.
I suspect it's because you're trying to outsmart the system.
I suspect it's because you're trying to outsmart the system.
the system needs outsmarting.
The problem with separating the system from the payload is that the system IS the payload.
When you install something even from yum or apt or synaptic or whatever, does it store this install and metadata in a separate filesystem? No. It reconfigures /etc and /usr/share and all that, and THAT'S one of the many things I don't want to have to do/setup all over again if the machine dies.
Every time I put a new applet on my gnome applet bar, every time I close a shell and my history is stored in .bash_history... THAT'S the stuff I want to back up.
ah, ok, you're using that inferor linux where you have to configure everything by hand, well.
me does 'dpkg --get-selections' and it gets me on 98% of where I was in advance.
I'd rather do gentoo, where its waste your time on compiling instead of waste your time on configuring ;-P
</rant>