On Fri, Jan 11, 2013 at 10:26 PM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2013-01-12, SilverTip257 silvertip257@gmail.com wrote:
You mentioned about it running with other people changing files ... it works ok for me. I have gigabytes of backups that get rsynced in the
early
to late morning ... not always are backups completely finished when rsync scans the files. So it picks up on it when the cronjob runs the sync a
few
hours later.
Since rsnapshot uses rsync under the hood, this strategy works for rsnapshot as well. The only real hiccup is if a user deletes a file between when it's scheduled to be synced and when rsync actuall reaches it to sync, rsync might produce a harmless error message.
Yep, a harmless error message.
*** You may have to run rsync as root with sudo to preserve all permissions/ownership. *** At work we have it locked down in sudoers to do so. It was a setup that predated my employment there, so I don't know if running it as root was necessary. Using SSH keys for auth.
You can also use an OpenVPN tunnel and NFS mount with no_root_squash. I like this method a lot because the mount can be made read-only, to ensure that no source data ever gets accidentally clobbered. With an ssh key there's a risk (probably minimal, but nonzero) that a fumblefingers might delete some data on the wrong side.
NFS over a VPN tunnel isn't a bad idea -- being able to make the mount read-only can be beneficial.
True, a risk is present if one is manually syncing the data. I run my routine/daily rsyncs via a cronjob, so once it's set it is not going to get fumbled. ;) --dry-run is important to test before clobbering.
--keith
-- kkeller@wombat.san-francisco.ca.us
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos