Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
On Thu, May 10, 2012 at 09:50:40PM -0300, rhatto wrote: Em Thu, May 10, 2012 at 12:45:08PM +0200, intrigeri escreveu: If the rsync handler is not in a good enough state on May 20th yet, I'll release backupninja 1.0 *without* the rsync handler, and upload it to Debian sid. Seems fair and I hope we can do it. I agree. I must say that with the recent patches it seems to work for me. The other things we recently discusses are cosmetics. I actually disagree with #3929 though, now I think of it. The date of the daily/weekly/monthly dirs is valueable, otherwise there is now way to tell when the backup is made. (At least, I frequently use it to check how things are going). I just cycled over all backupninja rsync issues[1], checked their status and made the needed commits so now I think we can test a rsync handler candidate for the 1.0 release. I merged all my recent work in my rsync branch[2] which right now is merged with master. So the rsync handler can be either tested from the current code at my rsync branch[3] or use a diff from from backupinja shipped on debian squeeze. I would like to try it (and do a diff what the changes are), but the host is unforunately down (or unreachable for me). Paul -- Using the Power of Debian GNU/Linux | E-mail: pau...@debian.org Jabber/GTalk: p...@luon.net | GnuPG key ID: 0x50064181 signature.asc Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
Em Fri, May 11, 2012 at 09:53:41AM +0200, Paul van Tilburg escreveu: On Thu, May 10, 2012 at 09:50:40PM -0300, rhatto wrote: Em Thu, May 10, 2012 at 12:45:08PM +0200, intrigeri escreveu: If the rsync handler is not in a good enough state on May 20th yet, I'll release backupninja 1.0 *without* the rsync handler, and upload it to Debian sid. Seems fair and I hope we can do it. I agree. I must say that with the recent patches it seems to work for me. The other things we recently discusses are cosmetics. I actually disagree with #3929 though, now I think of it. The date of the daily/weekly/monthly dirs is valueable, otherwise there is now way to tell when the backup is made. (At least, I frequently use it to check how things are going). I would like to know Intrigeri's opinion about that, but generally I think that leaving the folder dates untouched can led to more confusion than clarification. I just cycled over all backupninja rsync issues[1], checked their status and made the needed commits so now I think we can test a rsync handler candidate for the 1.0 release. I merged all my recent work in my rsync branch[2] which right now is merged with master. So the rsync handler can be either tested from the current code at my rsync branch[3] or use a diff from from backupinja shipped on debian squeeze. I would like to try it (and do a diff what the changes are), but the host is unforunately down (or unreachable for me). Sorry, it was an unexpected downtime. It should be reachable now. -- rhatto at riseup.net pubkey 64E39FCA / keys.indymedia.org signature.asc Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
On Fri, May 11, 2012 at 09:26:10AM -0300, rhatto wrote:
Em Fri, May 11, 2012 at 09:53:41AM +0200, Paul van Tilburg escreveu:
I actually disagree with #3929 though, now I think of it. The date of
the daily/weekly/monthly dirs is valueable, otherwise there is now way
to tell when the backup is made. (At least, I frequently use it to
check how things are going).
I would like to know Intrigeri's opinion about that, but generally I think
that leaving the folder dates untouched can led to more confusion than
clarification.
True, but the touching also leads to a loss of information.
Maybe it should not remove the created metadata file. That could also
be an easy solution.
So daily.1 has a created, and daily.{2,...}, weekly.{1,...} and
monthly.{1...} has created and rotated. At the moment only daily.* seem
to retain the rotated.
On the other hand, in case of both solutions the rsync handler messes
with actual file/dir stat metadata and not just with stuff under
metadata/; this is was I actually dislike most. When I want to get
something back from a backup made on march 4, I just do ls -l in the
backup dir and know what I should use.
I would like to try it (and do a diff what the changes are), but the
host is unforunately down (or unreachable for me).
Sorry, it was an unexpected downtime. It should be reachable now.
Ok, I did a diff. I have run a version of the rsync handler without:
- the lockfile/pipefail fix,
- the debug-instead-of-echo fix,
- the weekly*/monthly*-dir-touching fix,
- the metadata-validation fix
But the basic functionality (including numerous rotation fixes) is there
and works! I'm switching to your rsync handler just yet until the
weekly.*/monthl*-dir-touching situation is resolved.
Cheers,
Paul
--
Using the Power of Debian GNU/Linux | E-mail: pau...@debian.org
Jabber/GTalk: p...@luon.net | GnuPG key ID: 0x50064181
signature.asc
Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
Em Fri, May 11, 2012 at 04:27:28PM +0200, Paul van Tilburg escreveu:
On Fri, May 11, 2012 at 09:26:10AM -0300, rhatto wrote:
Em Fri, May 11, 2012 at 09:53:41AM +0200, Paul van Tilburg escreveu:
I actually disagree with #3929 though, now I think of it. The date of
the daily/weekly/monthly dirs is valueable, otherwise there is now way
to tell when the backup is made. (At least, I frequently use it to
check how things are going).
I would like to know Intrigeri's opinion about that, but generally I think
that leaving the folder dates untouched can led to more confusion than
clarification.
True, but the touching also leads to a loss of information.
Maybe it should not remove the created metadata file. That could also
be an easy solution.
So daily.1 has a created, and daily.{2,...}, weekly.{1,...} and
monthly.{1...} has created and rotated. At the moment only daily.* seem
to retain the rotated.
If I keep the created metadata for weekly and monthly rotations, then
these sets will be rotated in a different date as the current rotate_long
priorizes it over the rotated metadata.
I think it's better to leave this issue outside the 1.0 release as the
current behavior is not a bug.
On the other hand, in case of both solutions the rsync handler messes
with actual file/dir stat metadata and not just with stuff under
metadata/; this is was I actually dislike most. When I want to get
something back from a backup made on march 4, I just do ls -l in the
backup dir and know what I should use.
I would like to try it (and do a diff what the changes are), but the
host is unforunately down (or unreachable for me).
Sorry, it was an unexpected downtime. It should be reachable now.
Ok, I did a diff. I have run a version of the rsync handler without:
- the lockfile/pipefail fix,
- the debug-instead-of-echo fix,
- the weekly*/monthly*-dir-touching fix,
- the metadata-validation fix
From the list above, the lockfile/pipefail is the most important fix.
Other are more cosmetic like you say :)
But the basic functionality (including numerous rotation fixes) is there
and works! I'm switching to your rsync handler just yet until the
weekly.*/monthl*-dir-touching situation is resolved.
Nice to hear.
--
Using the Power of Debian GNU/Linux | E-mail: pau...@debian.org
Jabber/GTalk: p...@luon.net | GnuPG key ID: 0x50064181
--
rhatto at riseup.net
pubkey 64E39FCA / keys.indymedia.org
signature.asc
Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
On Wed, May 09, 2012 at 07:20:25PM -0300, rhatto wrote: If I understood correctly given the info above, weekly.1/ folder dates from Feb 27 01:11 but metadata/weekly.1/rotated says it was rotated at Thu 12 Apr 2012 01:04:38 CEST. What really counts is the date from the metadata file as the folder dates varies if it was created (new increment, mkdir) or moved from an older increment (weekly.1, is the former oldest daily backup). Indeed. However, the dates of the directories seem to indicate a bit when it was last touched (roughly). This makes me feel that we should change the folder dates to something closer to the actual rotation dates (a simple touch would suffice) otherwise it can get confusing to have one date in the folder and other in the increment. For that, I'm opening upstream issue https://labs.riseup.net/code/issues/3929 Agreed. I wouldn't exclude other problems with the weekly/monthly rotations and I could not spot why your weekly.* folders are so old comparing to the daily ones (maybe you disabled your rsync action for a while?) but the rotations seems to be happening. I haven't, but rotating seems to have started to happen! # ls -l total 56 drwxr-xr-x 19 root root 4096 May 10 01:01 daily.1/ drwxr-xr-x 19 root root 4096 May 9 01:01 daily.2/ drwxr-xr-x 19 root root 4096 May 8 01:01 daily.3/ drwxr-xr-x 19 root root 4096 May 7 01:01 daily.4/ drwxr-xr-x 19 root root 4096 May 6 01:01 daily.5/ drwxr-xr-x 19 root root 4096 May 5 01:02 daily.6/ drwxr-xr-x 19 root root 4096 May 4 01:01 daily.7/ drwx-- 15 root root 4096 May 10 01:01 metadata/ drwxr-xr-x 19 root root 4096 Apr 28 01:01 weekly.1/ drwxr-xr-x 19 root root 4096 Feb 27 01:11 weekly.2/ # cat metadata/weekly.*/rotated Sat 05 May 2012 01:00:36 CEST 1336172436 Sat 05 May 2012 01:00:36 CEST 1336172436 I still need to provide an unified patch for you to test. I'm very busy with lots of stuff but I'll try to do it soon. Sure, no problem. As it seems to be going right now, I can leave it running. Paul -- Using the Power of Debian GNU/Linux | E-mail: pau...@debian.org Jabber/GTalk: p...@luon.net | GnuPG key ID: 0x50064181 signature.asc Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
Hi, backupninja upstream and Debian maintainer hat on: I trust you to find a good long-term solution, but the backupninja 1.0 release is currently blocked by the remaining critical bugs in the rsync handler, and the Wheezy freeze is coming *soon*, so I now need to set a clear deadline: If the rsync handler is not in a good enough state on May 20th yet, I'll release backupninja 1.0 *without* the rsync handler, and upload it to Debian sid. If disabling this or that operation mode is an acceptable workaround, and avoids removing the handler altogether, e.g. because the remaining bugs affect only one specific mode of operation, I'd be fine with it too. If this is the chosen way, just tell me, push commits that disable the faulty operation mode to a specific branch aimed at 1.0 release, and ask me to pull from there. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
Em Thu, May 10, 2012 at 12:45:08PM +0200, intrigeri escreveu: backupninja upstream and Debian maintainer hat on: I trust you to find a good long-term solution, but the backupninja 1.0 release is currently blocked by the remaining critical bugs in the rsync handler, and the Wheezy freeze is coming *soon*, so I now need to set a clear deadline: If the rsync handler is not in a good enough state on May 20th yet, I'll release backupninja 1.0 *without* the rsync handler, and upload it to Debian sid. Seems fair and I hope we can do it. I just cycled over all backupninja rsync issues[1], checked their status and made the needed commits so now I think we can test a rsync handler candidate for the 1.0 release. I merged all my recent work in my rsync branch[2] which right now is merged with master. So the rsync handler can be either tested from the current code at my rsync branch[3] or use a diff from from backupinja shipped on debian squeeze. I'm deploying the current rsync handler code on my systems to see if it's stable enough. Paul, could you also test this new version? [1] https://labs.riseup.net/code/projects/backupninja/issues [2] https://git.sarava.org/?p=backupninja.git;a=shortlog;h=refs/heads/rsync [3] https://git.sarava.org/?p=backupninja.git;a=blob_plain;f=handlers/rsync.in;hb=refs/heads/rsync -- rhatto at riseup.net pubkey 64E39FCA / keys.indymedia.org signature.asc Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
Em Tue, Apr 24, 2012 at 03:13:23PM +0200, Paul van Tilburg escreveu: On Mon, Apr 09, 2012 at 02:01:45PM +0200, Paul van Tilburg wrote: I can confirm that after applying the patch, backups seem to be running again (first run with patch was Apr 7 00:36): # ls -l total 40 drwxr-xr-x 19 root root 4096 Apr 9 01:12 daily.1/ drwxr-xr-x 19 root root 4096 Apr 8 01:10 daily.2/ drwxr-xr-x 19 root root 4096 Apr 7 01:14 daily.3/ drwxr-xr-x 19 root root 4096 Apr 7 00:36 daily.4/ drwxr-xr-x 19 root root 4096 Feb 27 01:11 daily.5/ drwx-- 11 root root 4096 Apr 9 01:12 metadata/ And... I have found another problem. Sorry! The daily backups seem to run fine, but two weeks later, I still have no weekly backups: Hi Paul, don't need to apologize. I would say exactly the opposite: sorry for you doing the work I'm not doing well recently which is a proper debug of backupninja rotation functions. # ls -l total 52 drwxr-xr-x 19 root root 4096 Apr 24 01:01 daily.1/ drwxr-xr-x 19 root root 4096 Apr 23 01:01 daily.2/ drwxr-xr-x 19 root root 4096 Apr 22 01:01 daily.3/ drwxr-xr-x 19 root root 4096 Apr 21 01:01 daily.4/ drwxr-xr-x 19 root root 4096 Apr 20 01:01 daily.5/ drwxr-xr-x 19 root root 4096 Apr 19 01:01 daily.6/ drwxr-xr-x 19 root root 4096 Apr 18 01:01 daily.7/ drwx-- 14 root root 4096 Apr 24 01:01 metadata/ drwxr-xr-x 19 root root 4096 Feb 27 01:11 weekly.1/ drwxr-xr-x 19 root root 4096 Jan 13 01:07 weekly.2/ drwxr-xr-x 18 root root 4096 Jan 4 01:04 weekly.3/ When running backupninja in debug mode, it says that it thinks that each weekly.* is not old enough as it doesn't match the 7d/14d/21d/etc. old requirement. I think the metadata is fixed now for the daily stuff, but not the weekly stuff, concerning what I found: # cat metadata/weekly.1/rotated Thu 12 Apr 2012 01:04:38 CEST 1334185478 Obviously, weekly.1 is not rotated April 12, but February 27, the same holds for weekly.2 and weekly.3, but then with April 7. If I understood correctly given the info above, weekly.1/ folder dates from Feb 27 01:11 but metadata/weekly.1/rotated says it was rotated at Thu 12 Apr 2012 01:04:38 CEST. What really counts is the date from the metadata file as the folder dates varies if it was created (new increment, mkdir) or moved from an older increment (weekly.1, is the former oldest daily backup). This makes me feel that we should change the folder dates to something closer to the actual rotation dates (a simple touch would suffice) otherwise it can get confusing to have one date in the folder and other in the increment. For that, I'm opening upstream issue https://labs.riseup.net/code/issues/3929 I wouldn't exclude other problems with the weekly/monthly rotations and I could not spot why your weekly.* folders are so old comparing to the daily ones (maybe you disabled your rsync action for a while?) but the rotations seems to be happening. I still need to provide an unified patch for you to test. I'm very busy with lots of stuff but I'll try to do it soon. -- rhatto at riseup.net pubkey 64E39FCA / keys.indymedia.org signature.asc Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
Hello all, On Mon, Apr 09, 2012 at 02:01:45PM +0200, Paul van Tilburg wrote: I can confirm that after applying the patch, backups seem to be running again (first run with patch was Apr 7 00:36): # ls -l total 40 drwxr-xr-x 19 root root 4096 Apr 9 01:12 daily.1/ drwxr-xr-x 19 root root 4096 Apr 8 01:10 daily.2/ drwxr-xr-x 19 root root 4096 Apr 7 01:14 daily.3/ drwxr-xr-x 19 root root 4096 Apr 7 00:36 daily.4/ drwxr-xr-x 19 root root 4096 Feb 27 01:11 daily.5/ drwx-- 11 root root 4096 Apr 9 01:12 metadata/ And... I have found another problem. Sorry! The daily backups seem to run fine, but two weeks later, I still have no weekly backups: # ls -l total 52 drwxr-xr-x 19 root root 4096 Apr 24 01:01 daily.1/ drwxr-xr-x 19 root root 4096 Apr 23 01:01 daily.2/ drwxr-xr-x 19 root root 4096 Apr 22 01:01 daily.3/ drwxr-xr-x 19 root root 4096 Apr 21 01:01 daily.4/ drwxr-xr-x 19 root root 4096 Apr 20 01:01 daily.5/ drwxr-xr-x 19 root root 4096 Apr 19 01:01 daily.6/ drwxr-xr-x 19 root root 4096 Apr 18 01:01 daily.7/ drwx-- 14 root root 4096 Apr 24 01:01 metadata/ drwxr-xr-x 19 root root 4096 Feb 27 01:11 weekly.1/ drwxr-xr-x 19 root root 4096 Jan 13 01:07 weekly.2/ drwxr-xr-x 18 root root 4096 Jan 4 01:04 weekly.3/ When running backupninja in debug mode, it says that it thinks that each weekly.* is not old enough as it doesn't match the 7d/14d/21d/etc. old requirement. I think the metadata is fixed now for the daily stuff, but not the weekly stuff, concerning what I found: # cat metadata/weekly.1/rotated Thu 12 Apr 2012 01:04:38 CEST 1334185478 Obviously, weekly.1 is not rotated April 12, but February 27, the same holds for weekly.2 and weekly.3, but then with April 7. Cheers, Paul -- Using the Power of Debian GNU/Linux | E-mail: pau...@debian.org Jabber/GTalk: p...@luon.net | GnuPG key ID: 0x50064181 signature.asc Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
On Tue, Apr 17, 2012 at 12:56:58AM -0300, rhatto wrote: Em Sun, Apr 15, 2012 at 04:26:27PM +0200, Paul van Tilburg escreveu: I meant this differently. It just seems that if you make an error, e.g. you set: rsync_options = --non-existing-bla --syntax-error-coming up and rsync bails out, or maybe segvs or whatever, backupninja happily reports via email: SUCCES. Yes, that's another issue: https://labs.riseup.net/code/issues/3892 Ok. I know that the moreutils package in Debian has the mispipe tool[1] to return the exit code of the first program rather than the latter. Maybe this tool or its source code is useful. 1: http://packages.debian.org/source/unstable/moreutils I am reluctant to apply this... why also first $created but \$created in the second hunk? The second hunk refers to code to be executed in the remote side, so it has to be escaped to not evaluate at the local side. Maybe would be better to wait me to sort out the most important rsync handler issues and then give you a single patch to try so I don't bother you too much with my development as I already did. :/ Ok, it's no problem. I was just indicating this to mention that my results may become unreliable at some point due to this. But I keep a rsync.orig file to compare, and sometimes I patch by commenting out the old code. I think it's still good. :) Paul -- Using the Power of Debian GNU/Linux | E-mail: pau...@debian.org Jabber/GTalk: p...@luon.net | GnuPG key ID: 0x50064181 signature.asc Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
Em Sun, Apr 15, 2012 at 04:26:27PM +0200, Paul van Tilburg escreveu: On Thu, Apr 12, 2012 at 08:54:55PM -0300, rhatto wrote: Em Mon, Apr 09, 2012 at 02:01:45PM +0200, Paul van Tilburg escreveu: What it IMO doesn't solve, is the fact that the handler gave a syntax error and probably returned and error code, but backupninja intepreted this as backup succesful. This worries me a bit. I meant this differently. It just seems that if you make an error, e.g. you set: rsync_options = --non-existing-bla --syntax-error-coming up and rsync bails out, or maybe segvs or whatever, backupninja happily reports via email: SUCCES. Yes, that's another issue: https://labs.riseup.net/code/issues/3892 I think that the only way to avoid that is to validate the metadata. The following commit tries to do it: https://git.sarava.org/?p=backupninja.git;a=commitdiff;h=e22107cf0954f29215052becf848bc28b47ffbe0 Could you test to see if it works? I am reluctant to apply this... why also first $created but \$created in the second hunk? The second hunk refers to code to be executed in the remote side, so it has to be escaped to not evaluate at the local side. Maybe would be better to wait me to sort out the most important rsync handler issues and then give you a single patch to try so I don't bother you too much with my development as I already did. :/ -- rhatto at riseup.net pubkey 64E39FCA / keys.indymedia.org signature.asc Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
On Thu, Apr 12, 2012 at 08:54:55PM -0300, rhatto wrote: Em Mon, Apr 09, 2012 at 02:01:45PM +0200, Paul van Tilburg escreveu: What it IMO doesn't solve, is the fact that the handler gave a syntax error and probably returned and error code, but backupninja intepreted this as backup succesful. This worries me a bit. I meant this differently. It just seems that if you make an error, e.g. you set: rsync_options = --non-existing-bla --syntax-error-coming up and rsync bails out, or maybe segvs or whatever, backupninja happily reports via email: SUCCES. I think that the only way to avoid that is to validate the metadata. The following commit tries to do it: https://git.sarava.org/?p=backupninja.git;a=commitdiff;h=e22107cf0954f29215052becf848bc28b47ffbe0 Could you test to see if it works? I am reluctant to apply this... why also first $created but \$created in the second hunk? Paul -- Using the Power of Debian GNU/Linux | E-mail: pau...@debian.org Jabber/GTalk: p...@luon.net | GnuPG key ID: 0x50064181 signature.asc Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
Em Mon, Apr 09, 2012 at 02:01:45PM +0200, Paul van Tilburg escreveu: What it IMO doesn't solve, is the fact that the handler gave a syntax error and probably returned and error code, but backupninja intepreted this as backup succesful. This worries me a bit. I think that the only way to avoid that is to validate the metadata. The following commit tries to do it: https://git.sarava.org/?p=backupninja.git;a=commitdiff;h=e22107cf0954f29215052becf848bc28b47ffbe0 Could you test to see if it works? Thanks again :) -- rhatto at riseup.net pubkey 64E39FCA / keys.indymedia.org signature.asc Description: Digital signature
Bug#654192: Fwd: Bug#654192: [pkg-backupninja] Bug#654192: backupninja rsync handler bugs
On Fri, Apr 06, 2012 at 05:34:09PM -0300, rhatto wrote: Em Fri, Apr 06, 2012 at 09:37:37AM +0200, intrigeri escreveu: Please fix ASAP so we can release 1.0 :) This is top priority for me. :) I opened https://labs.riseup.net/code/issues/3868 to deal with this new issue. Paul, the attached patch possibly fix this issue, but you might need to manually edit your backup metadata and add a newline between the human-readable date and the timestamp, so it looks like Mon 27 Feb 2012 01:06:08 CET 1330301168 Could you confirm if backups work again after applying this patch? Thanks again for testing the handler. I can confirm that after applying the patch, backups seem to be running again (first run with patch was Apr 7 00:36): # ls -l total 40 drwxr-xr-x 19 root root 4096 Apr 9 01:12 daily.1/ drwxr-xr-x 19 root root 4096 Apr 8 01:10 daily.2/ drwxr-xr-x 19 root root 4096 Apr 7 01:14 daily.3/ drwxr-xr-x 19 root root 4096 Apr 7 00:36 daily.4/ drwxr-xr-x 19 root root 4096 Feb 27 01:11 daily.5/ drwx-- 11 root root 4096 Apr 9 01:12 metadata/ What it IMO doesn't solve, is the fact that the handler gave a syntax error and probably returned and error code, but backupninja intepreted this as backup succesful. This worries me a bit. [...] Date: Fri, 30 Mar 2012 11:10:39 +0200 From: Paul van Tilburg pau...@debian.org Info: Rotating /media/Backup/target.rsync///... Debug: daily.25 -- daily.26 Debug: daily.24 -- daily.25 Debug: daily.23 -- daily.24 Debug: daily.22 -- daily.23 Debug: daily.21 -- daily.22 Debug: daily.20 -- daily.21 /usr/share/backupninja/rsync: line 425: [: too many arguments /usr/share/backupninja/rsync: line 439: Mon 27 Feb 2012 01:06:08 CET 1330301168: syntax error in expression (error token is 27 Feb 2012 01:06:08 CET 1330301168) Info: finished action /etc/backup.d/10.target.rsync: SUCCESS Debug: send report to root Info: FINISHED: 1 actions run. 0 fatal. 0 error. 0 warning. Cheers, Paul -- Using the Power of Debian GNU/Linux | E-mail: pau...@debian.org Jabber/GTalk: p...@luon.net | GnuPG key ID: 0x50064181 signature.asc Description: Digital signature
