From: Gerry G. <geo...@gm...> - 2012-05-18 14:27:13
|
On Fri, May 18, 2012 at 9:55 AM, Jeffrey J. Kosowsky <bac...@ko...>wrote: > 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? > > Well, the data de-duplication issue has been conceded. However, why would one wish to have a "push" backup server which waits for the clients to send backups - easy, to run a remote backup service for disparate clts on separate (and remote) networks, whose systems are all separate, distinct and unrelated to each other. I think there may be a window of opportunity there. As far as the complete re-write, if encryption is left out, it may only require a rewrite of the web front-end, since all of the other pieces will mostly remain in place. Gerry George |