Bug#298134: rsnapshot: should allow remote snapshot_root

[Matt McCutchen]

This is a wontfix upstream.  Adding the ability to perform all the file
manipulations remotely would be a lot of work and would have no
advantage over simply running rsnapshot on the remote machine.

Note that the FAQ (http://rsnapshot.org/faq.html) has since been updated
to describe one way to push backups to an rsnapshot instance on a remote
machine:

https://sourceforge.net/mailarchive/forum.php?thread_name=1201443264.2328.72.camel%40localhost&forum_name=rsnapshot-discuss

-- 
Matt




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#298134: rsnapshot: should allow remote snapshot_root

[Christoph Wegscheider]

forwarded 298134 [EMAIL PROTECTED]
thanks

Hi Charles,
I saw that you already sent a similar mail to the rsnapshot-discuss mailing
list. Therefor I'll just let the bug open and hope that Nathan will
provide such a feature in the next release ;).

Christoph


pgp0Rk4na8RgZ.pgp
Description: PGP signature

Bug#298134: rsnapshot: should allow remote snapshot_root

[Charles Fry]

Package: rsnapshot
Version: 1.2.0-1
Severity: wishlist

It would be most helpful for rsnapshot ro support remote snapshot_roots.
I know that the online FAQ says:

"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:  Currently this is not possible. This would be a nice feature, but
several questions remain unanswered:

* How can the integrity of the snapshot root be guaranteed if one or
  more remote servers have write access to it?
* When snapshots are rotated, which of the potentially several
  remote servers connecting is responsible for performing this task?
* One possibility is to have a "staging" area for files to
  be transferred to, then have rsnapshot sync from this
  staging area into the snapshot root. Can this be
  accomplished without taking up double the disk space? "

This seems to suggest that the primary difficulties with remote
snapshot_roots involve the potential for multiple remote servers to push
into the same snapshot_root.

There is, however, a very simple way to accomplish this:

Document that there can be at most a single server using any given
snapshot_root. If multiple servers are pushing backups to a single
backup server, each needs its own root. I can see no reason why not to
support this functionality, at the very least.

Another option would be to add one additional level of indirection by
automatically creating a directory inside of snapshot_root containing
the name of the connecting server, and to include the daily.* &cetera
directories for each server in a directory unique to that server. This
is really just a way to automatically implement the above solution.

Charles

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (90, 'testing'), (80, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1um
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages rsnapshot depends on:
ii  logrotate 3.7-2  Log rotation utility
ii  perl  5.8.4-6Larry Wall's Practical Extraction 
ii  rsync 2.6.3-2fast remote file copy program (lik

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]