I've pondered the feedback and revised my proposal to the client. Here
is the revised project objectives. Notably, this is the addition of 4),
the deletion of the whole slew of items actually related to handling
versioned files, and mention of preexisting work on 1).
I've took a little gander at some of the backup wrappers, and it looks
like I will probably use one of these. I'll have to look a bit closer
to see which ones best fit my needs.
Thanks,
-Jay 'Eraserhead' Felice
Project objectives
The backup system project will meet the following objectives:
1. Implement SSL connections.
The modified client will use SSL for encryption of the protocol
stream. Existing clients can use an external shell program such as SSH
to provide encryption, but this is not portable and it is difficult to
manage.
An "--ssl" option will be added to the rsync program to enable
this
feature. This option will be accepted in both client and daemon mode.
Patches to rsync exist which do this. They will be evaluated and
applied or modified as appropriate.
2. Write a Windows backup service.
This service will be a wrapper for the rsync program. It will read its
configuration from the registry, then loop forever attempting to back
up configured directories to the server then sleeping a configurable
interval.
The backup service will be aware of changes to its configuration and
adjust its operation appropriately.
3. Write a configuration GUI for the Windows backup service.
This will be a simple program which maintains the registry settings.
It can be used to set the server, authentication information, and
select which directories should be backed up to the server.
4. Add a "--link-dest-type" option.
Currently, rsync's "--link-dest" option will hard link
files against
an older copy in an identical directory structure when they have not
changed in order to save space. With this option, the user would be
able to specify the link destination type as either "mirror" or
"hash." Mirror is the default, and will behave like existing
versions
of rsync.
The "hash" type will calculate a directory name based on a
strong hash
of the file and the file's size, for example
"/f7/d6/22/d9e9a6d8b9e9e4f00/1ff". rsync will search this
directory
for a file with identical contents to the one being transferred. If it
finds one, it will hard link the transferred file to it. If it does
not, it will create a new file with the next available integer
containing the new file and hard link it to the destination.
This will allow us to store only one copy of a file which might exist
in multiple places in a filesystem or even on multiple clients.
5. Write a restore GUI for Windows.
This program will be a graphical wrapper for the rsync command. It
will read the backup service's configuration to find the server and
get authentication information, then it will display backed-up
versions of files in a file-browser type interface. It will allow the
user to select files and versions to restore.
6. Create Windows installer.
Cronosys will create the files required to build a self-installing
executable for Windows which contains all of the programs, utilities,
and data files required to back up to a server.
--
Jason M. Felice
Cronosys, LLC <http://www.cronosys.com/>
216.221.4600 x302
On Tue, Oct 14, 2003 at 01:09:03PM -0400, Jason M. Felice wrote:> I've pondered the feedback and revised my proposal to the client. Here > is the revised project objectives. Notably, this is the addition of 4), > the deletion of the whole slew of items actually related to handling > versioned files, and mention of preexisting work on 1). > > I've took a little gander at some of the backup wrappers, and it looks > like I will probably use one of these. I'll have to look a bit closer > to see which ones best fit my needs. > > Thanks, > -Jay 'Eraserhead' Felice > > > Project objectives > > The backup system project will meet the following objectives: > > 1. Implement SSL connections. > > The modified client will use SSL for encryption of the protocol > stream. Existing clients can use an external shell program such as SSH > to provide encryption, but this is not portable and it is difficult to > manage. > > An "--ssl" option will be added to the rsync program to enable this > feature. This option will be accepted in both client and daemon mode. > > Patches to rsync exist which do this. They will be evaluated and > applied or modified as appropriate.The patches that exist have issues with the three-way connection. That is the primary reason they have not been accepted although they have tended to have problems with key management as well. A better use of your developer time might be to work on fixing the cygwin hang problem running rsync over ssh. I suspect that the delays in fixing this problem have been a lack of resources committed to fixing it. Using ssh is very manageable and only a portability problem for legacy systems.> 2. Write a Windows backup service.[snip]> 3. Write a configuration GUI for the Windows backup service.[snip]> 4. Add a "--link-dest-type" option. > > Currently, rsync's "--link-dest" option will hard link files against > an older copy in an identical directory structure when they have not > changed in order to save space. With this option, the user would be > able to specify the link destination type as either "mirror" or > "hash." Mirror is the default, and will behave like existing versions > of rsync. > > The "hash" type will calculate a directory name based on a strong hash > of the file and the file's size, for example > "/f7/d6/22/d9e9a6d8b9e9e4f00/1ff". rsync will search this directory > for a file with identical contents to the one being transferred. If it > finds one, it will hard link the transferred file to it. If it does > not, it will create a new file with the next available integer > containing the new file and hard link it to the destination.Cute idea. Will be dog slow compared to a normal rsync. You may want to sixel the hash which is 20 bytes. --link-by-hash=dir would be a better name.> > This will allow us to store only one copy of a file which might exist > in multiple places in a filesystem or even on multiple clients.I wouldn't recommend accepting this option as part of a proposal. It is vaporware that even if created has no assurance of becoming a part of the mainline codebase. Unless accepted into mainline the customer would then have a patched rsync that needs to be repatched every time there is an important (read security) update to mainline and no support from the community.> 5. Write a restore GUI for Windows.[snip]> 6. Create Windows installer.[snip] -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt