RE: [Trinux-talk] Q - Timothy Burt - Backup or clone hard drive

[Riaan L. <ri...@ra...>]

I will definitely look at it but the problem is that I doing the restore
over a wan i.e. very low bandwidth.

Riaan Labuschagne
e-mail: ri...@ra...
+27 83 4444148
+27 21 982 2223
+27 21 982 2225 (fax)
Visit http://www.radioretail.co.za


-----Original Message-----
From: P60 [mailto:akd...@ka...]
Sent: 02 October 2002 02:52
To: ri...@ra...; Trinux-Talk (E-mail)
Subject: Re: [Trinux-talk] Q - Timothy Burt - Backup or clone hard drive


> Timothy,
> I refer to your "clone hard drive" howto you wrote.
>
> Is there a way that I can tar the contents of a backed up disc, copy it to
> cd, untar it on a partition on the new hard drive and restore the disc,
> whilts keeping the permissions etc?
>
> I AM NOT LOOKING for a howto, just some pointers please.
>
> Thanks
> Riaan Labuschagne

Another perhaps easier method could be to use nc, as known as, netcat to do
such a job. It's in the netutils package. But it needs a working network
connection. And perhaps the dd program, It' in the fileutils package.
(There is also a netcat for NT)

From the nc info:

"Netcat can be used as a simple data transfer agent, and it doesn't really
matter which end is the listener and which end is the client -- input at one
side arrives at the other side as output.  It is helpful to start the
listener
at the receiving side with no timeout specified, and then give the sending
side
a small timeout.  That way the listener stays listening until you contact
it,
and after data stops flowing the client will time out, shut down, and take
the
listener with it.  Unless the intervening network is fraught with problems,
this should be completely reliable, and you can always increase the timeout.
A
typical example of something "rsh" is often used for: on one side,

 nc -l -p 1234 | uncompress -c | tar xvfp -

and then on the other side

 tar cfp - /some/dir | compress -c | nc -w 3 othermachine 1234

will transfer the contents of a directory from one machine to another,
without
having to worry about .rhosts files, user accounts, or inetd configurations
at either end.  Again, it matters not which is the listener or receiver; the
"tarring" machine could just as easily be running the listener instead.  One
could conceivably use a scheme like this for backups, by having cron-jobs
fire
up listeners and backup handlers [which can be restricted to specific
addresses
and ports between each other] and pipe "dump" or "tar" on one machine to "dd
of=/dev/tapedrive" on another as usual.  Since netcat returns a nonzero exit
status for a denied listener connection, scripts to handle such tasks could
easily log and reject connect attempts from third parties, and then retry.
"

Arne