From: Timothy B. <tb...@ar...> - 2002-10-02 16:30:08
|
Good idea. tar used to be terrible about maintaining permissions, perhaps it has been fixed. I use cpio because it has always done it right. nc -l -p 1234 | uncompress -c | cpio -i and find . -print | cpio -o | compress -c | nc -w 3 othermachine 1234 also, with sub 500 MHZ machines, it runs faster without the compression. ALSO, you cannot use this method to snapshot the root, while it is running. It might work, but it is not reliable. On Wed, 2 Oct 2002, P60 wrote: > > 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 > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Trinux-talk mailing list > Tri...@li... > https://lists.sourceforge.net/lists/listinfo/trinux-talk > -- -------------------- Timothy Burt General Manager Arbor Group LLC Los Angeles, Calif. USA |