remote backup options

Darryl Moore darryl-90a536wCiRb3fQ9qLvQP4Q at public.gmane.org
Wed Sep 23 13:04:51 UTC 2009


Thanks, yes after looking into it a bit more I see some of the issues.
The backup server does indeed need to run some scripts which means the
service provider needs to explicitly support it, or allow you ssh login
and allow you to run your own scripts.

rsync.net does allow ssh login, but I'm not sure about user script
support. They do however explicitly support duplicity, which with a
little finagling I was able to get working on a jaunty box. I think this
may be my best solution. At least WRT this service provider.

I still do not agree that rsnapshot is not good for remote backups. It
is promoted for this purpose and with rsync and ssh it should work well.

cheers,
darryl

Lennart Sorensen wrote:
> On Tue, Sep 22, 2009 at 06:20:12PM -0400, Darryl Moore wrote:
>> I think you'll have to explain yourself here. It communicates with the
>> remote server via rsync. Rsync was designed to be efficient at
>> replicating files over a distance.
> 
> Yes but I don't think rsync has an option for doing what rsnapshot wants
> to do, which is rename the last target, then run with that renamed target
> as the hardlink source for unchanged files while rsyncing a new target.
> That is what rsnapshot does.  rsync certainly can do it when the
> destination and previous target are on the localhost, and the source of
> the rsync files is the remote machine.  I don't think it can do it in
> the other direction, although it might.
> 
>> don't you know? You said you used it a lot.
> 
> Yes but I also run debian stable on servers, which means using whatever
> version of rsnapshot it includes.
> 
>> What is the problem that needs solving exactly? I believe the server
>> only needs to run rsync in server mode. The rsnapshot utilities are run
>> on the system to be backed up.
>>
>> Are you still sure we are talking about the same thing?
>>
>> Then why did you say "Well if the remote offers you an NFS mount, then
>> it might work ok."?
> 
> NFS would at least be a disk allowing the rename and hardlink trick to
> be treated as local that I know rsync supports.
> 
> Specifically rsync's --link-dest option takes a directory, not another
> remote rsync target.  That's what makes me think rsnapshot can't do that
> to a remote box, while rsnapshot can pull from a remote box.  It would
> be a nice setup to configure rsnapshot on a backup server to pull the
> backup data from all the clients machines to a central spot, compared
> to configuring each client to try and push their backups to a central
> backup server.
> 
> Of course the fact the rsnapshot config file always shows a local
> filesystem as the backup target, and has lots of ways to specify local
> and remote machines as the source for the files seems to backup my
> understanding.  That's from version 1.3.x though, not 1.4.x.  Checking
> the man page for the current version doesn't change that part though.
> The target of the backup is always a local disk, while the source can
> be local or remote.  Hence the only way to use a remote storage would
> be to treat it like a local disk, such as with NFS (which is a bad idea
> in this case).
> 
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list