BackupPC-users

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

2012-05-18 10:42:55
Subject: Re: [BackupPC-users] encrypted pc and pool directory
From: Adam Goryachev <mailinglists AT websitemanagers.com DOT au>
To: backuppc-users AT lists.sourceforge DOT net
Date: Sat, 19 May 2012 00:41:28 +1000
On 18/05/12 23:55, Jeffrey J. Kosowsky wrote:
>
> 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.

Actually, when backing up machines on a remote Internet connection, this is really only true for unix like OS's. For windows you need to add some sort of non-standard software (such as SSH) to tunnel/protect the data, as well as some sort of backup/transfer (eg rsync/rsyncd) to actually transfer the changed data sensibly (no, SMB wouldn't work very well).

Backuppc works fantastically for large number of "standard" windows PC on the local network or at least internal network, or for unix like servers and workstations either local or remote.

It doesn't work perfectly for remote windows machines.

In my opinion, it would be nice to be able to move the selection of "share names" and file inclusion/exclusion to the client, along with instigating the actual backup. Also, to be able to get the client to say "Oh, this one file just changed, please add it to the backup"...

This would allow a large number of disparate configurations (ie, backup as a service type users) to maintain their own list of files that get backed up.
The main thing preventing backuppc from being used in this scenario is the lack of a "wizard" which runs on windows, and can be used to configure the backup. If a end user could download some software to run on their PC, configure the username/password allocated to them, configure the shares and files to include/exclude, and then "submit" that to the server. Finally, the client would need to keep some sort of "tunnel" open to the server so that the backups can be run through any firewall/etc. However, I think that this might almost never happen, for the following reasons:
1) People who want this don't know how to write the code (myself included) and those with the money tend to close source
2) People using backuppc tend to be 'unix' people, since it won't run under windows anyway (at least, not on an ntfs)
3) People using backuppc tend to be the "administrator", hence they will just config everything centrally rather than individually on each PC, and better to not allow the stupid end user to muck up any config on their local machine anyway.
> 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.


I would suggest that encryption at the transport layer is probably sufficient, only truly paranoid people want to encrypt without the backup server knowing the content, and truly paranoid people wouldn't trust the backup system either so would create their own :)

Sure, some limited scenario's may require complete stored data encryption, but then a pre-process that encrypts the data before making it available to the standard backuppc methods is sufficient (ie, preusercmd or similar).
> Plus, this would require a near-complete rewrite of BackupPC.
>
> So, why the heck would anyone want to do this?

If backuppc is too far away from what you want, then it is the wrong product for your scenario. Possibly it is the closest to what you want, and so you are tempted to try and squish it into the shape you want, but that just won't work. No product is right for everybody in every scenario.

Don't get me wrong, backuppc is awesome, it does a fantastic job, it just doesn't do everything :)

PS, the recent new exe file for windows clients from Michael Stowe is a great movement towards solving the windows issue. My dream would be to add the "tunnel" software to this client, whether ssh based, or openvpn based, (or both) either would almost completely solve the issue, including allowing winexe to run to a remote (behind NAT router) windows client.

Regards,
Adam

--
Adam Goryachev
Website Managers
www.websitemanagers.com.au

------------------------------------------------------------------------------
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/