[Leaplist] duplicity recommendation - with a twist

[Chris]

John Simpson wrote:

> On 2008-01-12, at 1538, Dan Cherry wrote:
>
>>
>> I've been doing my backups with tar over ssh, and started looking  
>> into rsync.
>> Debian admin mentioned a pkg called 'duplicity' which uses rsync.
>> Anyone with experience using 'duplicity', care to comment on whether  
>> it's
>> worked for them, or if there are any drawbacks (or showstoppers)?
>
>
> no... i'm using rsync within ssh. 
> http://www.jms1.net/code/rsync-backup.shtml  has the details. (this 
> page has been sitting there, half-written,  for months... your 
> question prompted me to finally finish it. thank  you.)
>
> i remember looking at duplicity in the past. for me, the big 
> advantage  would be the encryption of the backups. however, since i 
> control both  the machine being backed up AND the machine which is 
> pulling the  backups, i don't have a real need for encrypted backups.
>
> i also like the fact that, if i have a real need, i can ssh to the  
> backup machine (which is in my house) and access individual files 
> from  within the backed-up image. this allows me to quickly restore  
> individual files, as well as access large files from the server  
> without having to scp them back across the wire again- they're 
> already  inside the house, so i can access them at 100Mb ethernet speed.
>
> one advantage of doing what i'm doing is that i'm "pulling" the  
> backups using a script on the backup repository machine, rather than  
> the server itself "pushing" the backups to some other box. looking at  
> the documentation...
>
> from http://duplicity.nongnu.org/duplicity.1.html , "Examples",  
> example #4:
>
>> Duplicity enters restore mode because the URL comes before the local  
>> directory.
>
>
>
> to me, this says that the URL (i.e. the remote server) MUST BE the  
> backup archive, and the local directory MUST BE the files you with to  
> back up.
>
> the way i do it, the scripting runs on the backup repository machine-  
> the only thing it requires on the production servers is sshd and the  
> rsync package. my script "pulls" the files, which means that the  
> backup server has access to the live server. to me it makes more  
> sense, and "feels" more secure, because the backup server can be  
> behind a NAT'ed cable modem connection somewhere, where the outside  
> world can't get into it. the live server has to be on the outside in  
> order to do its job- a dedicated backup machine doesn't.
>
> ----------------------------------------------------------------
> | John M. Simpson    ---   KG4ZOW   ---    Programmer At Large |
> | http://www.jms1.net/                         <jms1 at jms1.net> |
> ----------------------------------------------------------------
> | http://video.google.com/videoplay?docid=-1656880303867390173 |
> ----------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Leaplist mailing list
>Leaplist at leap-cf.org
>http://lists.leap-cf.org/mailman/listinfo/leaplist
>  
>
Thanks for the writeup - coincidently, I'm trying to solve a similar
problem this weekend, but I have one additional complexity - a
firewall.

Looks like this:
LocalLinux<--->RemoteBSDFirewall<--->ServerBehindFirewall

I need to back up ServerBehindFirewall to LocalLinux, but I
haven't figured out how to slide ssh through RemoteBSDFirwall.

I have root access on all three machines, so it should be easy,
sort of, but I haven't figured out how to put all the pieces together.

One less-than optimal solution might be to configure port forwarding
on RemoteBSDFirewall to slide all ssh packets directly between
ServerBehindFirewall. That seems a bit like using a sledgehammer
to drive a thumbtack, but...

This can't be a unique scenario, but I still haven't stumbled across
the right documentation.

Any clues, cookie crumbs appreciated.

Cheers,

Chris