Quote:
Originally Posted by heinzg  As I can remember it is not a bug... I want a weekly log with all info i.e. the logging of both Diff & Full backups |
Sorry Heinz.. I made some wrong changes to crontab and things got a bit messed up so I had to wipe everything and start over. I've since put crontab back to the example used in the script and disabled encryption. I made the 1st full backup manually (on the same day that crontab would have run a full backup) with subsequent diff backups run normally from crontab. The manual full backup didn't generate a log file - although I deleted the original file and touched a new one as part of the cleanup process, and that might be why. The null/empty log file was emailed normally though. Without encryption enabled the diff backups appear to create the Backuplist-<date>.txt.gz files okay without throwing the line 901/elastic buffer error. I have someone in the CC list for the email section of the script but neither address receives an email confirming diff backup completion and the log file shows a cumulative list of diff backups for the week, not just the latest diff backup event, so the log is not being cleared/reset on the start of the next diff backup run, which is the behavior I would expect since a diff backup appears to reset the log file (I could be wrong here.. like I said things got a bit screwy).
NB: I built dar as per the simple instructions on the project's website and using the sources from the same site. I get the following running dar -V
dar version 2.3.7, Copyright (C) 2002-2052 Denis Corbin
Long options support : YES
Using libdar 4.4.2 built with compilation time options:
Libz compression (gzip) : YES
Libbz2 compression (bzip2) : YES
Strong encryption : YES
New Blowfish implementation: YES
Extended Attributes support: YES
Large files support (> 2GB): YES
ext2fs NODUMP flag support : YES
Special allocation scheme : YES
Integer size used : unlimited
Thread safe support : YES
compiled the Apr 20 2008 with GNUC version 4.1.2 20070626 (Red Hat 4.1.2-14)
dar is part of the Disk ARchive suite (Release 2.3.7)
I'm not sure if that's relevant or useful, but hey. Please reply or PM me if there's any specific information you need. Based on what other people have posted as script output, the only information of relevance for the line 901 error is what I already posted - everything else in the logs is normal.
Final comment re the unusual elapsed time counter. I've noticed that the Sun NFS box I'm using as the backup target isn't using NTP and the clock is about 5 minutes ahead. I'm not sure if that's a contributing factor in the 1hr 84 mins elapsed time I see recorded on a full backup?
Christian