Hi,
Markus Iturriaga Woelfel wrote on 12.10.2007 at 16:47:29 [[BackupPC-users]
Question about wrapping rsync]:
> I'm attempting to write a wrapper around rsync which will take care
> of creating, mounting and then unmounting and deleting an LVM
> snapshot of the directory I want to back up. I know that I could have
> used the DumpPreUserCmd amd DumpPostUserCmd settings and I may yet
> have to. However, I was hoping to do everything in a single script.
> That way I can re-write paths, etc. on the fly and BackupPC doesn't
> need to "know" where the snapshot was mounted, for example.
if it works, that sounds like a very elegant approach. Does the file tree
of the transferred backup look correct in BackupPC?
> Right now everything works fine up to a point. My snapshot_rsync
> wrapper executes, makes the snapshot, starts the rsync with a Perl
> "system" call. Backups are made without a problem. However, it
> appears that the script gets killed as soon as rsync finishes. If I
> run it from the command line, I have no problem. The script continues
> after the system call and unmounts and removes the snapshot.
>
> So, my script simply stops running after:
> system("$rsyncPath @argList $newShare\n") || die "$rsyncPath @argList
> $shareName failed!";
Maybe because it should be "and" and not "or"? system returns the exit
status of the program, so a 0 return value means success, causing the "die"
to take effect. Aside from that, the die message quotes $shareName whereas
the command uses $newShare. That may or may not be intended :).
Strange, though, that it works from the command line.
> My question is - does BackupPC actively kill the "rsync" after the
> backup is finished? I tried catching SIGPIPE and doing the cleanup
> then, but that didn't help.
Without looking at the code, I would suspect BackupPC to close the socket
after transfer is finished (what else should it do? Wait for the remote side
to close it?). I would imagine that might generate a SIGHUP (probably only
if you've got a controlling tty). SIGPIPE should only be triggered if you
try to write to a closed socket.
On the other hand, if you really had "&&" and not "||" in your code, the
rsync being killed by a signal would trigger your 'die'.
What does your signal handler do? The real cleanup via system()? While Perl
is still inside the first system()? That doesn't sound like a too good idea.
How about just ignoring the signals?
Are you doing a backup of your local machine or of a remote machine via ssh?
If you succeed, please consider sharing your wrapper script via the mailing
list or the wiki (http://backuppc.wiki.sourceforge.net). Using snapshots for
backup in a transparent way is really an interesting thought. If you don't
succeed, sharing your approach may enable others to complete it :).
Regards,
Holger
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
BackupPC-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
