Your message dated Thu, 5 Jan 2012 11:48:48 +0100
with message-id <[email protected]>
and subject line Fixed in the testing/unstable version
has caused the Debian Bug report #654192,
regarding backupninja: rsync backup using long format fails to rotate
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
654192: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654192
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: backupninja
Version: 0.9.8.1-1
Severity: normal
Hi!
I have configured backupninja to do a rsync (pull) backup for some host.
However, after the first backup on day 1 (creating daily.1),
it only rotates once on day 2 (creating daily.2) and then backupninja stops
rotating and starts backuping over daily.1 repeatedly.
Debug: skipping rotation of <backuproot>/target.rsync///daily.2 because it
was created 0 days ago (1 needed).
Debug: skipping rotation of <backuproot>/target.rsync///daily.1 because
<backuproot>/target.rsync///daily.2 already exists.
[..]
Warning: <backuproot>/target.rsync///daily.1 already exists. Overwriting
contents.
The fact is, that daily.2 was created not 0 but 2 days ago, according to
stat and also the contents of <backuproot>/metadata/daily.2/rotated.
Correct me if I am wrong, but I think the rsync handler incorrecly inspects
the metadata. Consider line 402..410 of /usr/share/backupninja/rsync:
for (( i=$oldest; i > 0; i-- )); do
if [ -d $dir.$i ]; then
if [ -f $metadata/created ]; then
created=`tail -1 $metadata/created`
elif [ -f $metadata/rotated ]; then
created=`tail -1 $metadata/rotated`
else
created=0
fi
In this loop, the handler tries to find out which archives should be rotated.
However, the metadata variable is always fixed (earlier) to
<backuproot>/metadata/daily.1. IMO this makes no sense and probably should
be set to $backuproot/metadata/$dir.$i if it exists.
Kind regards,
Paul
--- End Message ---
--- Begin Message ---
Version: 0.9.10-1
The problem is indeed fixed by the 0.9.10-1 package of backupninja.
Given the changelog, it was probably already fixed by 0.9.9-1 but
I have not tested that version. Thanks for the heads up.
I recommend a backport of 0.9.10-1 to stable.
Cheers,
Paul
--
Using the Power of Debian GNU/Linux | E-mail: [email protected]
Jabber/GTalk: [email protected] | GnuPG key ID: 0x50064181
--- End Message ---
