🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.linux.questions
Article #27

Mirroring remote filesystems -- a solution ?

#27
From: Bruce Tulloch
Date: Thu, 05 Feb 1998 00:00
104 lines
5408 bytes

--------------F215F165F3C6249834E950AF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I want to mirror parts of my file system between two non-networked linux
machines on a daily basis (my work machine and my home machine). I've
found two tools that come close to achieving this...

   NNFS ("Non-Networked File System")
   http://www710.univ-lyon1.fr/~exco/NNFS/ANNOUNCE.html

   Reflect
   http://sunsite.unc.edu/pub/Linux/utils/file/reflect.tar.gz

NNFS is a a good attempt to solve this problem, but it relies on file
dates to "synchronise" file systems "automatically" which interferes
with other tools that rely on file dates and does not allow the user to
choose which file system is to be the "source" and which the
"destination". It's also a rather complicated implementation written
part in C and part in Shell which I have been unable to make work
flawlessly using Zip disks as the "NNFS media" (probably just me, not
the author :-).

Reflect on the other hand is a short, simple perl script that
_almost_ does exactly what I want -- it allows one to "reflect" one
file-system to another, copying and optionally deleting only those files
that have changed on the source file system when compared with the
destination. The problems with it is that both file systems must be
mounted on the same machine simultaneously.

What I seek is Reflect's functionality but which can use a small
intermediate (eg Zip disk) file system to transport the changes from one
large file system on the source machine to a mirror file system on the
destination machine (and back again in the morning :-).

On a daily basis it's unlikely that I'd generate more than 100 Mb of
changes, so one Zip disk is all that's required, even for mirrored file
systems many Gb's in size.

Modifying the reflect script is probably one way to go, but before I
attempt that I'm keen to learn if anyone else has a simple solution to
this problem.

Many thanks if you can help !

-bruce

--
     *** complex problems have simple easy to understand wrong answers ***



--------------F215F165F3C6249834E950AF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
I want to mirror parts of my file system between two non-networked linux
machines on a daily basis (my work machine and my home machine). I've found
two tools that come close to achieving this...

<P>&nbsp;&nbsp; NNFS ("Non-Networked File System")
<BR>&nbsp;&nbsp; <A HREF="http://www710.univ-lyon1.fr/~exco/NNFS/ANNOUNCE.html">http://www710.univ-lyon1.fr/~exco/NNFS/ANNOUNCE.html</A>&nbsp;
<BR>&nbsp;
<BR>&nbsp;&nbsp; Reflect
<BR>&nbsp;&nbsp; <A HREF="http://sunsite.unc.edu/pub/Linux/utils/file/reflect.lsm">http://sunsite.unc.edu/pub/Linux/utils/file/reflect.tar.gz</A>

<P>NNFS is a a good attempt to solve this problem, but it relies on file
dates to "synchronise" file systems "automatically" which interferes with
other tools that rely on file dates and does not allow the user to choose
which file system is to be the "source" and which the "destination". It's
also a rather complicated implementation written part in C and part in
Shell which I have been unable to make work flawlessly using Zip disks
as the "NNFS media" (probably just me, not the author :-).

<P>Reflect on the other hand is a short, simple perl script that _almost_&nbsp;does
exactly what I want -- it allows one to "reflect" one file-system to another,
copying and optionally deleting only those files that have changed on the
source file system when compared with the destination. The problems with
it is that both file systems must be mounted on the same machine simultaneously.

<P>What I seek is Reflect's functionality but which can use a small intermediate
(eg Zip disk) file system to transport the changes from one large file
system on the source machine to a mirror file system on the destination
machine (and back again in the morning :-).

<P>On a daily basis it's unlikely that I'd generate more than 100 Mb of
changes, so one Zip disk is all that's required, even for mirrored file
systems many Gb's in size.

<P>Modifying the reflect script is probably one way to go, but before I
attempt that I'm keen to learn if anyone else has a simple solution to
this problem.

<P>Many thanks if you can help !

<P>-bruce
<PRE>--&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; *** complex problems have simple easy to understand wrong answers ***</PRE>
&nbsp;&nbsp;&nbsp;</HTML>

--------------F215F165F3C6249834E950AF--
Technical Details
Message-ID: <34D944F4.463846D1@causal.com>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 1103af,fb5a00911eafbaca,start
X-Google-Attributes: gid1103af,public
X-Google-Thread: 100b1f,fb5a00911eafbaca,start
X-Google-Attributes: gid100b1f,public
X-Google-Thread: 102983,fb5a00911eafbaca,start
X-Google-Attributes: gid102983,public
X-Google-Thread: ff9be,fb5a00911eafbaca,start
X-Google-Attributes: gidff9be,public
From: Bruce Tulloch <poster@causal.com>
Subject: Mirroring remote filesystems -- a solution ?
Date: 1998/02/05
Message-ID: <34D944F4.463846D1@causal.com>
X-Deja-AN: 322210912
Content-Type: multipart/alternative; boundary="------------F215F165F3C6249834E950AF"
Organization: The Zipsters
Mime-Version: 1.0
Reply-To: poster@causal.com
Newsgroups: comp.os.linux.questions,aus.computers.linux,comp.os.linux.help,comp.os.linux.misc