🚀 go-pugleaf

Linux RAID Functions:
what you are looking for:
"Mirroring: Two hard disk partitions are used to create one partition,
which is the size of the smallest component partition. Each of the
component partitions contain the same information, so if one disk fails,
the other takes over without any loss of data."

look at this document, too.
http://metalab.unc.edu/mdw/HOWTO/Root-RAID-HOWTO.html

"Olivier M." wrote:

> Hello,
>
> I'm currently trying to set up a kind of high security linux
> There are 2 harddisks of the same size, and partitionned exactely

Linux RAID Functions:
what you are looking for:
"Mirroring: Two hard disk partitions are used to create one partition,
which is the size of the smallest component partition. Each of the
component partitions contain the same information, so if one disk fails,
the other takes over without any loss of data."

look at this document, too.
http://metalab.unc.edu/mdw/HOWTO/Root-RAID-HOWTO.html

"Olivier M." wrote:

> Hello,
>
> I'm currently trying to set up a kind of high security linux
> There are 2 harddisks of the same size, and partitionned exactely

Olivier M. <XO*QVV@technologist.com> wrote:
> think that using "dd" is a good idea ? Or should I rather use

dd is only good provided the fs is umounted, or at least mounted
read-only.

> Or maybe would RAID help me in this case, but I have no good
> docs about that, and it seems to be quite a dangerous system
> if not correctely configured. 

Anyway, if the power fails, BOTH your RAID partitions will be
in the same incoherent state, needing fsck, and in the bad cases,
manual intervention.

Your idea of ``from time to time copies'' is good. If you unmount
the backup after the copy, the only ``dangerous'' window is
during the copy.

By the way, how do you intend to automate the recovery process ?
One idea would be to have a partition which is never written to
(initrd) and which attempts to mount all the other partitions,
doing fsck when needed and if fsck fails, mount the alternate.

Marc SCHAEFER <schaefer@alphanet.ch> wrote:
> By the way, how do you intend to automate the recovery process ?
> One idea would be to have a partition which is never written to
> (initrd) and which attempts to mount all the other partitions,
> doing fsck when needed and if fsck fails, mount the alternate.

This partition could be be RAID1, however, I know of no
motherboard which supports this: this means that if the disk is
dead, you can't boot. However, you can replace the hard-disk.

<schaefer@alphanet.ch> ecrivait/schrieb/wrote:
>> think that using "dd" is a good idea ? Or should I rather use
>dd is only good provided the fs is umounted, or at least mounted
>read-only.
you mean both fs ? or is it ok if only the destination fs is
unmounted ? for example if I dd the partition of /home, I don't
really want to mount it read-only : users wouldn't be able to
get mail (qmail: mailboxes _are_ in /home/username/Maildir), 
and cgi that need to write to the disk wouldn't work anymore
during this (too long) time.
 
>Anyway, if the power fails, BOTH your RAID partitions will be
>in the same incoherent state, needing fsck, and in the bad cases,
>manual intervention.
tja, that's exactely what I want to avoid. The server is really
far from my workplace (50km), and in case of problem, the only thing
I can do, is to tell by phone to somebody in the server room : take
the rescue disk (LILO, set up to boot on the _second_ HD) and restart
the PC.

>Your idea of ``from time to time copies'' is good. If you unmount
>the backup after the copy, the only ``dangerous'' window is
>during the copy.
could even be good against low level hackers :) 

>By the way, how do you intend to automate the recovery process ?
with a LILO disk as said a few lines before.

>One idea would be to have a partition which is never written to
>(initrd) and which attempts to mount all the other partitions,
>doing fsck when needed and if fsck fails, mount the alternate.
well, it sounds interesting, but I currently don't have the
knowledge to make such a thing, at least not without good docs :)

The final goal is to have 2 separate servers (hosted at different
providers) with same setup and harddisk contents, so that even
if a provider is unreachable, the pages will still be viewable.
I'll have to configure named to make it work, but I don't think
it will be too difficult. If you already tried something like
this, feel free to make comments...

If it works, then I'll write something about this on the linux
server guide project ( http://lisa.8304.ch ).

Olivier
-- 
____________________________________________________________
 ... Please replace "XD*NUP" by "olm" to answer by e-mail...
    --- .-.. .. ...- .. . .-.    -- ..- .-.. .-.. . .-.

Hi,

Olivier M. schrieb in Nachricht ...

>The final goal is to have 2 separate servers (hosted at different
>providers) with same setup and harddisk contents, so that even
>if a provider is unreachable, the pages will still be viewable.
>I'll have to configure named to make it work, but I don't think
>it will be too difficult. If you already tried something like
>this, feel free to make comments...


there are many issues regarding security, but I think what you're looking
for is HA (high availability).

As you've always been told, you should mirror your harddisk (RAID). for the
backup, just unmount the mirror-side and make an ufsdump (this is a SUN
command, don't know the linux equivalent). attention: keep backup time as
short as possible, as the new datas won't be saved in this time.

for your cluster, do exactly the same. there are two things that aren't that
easy to handle:

1. how to mirror the 1st system to the 2nd? on SUN there's software which
can do this, which keeps track of the copied files and update them if
necessarly. I suppose you will find something similar on linux too. but keep
in mind, that it can cause heavily network traffic between the two machines,
depending on how often you write on the master system. maybe you need just
for this an extra fast ethernet connection.

generally you should ask yourself, how high the network traffic is, and how
many datas you have to secure. only if you know this, you can design your
solution.

2. if the master system crashes, how can the slave system take it over? I
guess that at least you have to change the IP adress manually, which means
that in this time period your server is down.

maybe you should think also about power. some HA-Server have three power
supplies!

just some thoughts...

bye

Matthias

Olivier M. <XD*NUP@technologist.com> wrote:
> you mean both fs ? or is it ok if only the destination fs is

Both (source AND destination) MUST be unmounted.  Having the
destination fs mounted may cause system panic. Having the source
mounted will at require an e2fsck on the destination before
use, since the fs will not be marked as clean. Theoretically,
the data on it should be there, since dd also uses the buffer
cache (there is no real raw devices on Linux --- well, without
Direct IO).

> get mail (qmail: mailboxes _are_ in /home/username/Maildir), 
> and cgi that need to write to the disk wouldn't work anymore
> during this (too long) time.

that's why tar is best.

> I can do, is to tell by phone to somebody in the server room : take
> the rescue disk (LILO, set up to boot on the _second_ HD) and restart
> the PC.

Do it with tar, then.

> >By the way, how do you intend to automate the recovery process ?
> with a LILO disk as said a few lines before.

so it's not really automatic, which is probably enough for now.

> it will be too difficult. If you already tried something like
> this, feel free to make comments...

if you put multiple addresses on a A record, I don't think people
try them only if it fails: I think they are served in round-robin
fashion (but only a DNS specialist can answer this).

Marc SCHAEFER <schaefer@alphanet.ch> wrote:
> the data on it should be there, since dd also uses the buffer
> cache (there is no real raw devices on Linux --- well, without
> Direct IO).

But still, there are windows were this won't work either, causing
data corruptions: since there are locks in ext2 which will be
bypassed by accessing the buffer cache directly.