Yet another rsync incremental thread
Hello all, Since the rsync on Panther many things changed in my professional life. This project is abandoned although it should work. But this you already know. What's new? On my new job I have several servers to administrate. Servers that aren't backed up (sic). So, there's why I'm back to rsync. The backup plan I would like: 1) Client side: PCs running rsync (or cwrsync with UTF-8 mod for long names for windows ones). They run rsync (I don't need data encryption so no need to ssh unless it's simpler) and pull data they want to the backup server. This side is OK. 2) Server side: A standard PC with FreeNAS FreeBSD distrib, RAID-1 disks and rsync server. Here I would like the backups to be incremental and rotated, with a sort of time stamp. Here is where things get complicated. Solutions I've found: A - Simpler at the end but would need modifications to rsync: Go further on the backup module of rsync, building in the rotate mv/rm commands. Why simpler? Because a rsync client would only do one command to the rsync server saying there is it, and the server do it's own internal cook with the stuff. No need to additional scripts. I know that rsync isn't an incremental backup tool at the basis but a syncing tool. But as it already do some of the work, why not doing it better? B - As I said before, additional scripts. Do the client open an ssh connection, do the pre_backup.sh then close ssh (as I understood even using ssh for rsync, it uses it own tunnel, and not an already opened one, no?) run rsync, then rerun ssh, do the post_backup.sh. That should work, but why scripting many times (I'm sure I'm not the only one in this case) when it could be done once for all? C - Between A and B solutions, rsync could, in a first time, have an option to run pre and post scripts when running on ssh. In this manner there would not be needed to open and close ssh 3 times. D - I looked at rsnapshot, but it wouldn't help on this case of rotating server side folders. I also found complicated scripts for rotating folders from the server, but the client would need putting a flag on the server saying syncing is done. All of this don't seem to be the good approach for me. To much complicated to respond to some lines of code missing on rsync (OK, missing for me but I know that this isn't the original goal of rsync and it does lovely what it was designed for). Well, I'm not an rsync expert, so please correct my exposé if I'm wrong. I think solution C would be easy to code, solution A would be the ideal for me but requires some more functions. I'm ready to help coding it. What do you think? Am I on the right path? Would this addition being integrated to the main rsync (after testing, of course)? Any other remarks or suggestions? Best regards, Vitorio-- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Yet another rsync incremental thread
On Fri, 2008-07-18 at 12:40 +0200, macuserfr wrote: What's new? On my new job I have several servers to administrate. Servers that aren't backed up (sic). So, there's why I'm back to rsync. The backup plan I would like: 1) Client side: PCs running rsync (or cwrsync with UTF-8 mod for long names for windows ones). They run rsync (I don't need data encryption so no need to ssh unless it's simpler) and pull data they want to the backup server. This side is OK. I think you mean push. 2) Server side: A standard PC with FreeNAS FreeBSD distrib, RAID-1 disks and rsync server. Here I would like the backups to be incremental and rotated, with a sort of time stamp. Here is where things get complicated. Just use an rsync daemon wired up to an rsnapshot installation in sync_first mode, where the daemon module points to the .sync dir in the snapshot root and the post-xfer exec command calls rsnapshot LOWEST-INTERVAL. You can use a listening daemon or a single-use daemon over ssh as you prefer. This is the approach I've been recommending for pushing hard-linked backups for a while; it achieves everything you want without modifying any of the tools. I helped Eric Johansson with a similar setup a while ago: http://lists.samba.org/archive/rsync/2007-December/019470.html If you have multiple clients pushing backups, it's simplest to have a separate module and snapshot root for each client. To keep things manageable, you can write a script to automatically generate the individual rsnapshot.conf files by substituting the necessary values into a template. Matt signature.asc Description: This is a digitally signed message part -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[SCM] rsync branch, master, updated. v3.0.3-22-g28a5b78
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project rsync. The branch, master has been updated via 28a5b78c6f13aeac716d4aaf4248b8d8763c9b8b (commit) via 7bbd60101e81aabc366c0187bd66af5be777deb8 (commit) from d239efa3ff2a834659d6de397dda17aeb6798d9b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 28a5b78c6f13aeac716d4aaf4248b8d8763c9b8b Author: Wayne Davison [EMAIL PROTECTED] Date: Fri Jul 18 17:35:22 2008 -0700 Improved the hard-link logging. commit 7bbd60101e81aabc366c0187bd66af5be777deb8 Author: Wayne Davison [EMAIL PROTECTED] Date: Fri Jul 18 17:34:59 2008 -0700 Turn on flist5 debugging. --- Summary of changes: flist.c | 24 +--- hlink.c |6 +++--- testsuite/hands.test |2 +- 3 files changed, 17 insertions(+), 15 deletions(-) hooks/post-receive -- rsync ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
[SCM] rsync branch, master, updated. v3.0.3-24-g51ce67d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project rsync. The branch, master has been updated via 51ce67d59968560f0e975dc97bb0a22a7edb0610 (commit) via a02348b5df636914e356b539d91ed21f7b3a1ab5 (commit) from 28a5b78c6f13aeac716d4aaf4248b8d8763c9b8b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 51ce67d59968560f0e975dc97bb0a22a7edb0610 Author: Wayne Davison [EMAIL PROTECTED] Date: Fri Jul 18 20:57:52 2008 -0700 Improved the alignment code and changed POOL_APPEND to POOL_PREPEND. commit a02348b5df636914e356b539d91ed21f7b3a1ab5 Author: Wayne Davison [EMAIL PROTECTED] Date: Fri Jul 18 20:46:58 2008 -0700 We now pass the POOL_QALIGN flag to pool_create(). Also optimized the verbose-message check at the start of recv_file_list(). --- Summary of changes: flist.c | 17 --- lib/pool_alloc.c | 144 +++--- lib/pool_alloc.h |2 +- 3 files changed, 94 insertions(+), 69 deletions(-) hooks/post-receive -- rsync ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
