NetBSD disk backup over network

[Warner Losh]

From: Sergey Babkin <babkin at verizon.net>
Subject: Re: Re: NetBSD disk backup over network
Date: Tue, 07 Mar 2006 08:33:37 -0600 (CST)

> >From: Bernd Walter <ticso at cicely12.cicely.de>
> >> >From: Ashley Moran <work at ashleymoran.me.uk>
> >> 
> >> >I just saw this slashdotted article: 
> >> >http://ezine.daemonnews.org/200603/dermouse.html
> >> 
> >> Well, I've been running around with this kind of idea for
> >> around 10 years now. Never actually implemented it though.
> >> I can't quite believe that encryption at full disk speeds
> >> makes no noticeable CPU overhead.
> >
> >This sounds as nothing more than a mirror with one disk beeing a remote
> >file.
> >And this is not really a new idea - remote mirror has a long standing
> >tradition.
> >You can already configure these things with GEOM right now.
> >But this is in no way a backup, this just saves you from disk failures
> >which is the purpose of a mirror.
> >What is missing is history in the remote image so that one can access
> >older contents.
> 
> You can easily save the stream of updates as a redo
> log (well, that's the idea I've been running around with).
> Then you can roll forward from the full backup points using
> this log, and also use it for online backups while
> the operations are still running. Of course, it would 
> probably require an fsck to get things actually mounted.
> My impression from the article was that he had this thing 
> as well.

Years ago, I did something called Datastar.  We did remote geographic
mirroring between different sites at the block level.  This worked
only so so.  The biggest problem was that on solaris (and FreeBSD too,
I'd think) the buffer cache would persist in core a long time before
being shipped out to disk in some cases for busy blocks.  This made
the remote system unusable most of the time.  We had no way of knowing
how good/bad the actual data was due to these buffering issues.

The problem also was that fsck would break the mirror if you did it in
write mode, forcing a complete resync (optimized, of course, but still
expensive).  As would mounting the file system r/w.  There were also
major issues with solaris mounting it read-only when the mirroring
daemon was writing to the disk.

These issues aren't insurmountable, but can be difficult to cope
with.  The missing data issue is likely the biggest, most difficult
problem to face.

Warner