Data Pull Vs Push

[Kevin Korb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- From http://rsnapshot.org/faq.html:

Q: 	Can I set the snapshot_root to a remote SSH path? I want to push
my backups to a remote server, rather than pull them from a remote server.
A: 	

Rsnapshot does not support a remote snapshot root via SSH. However you
should be able to use a remote snapshot root that is NFS mounted on
the machine that runs rsnapshot but hosted on another machine (NFS
server).

If you are running rsnapshot as user root (which is the normal case),
make sure that the NFS server allows root access for that NFS mount to
the rsnapshot machine as an NFS client. For a solaris NFS server, see
root= in share_nfs(1). For a Linux NFS server, see no_root_squash in
exports(5). Otherwise you might get errors about chown, removing
directories/files, etc if permissions on the NFS server are mapped
from "root" to "nobody".

For advanced users, Matt McCutchen suggested the following
alternative. What you can do instead is put the rsnapshot
configuration file on the destination server (with a local snapshot
root), allocate a "staging" area on that server, and define it as the
sole backup point. To make a snapshot, execute an ordinary rsync push
to the staging area and then invoke rsnapshot on that server to
incorporate the new data into a snapshot. To do this conveniently over
SSH, create the following script rsync-and-kick-rsnapshot on the
destination server:

#!/bin/bash
rsync "$@" && rsnapshot interval

And then pass --rsync-path=/path/to/rsync-and-kick-rsnapshot. With an
rsync daemon, create this script kick-rsnapshot:

#!/bin/bash
if [ "$RSYNC_EXIT_STATUS" == "0" ]; then
        rsnapshot interval
fi

And specify it as the post-xfer exec command for the module containing
the staging area.

If multiple machines need to be backed up, instead of trying to
coordinate their pushes and rotations, the easiest thing to do is to
make a completely separate rsnapshot configuration file and snapshot
root for each. Some more hints, including two approaches to avoid the
use of double the disk space on the destination server, may be found
in this message and this message.

On 01/16/12 15:29, Charles Marcus wrote:
> On 2012-01-16 3:03 PM, Kevin Korb <kmk at sanitarium.net> wrote:
>> On 01/16/12 09:55, L. V. Lammert wrote:
>>> On Mon, 16 Jan 2012, Satish Shukla wrote:
>>>> b)      pulling  the data from source to destination   (
>>>> i.e. running rsync from destination machine)
> 
>>> The main reason to pull is with hard linking of the saved
>>> files, e.g. rsnapshot - only possible with a pull operation.
>>> Security is also a little better, as you have a single
>>> authorized command key on the remote machine so the backup
>>> machine can be secured better (behind a firewall).
> 
>> Actually, rsync is completely capable of doing hard links 
>> (--link-dest) in push or pull mode.  It is rsnapshot that
>> artificially imposes that limitation to rsync.
> 
> Eh?? What are you two talking about?
> 
> I've been doing push backups with hardlinks using rsnapshot for a
> long time. My understanding is that this is much *slower* than
> pulling them, but it certainly *works*.
> 

- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8UkVcACgkQVKC1jlbQAQfjmACgyCRcLNfUreDF+huLj1uYVQtq
m4gAnjsYSqo8ziMxF+FpPhmgghYQRxBk
=XfNE
-----END PGP SIGNATURE-----