Thanks for your post, and feed back!
To answer some of your questions in short and to ask some questions to.
Good I see you got mail installed and working. Did the script not print out the following when not finding mailx?
About dar. Dar is my choice of archive due to the the list of features it has in comparison to tar, and the list is well long, e.g. one of the features of dar is the ability to recover single files from the archive with out having to unpack the whole archive. It also has encryption builtin which I will add to the script in the next release for better security. After all we don't want our tapes and dvd being copied by others with intentions we might find offensive!
"For a "Howto" install mailx without postfix please visit the link below"
But the main reason to use dar is for the neat way it make full and then differential backups. Meaning you save a lot of space on your storage media. I have setup dar to make compressed backups archives (gzip -9 level) you can change this be changing COMPRESS=9 to a lower amount.
This is also one of the reasons why it seams that dar is hanging on your system. At over 2GB of data it takes quite a bit of time to create the initial catalogue, and secondly the script is running dar as a background proc in non interactive mode. So it is normal for dar to sit there for a bit seeming not to do anything.
On your spec system and data volume I can imagine that with compression on full and all IO on the same disk, that it can take up the good part of 35 to 50 min for a full backup.
After making a Full backup you now only have to make differential backups to capture and save only file that have changed from those in the full backup archive, plus it is a lot faster now. I would guess on your system depending on the amount of spam you get a day 5 to 10 min and about 60MB data. So to recap you save lots of space on long term storage media through compression and differential backups, Dar has also been instructed not to compress common compressed files thus a performance increase for you.
As for a increased in performance you would have to put your SYNC_DIR on an other disk than where your ARCHIVEDIR is, the basic IO story.
OH yes the script starts dar with “nice 19” (change 19 -> 0 for more speed) which is the lowest priority... not to hinder Zimbra server from doing important mailing work :-)
About there not being any files in TOO_MEDIA_DIR has to do with my logic of doing the backups. The script works on a weekly rotation e.g. On Monday morning it makes a full backup and then every 24 hour there after a differential backup. Until it gets to Monday morning again where it will then transfer the backups from the last week to TOO_MEDIA_DIR where you can then write it to tape or DVD what ever. But the full backup archive should stay in ARCHIVEDIR as dar compares the files from the SYNC_DIR with those in the full backup archive to then create a differential backup file.
So if you use my crontab suggestion you will find files in TOO_MEDIA_DIR one week after running the script for the first time.
The bit about the LOG file. This is sort of a hack if you wish... as the script is/or should mainly be used as a root corn job you should redirect all out put from the script into the same file as stated in LOG=.
Crontab example (run the script with -h to see the right statement for your LOG entry in the contab):
If you don't do the redirect then you will land up this mails with a subject but with no body, which should actually contain the contents of the log file.
0 3 * * 1 /bin/sh /path to script/zmbac.sh -f > /path to log dir/file.log 2>&1
0 3 * * 2-7 /bin/sh /root/zmbac.sh -d >> /path to log dir/file.log 2>&1
A sample print out of the weekly full backup should look something like this, note this system also took 38 min for the task to complete (time for a new office server...):
I hope this helps you some what!
Full Backup started at: 03:00
Old backups found...old week= 08 current week= 09
/data/Backup/zimbra_dars/08_Zimbra_Backup_01-March-2008_DIFF.1.dar moved to /data/Backup/burn/
/data/Backup/zimbra_dars/08_Zimbra_Backup_02-March-2008_DIFF.1.dar moved to /data/Backup/burn/
/data/Backup/zimbra_dars/08_Zimbra_Backup_25-February-2008_FULL.1.dar moved to /data/Backup/burn/
/data/Backup/zimbra_dars/08_Zimbra_Backup_26-February-2008_DIFF.1.dar moved to /data/Backup/burn/
/data/Backup/zimbra_dars/08_Zimbra_Backup_27-February-2008_DIFF.1.dar moved to /data/Backup/burn/
/data/Backup/zimbra_dars/08_Zimbra_Backup_28-February-2008_DIFF.1.dar moved to /data/Backup/burn/
/data/Backup/zimbra_dars/08_Zimbra_Backup_29-February-2008_DIFF.1.dar moved to /data/Backup/burn/
Printing date: 03-March-2008 and software version: *into /opt/zimbra/DATE_VERSION.txt
Doing a hotsync of /opt/zimbra/ to /mnt/fakebackup/
sync went ok
Stopping the Zimbra server
Zimbra server has stopped
kill any left over zimbra procs
Doing a fast cold sync of /opt/zimbra/ & /mnt/fakebackup/ while the Zimbra server is down
sync went ok
Zimbra has started
Stats seems to be running fine...
Writing a full backup called:09_Zimbra_Backup_03-March-2008_FULL in: /data/Backup/zimbra_dars/ with file sizes of max: 4695M
*35430 inode(s) saved
*with 1454 hard link(s) recorded
*0 inode(s) not saved (no file change)
*0 inode(s) failed to save (filesystem error)
*0 files(s) ignored (excluded by filters)
*0 files(s) recorded as deleted from reference backup
*Total number of file considered: 35430
*EA saved for 0 file(s)
Archive Created successfully
Full Zimbra Backup ended at: 03:38
The the full backup took Hr:0 Min:38 Sec:39 to complete
:::::::::::::::::::Cheers Osoffice.de for the script:::::::::::::::::::::::