hello, I successfully installed and configured reoback. I made a testrun (manually) and everything worked fine. The backup was made, everything ok. Then I noticed that when reoback ran as cronjob it kind of "hung" - the cronjob was set for 3 o'clock and late i nteh evenign I noticed a high CPU load. I checked and found out tar was still running. My first idea was that maybe the reason was that I had configured reoback to backup / with just a few exceptions. So I reconfigured and specified each directory separately and did a testrun again. It run fine, a little smoother, basically a full backup took 1 1/2 hours the transfer itsself 30mins... but today I just noticed tar was still running... and reoback.pl and run_reoback.sh are also running. So here I am - what can I check, how can I enable some logging to find out why it does not run when used with cron? here is my cronjob: 3 3 * * * /etc/reoback/run_reoback.sh | mail -s "reoback" postmaster@mydomain
What's in /etc/reoback/run_reoback.sh? Did you use full paths for all commands in that script? The PATH variable might be different in a cron job and on the shell.
basically this is its content, except for the shebang... I started the manual run like this: reoback.pl /etc/reoback/settings.conf ... maybe I should change the run_reoback.sh from full path to this ?
You can try and add a PATH variable at the beginning of the run_reoback.sh script (in line 2, right after the shebang), e.g. Code: PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin
the run_reoback.sh look like this now: I also re-enabled the cronjob so I will report back tomorrow with the result of this modification.
I put the whole path into it like you quoted above. there were no error messages, as I had to kill the still runnign scripts. they were consuming too much cpu-time you also have details regarding this in a PM
the tar job and reoback job have now been running for more than 24h and still running, and running. I killed both manually and here is an excerpt from the mail I got: It seems it never finishes with the var directory which is the biggest one on the server... still if I launch it manually it works just fine and finishes in a few minutes...
I had this same problem even when running the script manually on your server. I was thinking that maybe it needs a few hours because the /var directory is so big...
strange, when I first ran it, it was ok... maybe it has an issue with the following updates? I'll delete its datafile tomorrow, that way it will think its the first backup and will perform a full update, those were always working..
