Menu
▾
▴
RE: [BackupPC-devel] "backuppcd" ?
|
From: Jeroen K. (v. <cr...@at...> - 2005-06-28 06:15:54
|
Take a look at librsync, it's crossplatform library which implements the
Rsync algorithm. Maybe you can use this, I myself thought about implementing
something like this.
A nice feature could be to include database support, just a thought.
-----Original Message-----
From: Craig Barratt [mailto:cba...@us...]
Sent: Monday, June 27, 2005 5:49 AM
To: Roy Keene
Cc: Bac...@li...
Subject: Re: [BackupPC-devel] "backuppcd" ?
Roy Keene writes:
> I've started using BackupPC on my network to manage backups for
> Win32 and Linux clients. I'm currently using the "rsyncd" Xfer method
> but finding it restrictive or underdeveloped in the following ways
> (mostly on
> Win32):
>
> 1. Requires manual configuration to list each drive in Win32.
> I've addressed this by creating a wrapper batch file that generates
> the correct "rsyncd.conf" on start-up, but I still need to specify
> each drive as a seperate "share" in the configuration for that host.
> Thus manual reconfiguration needs to occur on system changes. (Source
> code to the tool that generates the proper rsyncd.conf available upon
> request)
>
> 2. Behaves strangely as a service on Win32. This may be caused by
> my wrapper batch file that generates the rsyncd.conf, but stopping the
> "rsync" service fails.
>
> 3. Doesn't allow for any client-side exclusion lists (like .nsr
> files under Networker). This could probably be partially implemented
> by passing "--exclude-from" to the remote rsyncd (assuming that works)
> and having a single exclusion file rather than a set of them.
>
> 4. rsyncd.secrets contains a clear-text password. This is not good
> for me because various other people have root on some of the systems I
> back up and I do not want them to have full read-write access to
> other's systems. I've mitigated this by only allowing from a single
> IP, but if they wanted they could just steal that IP.
>
>
> I understand the goal of trying to support existing transfer protocols
> rather than implement our own but I propose that we implement our own
> in addition to supporting the other protocols.
>
> I would have no problem designing, creating, documenting, and
> maintaining the "client" (i.e., portion that runs on the backup client
> nodes) end of this. I'd likely write it in C with the following
parameters:
>
> 1. Portable across at least the following systems:
> Windows
> UNIX-like (Linux, *BSD, Solaris, IRIX, HP-UX, ...)
> Mac OS X
> QNX
>
> 2. Provides a unified namespace to all non-removable media. That
> is, under Windows, for example there would be a "share" called `/'
> that has the children "C", "D", and "E" which have the children of the
> contents of those drives.
>
> 3. Runs as a native service under operating environments that
> support it (e.g. Windows).
>
> 4. Supports extended attributes and ACLs.
>
> 5. Supports hashed (MD5) passwords.
>
> 6. Supports local directives files (e.g., ".nsr"-like files)
>
> 7. Minimal configuration required:
> a. Connections allowed from
> b. User / password pairs for access levels (read,
read-write)
>
> 8. More advanced configuration optional:
> a. Exclusions
> b. Inclusions
> c. Scheduling priority
>
> Eventually:
>
> 9. Can upgrade itself over the network. Not too difficult, but not
> worth implementing immediately.
>
>
> If I implemented this, would anyone be interested in doing the same
> for the server-side portion (i.e., the portion that runs on the backup
> server), probably in Perl ?
>
> If not, I'd likely look into making mine as rsyncd compat. as possible
> within the specifications of the protocol.
>
> Please feel free to respond with misc. comments on the idea, or a
> project with similar enough goals to my own that may preemptively make
> mine obsolete or unneeded.
>
> Also, I'm very thankful for BackupPC. The pooling system is excellent
> and highly useful.
This is a pretty ambitious plan, but if you can develop something like this
I would be happy to add the server-side code to support it (assuming it is
not too different to rsync). I would recommend leveraging what rsync
currently does, perhaps with some wrappers and/or changes. Rsync
development is very active, although not primarily focussed on Win32.
To the extent it can look like the rsync protocol that would make it easier,
but things like ACLs would require extensions. That said, one major
limitation with rsync is that the entire file list has to be stored in
memory (at a rough cost of 100 bytes per file), which makes backing up very
large file systems difficult.
Also, a major missing feature on windows in accessing locked files.
There has been some discussion on the mail list about the recent additions
to WinXP and Win2003 Server that support snapshots (Volume Shadow Copy
Service). See:
http://blogs.msdn.com/adioltean/archive/2004/12/30/344476.aspx
http://blogs.msdn.com/adioltean/archive/2005/1/5.aspx and
http://blogs.msdn.com/adioltean/archive/2005/01/20/357836.aspx
If VSS could be supported on WinXX machines it would be huge benefit, since
all files could be backed up.
Someone emailed the list that they had successfully added an rsync wrapper
to use VSCS on Win2003 Server for use with BackupPC. I can't find the email
though. Unfortunately WinXP doesn't allow a letter drive mount point for
the shadow, whereas Win2003 does.
One design issue if you take the non-rsync path is the need to design a
protocol that allows efficient pipelining over high-latency networks.
Craig
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from
IBM. Find simple to follow Roadmaps, straightforward articles, informative
Webcasts and more! Get everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
BackupPC-devel mailing list
Bac...@li...
https://lists.sourceforge.net/lists/listinfo/backuppc-devel
http://backuppc.sourceforge.net/
|