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>
But I am too old to fight with gentoo and I go with ubuntu because they make it as easy as possible.
When you do that, it's pretty easy to never have to do a reinstall; you just keep rolling forward with the in-place updates.
If you insist on wiping it clean from time to time, the best available practice for "keeping your stuff" is to install it all in /usr/local and then when you reinstall or move to a new machine, you bring along your backups of /usr/local and /home.
Also, running a network of multiple machines where /usr/local and /home are shared with NFS will really hone your skills in this area.
I don't wipe my machine exactly. I mean, I do, but I end of copying back /home and all my /usr/local/bin stuff and when things don't run anymore, I have to hunt down the packacge I'm missing.
Eventually I get to a place where I've been able to do everything I want to for a while then throw away the backup of the old machine.
I have a mount called /sp that I try and throw all my data in where possible so I only really have to back that up and move that from machine to machine to get most of what I had.
I recently finished my banishment of vmware. It took 2 solid days, but I've got most everything I had before.
I can vpn play pandora and rip dvds and whatnot and so far virtualbox is keeping up.
So hopefully I'll never have to suffer that dreaded "oh no vmware won't compile its kernel modules again" stomach drop out things.
Or did you manage to pull it all together using only drivers that are in the repository?
And now you'll just get the dreaded "oh no virtualbox won't compile its
kernel modules again" stomach drop out things instead.
Doesn't happen on Windows.
Binary blobs scare me. I have a few too many binary blob programs that no longer run under current Glibc releases. If KVM gets replaced at some point with someting better, I would guess I would have a way to continue using my ancient vm images that I keep around to punish myself and my free time. I can't say that about the more recently abandoned VMWare Server product - Firefox breaks the browser plugin and I end up having to use a hack for the ESXi management tool just to see the hosts I have deployed. I would guess the blob would quit working at some point as well with a Glibc update. At least the qemu convert tools will give me some hope.
Probably being to harsh on VMwer, but KVM fits the bill for 99.99% of what I do (i.e. no games or graphics intensive stuff, but they are working on that via seperation from the vnc stuff).
Having been blessed by Red Hat, Canonical, and Linus "I like to break the kernel ABI on a daily basis" Torvalds, KVM will find itself the happy recipient of quite a lot of improvements and optimizations, and eventually a really nice set of management tools will spring up around it.
Xen is toast. No doubt about it. VirtualBox will continue to enjoy its current position for as long as people continue to run systems without hardware VT on the processors.
VMware continues its reign of awesomeness. There's still nothing out there quite like vSphere. And y'all know what a big open source advocate I am, but I still love vSphere. On the other hand, VMware Server 2.x is probably the single worst product they've ever released; it tries as hard as it can to suck as much as possible.
My server on the Internet is running a standalone copy of ESXi. I tend to make the big changes whenever I get new hardware, which in this case was last summer. It was my first VT-capable box, so I took the opportunity to switch from OpenVZ to VMware ESXi. It'll probably stay that way until my next hardware upgrade, by which time we will hopefully have a much more manageable and usable KVM available.