Re: Best way to duplicate HDs
> On Tue, 1 Jan 2002 07:28, Jason Lim wrote:
> > What do you think would be the best way to duplicate a HD to another
> > (similar sized) HD?
> >
> > I'm thinking that a live RAID solution isn't the best option, as (for
> > example) if crackers got in and fiddled with the system, all the HDs
would
> > end up having the same fiddled files.
>
> If crackers get in then anything which involves online storage is
> (potentially) gone.
Right now one of the things we are testing is:
1) mount up the "backup" hard disk
2) cp -a /home/* /mnt/backup/home/
3) umount "backup" hard disk
The way we do it right now is:
1) a backup server with a few 60Gb HDs
2) use "dump" to cp the partitions over to the backup server
3) use "export" to restore stuff
(not very elegant... which is why we're trying to set up a better way)
Unless a cracker spends quite a bit of time going through everything, they
would most probably miss this part. True... if they do spend enough time
going through everything, then as you said, it is potentially gone.
> > If the HD is duplicated every 12 hours or 24 hours, then there would
> > always be a working copy, so if something is detected as being
altered, we
> > could always swap the disks around and get a live working system up
and
> > running almost instantly (unless we detect the problem more than 24
hours
> > later, and then it would be too late since the HDs already synced).
>
> The most common problem in this regard I've encountered when running
ISPs
> (see at many sites with all distributions of Linux, Solaris, and AIX) is
when
> someone makes a change which results in a non-bootable system. Then
several
> months later the machine is rebooted and no-one can remember what they
> changed.
Haven't had that yet... because every time we make a massive system change
that might upset the "rebootability" of the server (eg. fiddle with lilo,
partition settings, etc.) we do a real reboot. This might not be pratical
on a system that needs 99.9999% uptime, but ensures it will work in
future.
> Better off having an online RAID for protection against hardware
failures and
> secure everything as much as possible to alleviate the problem of the
> machines being cracked.
>
> > So... what do you think the best way would be to duplicate a HD on a
live
> > working system (without bringing it down or anything like that).
> > Performance can drop for a while (maybe do this at 5am in the
morning),
> > but the system must stay up and operational at all times.
>
> LVM. Create a snapshot of the LV and then use dd to copy it.
Eep... setting up LVM for the SOLE purpose of doing this mirroring? Seems
a bit like overkill and would add an extra level of complexity :-/
> > Maybe dd... or cp -a /drive1/* /drive2/... or something?
>
> Doing that on the device for a mounted file system will at best add a
fsck to
> your recovery process, and at worst result in a file system so badly
> corrupted that an mkfs is needed. LVM solves this, but adds it's own
set of
> problems.
> I think that probably your whole plan here is misguided. Please tell us
> exactly what you are trying to protect against and we can probably give
> better advice.
>
I know of a few hardware solutions that do something like this, but would
like to do this in hardware. They claim to perform a "mirror" of one HD to
another HD while the system is live and in use. I have no idea how it does
this without corruption of some type (as you mentioned above, doing dd on
a live HD will probably cause errors, especially if the live HD is in
use). For example, http://www.arcoide.com/ . To quote the function we're
looking at " the DupliDisk2 automatically switches to the remaining drive
and alerts the user that a drive has failed. Then, depending on the model,
the user can hot-swap out the failed drive and re-mirror in the
background.". So it "re-mirrors" in the background... how do they perform
that reliabily?
Sincerely,
Jason
Reply to: