BackupPC-users

Re: [BackupPC-users] encrypted pc and pool directory

2012-05-18 10:37:27
Subject: Re: [BackupPC-users] encrypted pc and pool directory
From: "Jeffrey J. Kosowsky" <backuppc AT kosowsky DOT org>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Fri, 18 May 2012 10:36:10 -0400
Gerry George wrote at about 10:27:04 -0400 on Friday, May 18, 2012:
 > On Fri, May 18, 2012 at 9:55 AM, Jeffrey J. Kosowsky
 > <backuppc AT kosowsky DOT org>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.

So? BackupPC has no problem dealing with disparate systems now. It
does not care what the systems are. Plus a "push" system allows for
queuing to manage network and server bandwidth.

If you wish to avoid the central scheduler and initiate backups from
your client, then just write a client-side script that sends a command
to the server (e.g. via 'ssh') to initialize a backup.

 > 
 > 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
 > 
 > ----------------------------------------------------------------------
 > ------------------------------------------------------------------------------
 > Live Security Virtual Conference
 > Exclusive live event will cover all the ways today's security and 
 > threat landscape has changed and how IT managers can respond. Discussions 
 > will include endpoint security, mobile security and the latest in malware 
 > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 > 
 > ----------------------------------------------------------------------
 > _______________________________________________
 > BackupPC-users mailing list
 > BackupPC-users AT lists.sourceforge DOT net
 > List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
 > Wiki:    http://backuppc.wiki.sourceforge.net
 > Project: http://backuppc.sourceforge.net/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/