so the technique is as so: on your server or other system with some
spare drive space (you do have more than one computer in your house
don't you? no? keep moving along and leave your hacker badge at the
door) type the following command:
> nc -l -p 6666 > laptop.tar.bz2
if you get an error about the port being in use just try a different
number above 1024 until the command just sits there doing what appears
to be nothing. what it is doing is waiting for an incoming connection
from another system on the network and redirecting that to a file
named laptop.tar.bz2.
now we go over to our system we want to backup, on which you will need
to have root access. you will need to know the hostname or ip of the
machine we typed the previous command on; if you don't, i suggest you
go back to the server and find out. if you have a local network dns
service setup (bind (ugh) or something nice like dnsmasq) the hostname
should work across your network, so you can just find it using the
hostname command. if you don't have that you can type /sbin/ifconfig
to get some information about your ethernet interfaces; the ip address
of the machine would be in the section marked eth0 and would generally
start with 192. of course, if you are reading this i'm sure you've
setup your own network and know all this, but let's get back to the
upgrade plan.
so as root on your machine you want to upgrade, if your server
hostname is 'meta', type:
> tar jlcvPpf - / > /dev/tcp/meta/6666
or if the ip address 192.168.0.2:
> tar jlcvPpf - / > /dev/tcp/192.168.0.2/6666
the options are as follow:
j - do bzip2 compression on the archive
l - one file system (more on this later)
c - create archive
v - be verbose about it
P - don't strip leading / from pathnames
p - preserve permissions
f - the file name to write, which in this case is - which means
standard output
so this is then redirected to the network using the nice little bash
redirection feature, which is equivalent to piping to netcat as so:
> tar jlcvPpf - | nc -p 6666 [hostname or ip address of server]
the tar options are pretty standard except for the l option. my tar
complains a bit about how one shouldn't use the l option and should
provide the long --one-file-system option; my manual says they are
equivalent but if the error bugs you, feel free to switch it up.
the l option is important since it keeps you from crossing file system
boundaries when you're building the system archive, thus keeping you
from tarring up /proc, /sys, /tmp (if you have it mounted as a
shmfs). it also prevents you from backing up any other partitions you
might have mounted on your system; this worked for me because i've
long since moved from having tonnes of partitions on my home system.
if you still do it the old fashioned way, make sure you put every
mounted directory after the / in the tar command (if you want the
whole system in one big archive) or run the above commands for each
mounted directory on both the host and the server so you can recreate
the new partition mapping easily.
so now that you've done this, you can wait and watch all the files on
your host system scroll by on the screen... be prepared to wait a
long while, especially for large drives. in the meantime, go talk
with your SO (remember them?), install FreeBSD or, um, go outside for
a walk...trust me, it's good for you.
so, now that's finished and we'll go over to the hard drive upgrade.
i'm going to blaze over this since it's not my intention of this to
show you how to do that. basically turn the machine off, take the old
drive out and put the new one in. find yourself a nice shiny linux
installer cd (i used slackware 10, which was the same system that was
on the machine i was upgrading).
my first idea was to boot with the new hard drive, partition it and
mount it and then use netcat to untar the old system onto the new root
partition on the drive; of course it didn't work that way since
slackware doesn't provide netcat on the installation disk (damn you!)
and bash hasn't incorporated my server patches into the default
distribution. oh well, on to try two.
what i ended up doing was doing a basic minimal install of slack onto
the new root partition; again i won't walk you through this, but it's
quite easy and make sure you get netcat on there somewhere. you can
stop after the initial installation as long as you have bash, tar,
bzip2, and nc and the required libs installed (the base 'a' set in
slackware and netcat).
now you have to get your network up and running, which hopefully will
be a simple process, and since you already had linux running on the
system you're upgrading, i'll assume that the network worked before at
least. you might have to load a module to get your network card
working; check your distributions documentation for that since i'm
not going into that much detail in this little article.
the network on the machine to upgrade can be brought up with:
> /sbin/ifconfig eth0 192.168.0.3
try to ping your server:
> ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=1.57 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.107 ms
--- 192.168.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 0.107/0.842/1.578/0.736 ms
looks good. if not, go back to google and figure it out :)
with your new desired root partition is in /mnt, do a:
> chroot /mnt /bin/bash
to get into the base system and type the following:
> nc -l -p 6666 | tar jxvpf -
now scuttle over to your host machine console and type:
> cat laptop.tar.bz2 > /dev/tcp/192.168.0.3/6666
...and wait. on your laptop machine you'll find all the files scroll
by yet again, and you get to wait...again. if you did the multiple
partition thing, mount each of them in their respective directories
and untar each file in turn.
so, by the time this is finished, you will have all the files back in
your new partition...but we aren't finished yet! the drive does
contain a duplicate of the files that were on the old drive, but it
still doesn't boot, or at least not like it used to (it might be setup
to boot with the basic installation that you installed to get netcat
installed, blah blah blah). so you need to re-run grub or lilo to
fixup the MBR on the new disk, and get the system booting.
once you've done that, you can fix up your /etc/fstab if you've
switched any partions around, unmount the new root directory and any
others your moved over and reboot. make sure you cross your
fingers...
and if you crossed them just right, the system will boot just like it
did before, except with a bigger hard drive. of course, there's a
pretty big chance that it won't due to some bad path name to the
kernel, or gnomes or something...just remember that the best thing
about linux is that you get to LEARN! i've never run into a problem
that isn't fixable with enough effort and you'll up your hacker skill
points every time you fix a messup on your system ;-)
but of course the best part is that if this doesn't work at all and
you cannot be arsed to figure out how to make it work, simply take the
new drive out, put the old one back in and it'll work just like
before. then go over to your local computer shop that has a 'linux
guru' and let him mess it up for you, probably losing all your data
along the way, and you get to pay for it in the end!
so yes, this has been an article on a simple way to upgrade your
hard drive using a couple of basic tools and some know how. even if
this doesn't seem simple, once you get to know linux (or unix in
general) you'll find out how simple it really is, once you know a bit
about what you're doing. the only limit with unix is your own
knowledge, and it's wide open to study, examine, learn and modify.
--
kruhft
kruhft.blogspot.com
www.myspace.com/kruhft
metashell.blogspot.com
Awesome post !
Thank you.
Here's a similar method I once used to mirror identical machines over
the network:
-== Block Device copying over LAN (Using linux LiveCD) ==-
To copy the entire block device from one machine to the other, use the
following procedure:
* Make sure the ssh daemon is running on the target machine
* Make sure the ssh daemon is running on the source machine
* Execute the following command on the source machine
dd if=/dev/hda bs=1k conv=sync,noerror | gzip -c | ssh -c blowfish
user@hostname "gzip -d | dd of=/dev/hda bs=1k"
--
Cheers,
Maxim Vexler (hq4ever).
Do u GNU ?