On Tue, Sep 19, 2006 at 10:56:59AM -0500, Richard Geoffrion wrote:
>
> IS *THIS* **FINALLY** a reason to do a dirvish-PUSH instead of a
> dirvish pull??? (never mind that I have other VALID reasons to do a
> dirvish-push backup....ie Mac/Netatalk/AFP!!<---a valid reason, dang it!!)
>
> So...is there something "technical' that prevents DIRVISH from sending
> its backups to a remove backup server???
>
>
> Because...it seems like this would be the PERFECT solution for Ken.
> (well....as long as his auditors don't mind root ssh access for his
> backup server)
>
> Ken, what if the root login was restricted to only the backup
> server...with no ssh login allowed on the backup server?
ssh root access for the dirvish backup server means potental root
access for all machines being backed up from any machine being
backed up. The reason for "no push servers" is that by default
it breaks security for every machine getting backed up.
Remember that a complete backup image contains all the information
to completely 0wn a client. And any client with root access to
the backup server can get to any other client image on that server.
If Sarbanes-Oxley forbids server access to clients but permits
client access to servers, then I'm moving my machines off-shore ...
If the push server process is run to a dedicated machine designed
to hold backups for the one client only, that would be relatively
safe, but that is not what dirvish is intended for, and it would
be quite different code.
If somebody wants to fork the code and write a push server
("pirvish"?), be my guest. The dedicated machine could be a
virtual machine guest running in UML or Xen, on a host holding
many such instances. Not efficient for disk storage, of course.
But that way, 0wning one client would not inevitably 0wn the
backup server, providing enough information to 0wn all the clients.
Unless the root server rsync is rewritten also, the push approach
would also allow the client to scribble over old backups, so they
no longer can be used for recovery after a client security breach.
The main reason I run backups is because I want secure copies of
clients in case they get 0wned. I do not expire because it is
not always obvious when a security compromise occurs, and daily
images going back quite a ways are a real help in determining
what files were changed and when. Your reasons for running
backups may vary, of course.
BTW, if you want to run dirvish on a Mac, push versus pull isn't
the major problem. OS-X Mac runs the UFS+ file sustem, which
contains metadata and resource forks that a Linux/BSD/Solaris file
system does not easily accomodate. Moving that metadata requires
a special version of rsync at the Mac end, with some special
command line options. At the receiving end, the rsync process
may need to run in --checksum mode, because the wierd little
files sent along to hold the metadata are generated on the fly
by the client, so the timestamp changes every day. Alternately,
you move and accumulate a new copy of the metadata files every
day; there probably aren't too many of them.
It is possible to recompile a Linux kernel add the UFSplus file
system, and compile the metadata-aware Mac version of rsync for
the server end. But again, that starts looking like a major
change in behavior to serve the Mac, and may be fork-worthy
("mirvish"?).
The Mac issues interest me because my sister just got a Mac Mini
that I will be administering remotely. I've concluded I can't
easily do a network backup for it, because of the file system
differences and because of DSL assymetrical bandwidth issues.
So she gets a little USB drive for local backups, and runs
whatever local software that makes sense. No backup tool is
good for all tasks, not even dirvish.
Keith
--
Keith Lofstrom [EMAIL PROTECTED] Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
_______________________________________________
Dirvish mailing list
[email protected]
http://www.dirvish.org/mailman/listinfo/dirvish
