From: Jeffrey J. K. <bac...@ko...> - 2012-05-18 13:56:13
|
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? |