From: Handover Phist on
The subject line is a bit unclear. What I want to do is copy the
contents of an ext3 partition over a network, run lilo on the drive, and
have it work.

I have a Slackware based house server and I would like to upgrade the HD
with as little downtime as possible. My thought is put the new drive in
another machine, set up the partitions, then copy the contents over the
network while the server is running. Once that's done, swap out the
drives, fire up the server, and viola! One upgrade with about 5 mins
downtime. Anyone done this sort of thing before? What are the chances of
MySQL databases getting B0rked (I have about a dozen of them)?

--
"God is as real as I am," the old man said. My faith was restored, for
I knew that Santa would never lie.

www.websterscafe.com
From: Bit Twister on
On Sun, 7 Feb 2010 09:17:04 -0800, Handover Phist wrote:
> The subject line is a bit unclear. What I want to do is copy the
> contents of an ext3 partition over a network,

rsync over network or nfs mount using rsync would work. There are some
file systems that you do not copy over. /proc and /sys (I think) come to mind.

> run lilo on the drive,

Bit tricky there. I would guess drive would have to be same device as
server (sda, sdb, hda. hdb...) whichever when executing lilo to
install into MBR or whereever.

> and have it work.

> What are the chances of
> MySQL databases getting B0rked (I have about a dozen of them)?

Well in your case they would have to be shutdown, copied to other
drive, you update drive then swap drives, then start MySQL up.

Then again we have no ideal how you have set those up.
From: Henrik Carlqvist on
Handover Phist <jason(a)jason.websterscafe.com> wrote:
> What I want to do is copy the contents of an ext3 partition over a
> network, run lilo on the drive, and have it work.

A single ext3 partition?

> I have a Slackware based house server and I would like to upgrade the HD
> with as little downtime as possible.

The quickest and simplest way to do this would be to add the new drive to
the server and keep the old drive. Once installed you can partition the
new drive to add partitions for stuff like /usr/local and /home/someuser.
You might also want to add an extra swap partition to make your swap work
like raid 0 with the same priority on both drives swap partitions.

Once you have created your new partition table you will be able to write
the partition table and immediately use it as you haven't had any
partitions on that drive mounted. With mounted partitions from a drive a
reboot is required to reread the partition table.

Create your file systems and mount them on some temporary place like
/tmp/mnt. Then do things like:

cd /usr/local ; tar -cf - | (cd /tmp/mnt ; tar -xvf -)

Then edit your fstab to add your new partition and do something like:

cd /usr ; mv local local.old; mkdir local; mount local

All this partitioning and copying of files can be done while the server is
running.

> My thought is put the new drive in another machine, set up the
> partitions, then copy the contents over the network while the server is
> running. Once that's done, swap out the drives, fire up the server, and
> viola! One upgrade with about 5 mins downtime. Anyone done this sort of
> thing before? What are the chances of MySQL databases getting B0rked (I
> have about a dozen of them)?

Making a backup like that from a running system will give you a snapshot
of the running system and that snapshot will probably not be fully
consistent. Your MySQL databases will might get borked and the entire
system will at bootup behave as a system which was shutdown in an unclean
way, except that there is no need to run fsck.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root(a)localhost postmaster(a)localhost

From: Handover Phist on
Bit Twister :
> On Sun, 7 Feb 2010 09:17:04 -0800, Handover Phist wrote:
>> The subject line is a bit unclear. What I want to do is copy the
>> contents of an ext3 partition over a network,
>
> rsync over network or nfs mount using rsync would work. There are some
> file systems that you do not copy over. /proc and /sys (I think) come to mind.

Ran rsync over nfs and most of /dev came over. Not sure about /proc.

>> run lilo on the drive,
>
> Bit tricky there. I would guess drive would have to be same device as
> server (sda, sdb, hda. hdb...) whichever when executing lilo to
> install into MBR or whereever.

I made the drive equivalent to the server drive. swap on /dev/hda and
root on /dev/hdb. I just copied everything wholesale.

>> and have it work.
>
>> What are the chances of
>> MySQL databases getting B0rked (I have about a dozen of them)?
>
> Well in your case they would have to be shutdown, copied to other
> drive, you update drive then swap drives, then start MySQL up.
>
> Then again we have no ideal how you have set those up.

Neither httpd or mysqld worked in this process. ssh services also took a
hit. I think this is a failed method. What I'm going to do next is
install slack 12.2 (the server is 12.1) and copy the relevent /etc files
(http, syslog, named, etc.) and then dump and import the databases and
see how that works. I have 12.2 on an nfs export from the server to the
build machine so it should Just Work if everything goes my way.

It pays to have a test box ;).
From: higuita on
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all

On Sun, 7 Feb 2010 18:45:17 -0800, Handover Phist <jason(a)geddy.websterscafe.com> wrote:
> Ran rsync over nfs and most of /dev came over. Not sure about /proc.

Actually, for network transfers, rsync+rsync server is more efficient
than nfs, specially for resuming, but nfs works too

> Neither httpd or mysqld worked in this process. ssh services also took a
> hit. I think this is a failed method. What I'm going to do next is

What!?!
i used this method thousands of times and the only problems i had
are the missing --numeric-ids in rsync (when i forgot it) and tunnig the
initrd on systems that use it and have different hardware (ie: scsi
controllers)

the --numeric-ids is important, as rsync tries to match the
usernames from the remote to the local account, changing the uid and
gid. After booting the transfered system, the uid/gid from running
servers dont match the ones on the filesystem and things fail.

i use this command usually on each mount point i need:

rsync -avxh --progress --stats --numeric-ids server:/ /mnt/new-hd/

during this transfer, i have everything running, even
databases...after the first copy i then stop all services on the
old system, rsync again to synchronize any changed files. this
rsync is very quick, as rsync is smart enough.

i then run:
mount --bind /proc /mnt/new-hd/proc/
mount --bind /sys /mnt/new-hd/sys/
mount --bind /dev /mnt/new-hd/dev/ (not needed in many systems)
chroot /mnt/new-hd

i fine tune the lilo.conf and fstab and run lilo.
exit/umount everything, shut down the old system and reboot the
new one.

Based on your comment, i guess that you MUST use the
- --numeric-ids

> It pays to have a test box ;).

always!! :)

good luck!
higuita
- --
Naturally the common people don't want war... but after all it is the
leaders of a country who determine the policy, and it is always a
simple matter to drag the people along, whether it is a democracy, or
a fascist dictatorship, or a parliament, or a communist dictatorship.
Voice or no voice, the people can always be brought to the bidding of
the leaders. That is easy. All you have to do is tell them they are
being attacked, and denounce the pacifists for lack of patriotism and
exposing the country to danger. It works the same in every country.
-- Hermann Goering, Nazi and war criminal, 1883-1946
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktyDHQACgkQrv1jazsMcrO05gCfa1t2ec0yBbuNzidDJFT2h1Z0
iskAoJ2epSHXDHRR8abPxozD6SeD6CB7
=SE4k
-----END PGP SIGNATURE-----