On Fri, May 18, 2012 at 9:55 AM, Jeffrey J. Kosowsky
Gerry George wrote at about 16:38:47 -0400 on Thursday, May 17, 2012:
> Actually this coincides with an idea I had for using BackupPC for use as a
> backup service. It would have to operate differently to the standard
> configuration, though. The system I envisioned was as follows:
>
> - rather than the BackupPC Server polling clients, the clients would be
> responsible for initiating the connection to the BackupPC server.
> - The BackupPC server would need to run Rsyncd in order to listen for
> connections and expose the backup store location to the client, based on
> the authentication and other defined criteria (alloted space, compression,
> encryption, authorization)
> - the clients would run rsync (or some other process) which will send
> the data across to the BackupPC server, over SSH (for example), which would
> utilize encryption for the SSH path.
> - Optionally, the data can (possibly) be encrypted BY THE CLIENT, and
> sent across as raw bits to be stored on the Rsync store. This would mean
> that, as was suggested by John's boss, the server does not have access to
> the unencrypted data, as the client could choose their own password which
> the server/service provider would not have. This would mean, though that
> data recovery from failed disks would be a royal pain
>
> Issues:
>
> - Client access to the data - the web interface would become much more
> complex, as it would now need to be accessed over a WAN or Internet in
> order to check or manipulate clients backups and restores.
> - Client would now need to keep "backup state" information
> - WAN link becomes issue - Internet connection speeds will determine
> backup duration.
> - Backing up of clients may be limited to the use of Rsync and SSH.
>
>
> Other Considerations:
>
> - Client can optionally have a "staging server" which offers a web
> interface for local "consumption, interacts directly with the backup server
> (as a sort of gateway), keeps backup state and status, and stores commonly
> accessed info (backup details, file lists, etc), and would be responsible
> for requesting files for restore from the backup server. This could aid
> with system security, as the Backup Service will have less interfaces to
> expose to the public.
> - Secure encrypted communications can then happen between staging server
> and BackupPC server(s), with on-disk encryption, if needed, being done by
> the staging server before shipping files over.
>
>
> This means that BackupPC would need to be changed from a "pull" backup
> system (by the server), to "push" backups (by the clients). It would also
> change the way the web interface operated (if clients now access from the
> server), or the structure and relationship between systems if the option of
> a gateway or staging server is utilized.
>
> While I am not a programmer, and would not be able to even begin to provide
> any assistance in this, I think such an option would not just put BackupPC
> over the top (as it is already there), but would place it in a completely
> new class of software (BaaS - Backups as a Service), and open up a whole
> new realm of options for OSS fans.
>
>
> Any criticisms (or dissecting, correcting, whatever) of the above is
> welcomed. Does anyone think this may be feasible?
Yeah -- why would anyone ever want to do this?
The whole beauty/simplicity of BackupPC is that it does not need any
specialized client to install, manage and run -- it simply uses
existing ssh/rsync/smb/tar/ftp etc. applications. Nor is there
anything to run or break on the client.
Plus, any encryption on the client side hidden to the server would
completely destroy BackupPC's pooling/deduplication feature which is
perhaps one of its strongest and most unique features.
Plus, this would require a near-complete rewrite of BackupPC.
So, why the heck would anyone want to do this?