[SOLVED] Yet Another Backup Script for Community Version

[heinzg]

Originally Posted by jetorres

Please refere to post from member "vdd" stamped 08-05-2009, 02:02 AM, permalink #136.

When a system is big enough the ARCHIVESIZE produces multiple DAR files. In the section code for line 996 the DAR files are verified.
Got down to: "# Create MD5 Checksums to verify archives after writing to media or network transfers"
The code used is [-e $FILENAME] but the $FILENAME variable has a list of file names as $FILENAME='ls -A ...*'

This causes the Not Found error "This should not happen", but the files indeed exist.

To solve the error a 'for loop' may be used but I think the error is propagated on later code sections so the changes required should be made by an experience bash programmer.


Cordially

Jose

Hi,

I think I see the problem you are pointing out. I will build in the loop tomorrow and send you the fixed version for testing.

Cheers
Heinzg

[borngunners]

I am still waiting for the loop version. Please send me the loop version so I can configure my backup test it before migrating users to my live email server

[jetorres]

Originally Posted by heinzg

Hi,

I think I see the problem you are pointing out. I will build in the loop tomorrow and send you the fixed version for testing.

Cheers
Heinzg

Greetings!

If you have a small development system, you can test the same behavior of a large system in this regard by setting the ARCHIVESIZE to a really small value.

I do not have a development system, I only have a production system so I can not test the new code when ready to test.

But seems that others are waiting for the new code willing to test it and share the outcome in case you are in the same situation as I am.

Jose

[nniemeyer]

./zmbak_v.0.5.sh: line 775: /usr/share/man/man1p/uuencode.1p.gz: cannot execute binary file
Null message body; hope that's ok


I am receiving this notification after a full backup.

CentOS release 5.3 (Final)

Any help is greatly appreciated,
Thanks,
Nick

[nniemeyer]

I am not receiving these errors in the CRON job. Shrug...

Thanks,
Nick

[wizzie]

Hi there,

pretty new to Zimbra and linux as well, learning by doing has allways been my tune. Have run in to some problems and would very much apreciate some help.
I have Zimbra installed and up and running with about 350 users. Everything works well and now its time to fix the backups as well. Found this script and tried to set it up:

My machine is a Xeon 2.4 GHz with 2 GB mem and running Ubuntu 8.04 LTS
Downloaded script from http://files.osoffice.de/zmbak_v.0.5.tgz
I scp:ed the script to the /tmp folder
Opened a terminal with putty and did the following

root@mail:/tmp# tar -xf zm*
root@mail:/tmp# ls
gengraphs.out hsperfdata_zimbra zimbra zmbak_v.0.5.tgz
hsperfdata_root logprocess.out zmbak_v.0.5.sh
root@mail:/tmp# chmod +x zmbak_v.0.5.sh
root@mail:/tmp# sh zmbak_v.0.5.sh -INSTALL
: not found.sh: 49:
: not found.sh: 52:
: not found.sh: 59:
: not found.sh: 62:
: not found.sh: 69:
: not found.sh: 73:
: not found.sh: 78:
: not found.sh: 83:
: not found.sh: 91:
: not found.sh: 96:
: not found.sh: 97:
: not found.sh: 101:
zmbak_v.0.5.sh: 123: Syntax error: "(" unexpected (expecting "then")
root@mail:/tmp#

What am I doing wrong? Please help!

Regards

Wizzie

[borngunners]

You will have to extract the script to some location other than /tmp folder because once you reboot your computer the script will be gone. I will suggest the /root directory. After you do that open the file and make the necessary modifications relating to your system. The instructions will be in the script. After completing all that you have to type the following crontab command "crontab -e" to make the necessary backup schedule....

[wizzie]

Thanks for the help, I have edited the script to suit my system setup, but I still get the same error (se my last post).

Should I run it in some other way or what? Have run a lot of scripts earlier and no problem....???

Please help!

[chewitt]

./zmbak_v.0.5.sh: line 775: /usr/share/man/man1p/uuencode.1p.gz: cannot execute binary file

The clue is the /path/file in the error message. An early part of the script runs

whereis uuencode | awk '{print $2}'

to locate the absolute paths for the uuencode binary but on your system this search is returning part of the manpages system instead. I'm 99.999% certain the cause is that you don't have uuencode installed. If you're using CentOS (like I was) running "yum install sharutils" will add /usr/bin/uuencode so that the correct binary is found and used by the script. If you're using Ubuntu then "apt-get install sharutils" (as root) does the same thing.

Christian

[chewitt]

I made some minor tweaks to the script. To apply them copy the code below and paste them over the original section around line 750:

    # over view of all the files which where backed up
    echo "Creating file listing from archive..."
    if [ "$CRYPT" = "yes" ]
	then
	    KEY=`cat "$PASSDIR""$PASSFILE"`
	    nice -19 $DAR_BIN -K bf:$KEY -l "$ARCHIVEDIR""$BACKUPWEEK"_"$BACKUPNAME"_"$BACKUPDATE"_"$PREFIX" -Q\
	    > "$ARCHIVEDIR""$BACKUPWEEK"Backuplist-"$BACKUPDATE".txt && gzip -9 "$ARCHIVEDIR""$BACKUPWEEK"Backuplist-"$BACKUPDATE".txt
	else        
	    nice -19 $DAR_BIN -l "$ARCHIVEDIR""$BACKUPWEEK"_"$BACKUPNAME"_"$BACKUPDATE"_"$PREFIX" -Q\
	    > "$ARCHIVEDIR""$BACKUPWEEK"Backuplist-"$BACKUPDATE".txt && gzip -9 "$ARCHIVEDIR""$BACKUPWEEK"Backuplist-"$BACKUPDATE".txt
	fi
	# Script Timer
    STOPTIME=(`date +%s`)
    RUNTIME=$(expr $STOPTIME - $STARTTIME)
    echo
    echo ":::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::" 
    echo "Zimbra $TYPE backup ended at: `date +%H:%M`" 
    echo "Backup took $(date -d "1970-01-01 $RUNTIME sec" +%H:%M:%S) to complete" 
    echo ":::::::::::::::Cheers Osoffice for the script:::::::::::::::::::::::::"
    (cat $LOG; $UUENCODE_BIN "$ARCHIVEDIR""$BACKUPWEEK"_Backuplist-"$BACKUPDATE".txt.gz "$ARCHIVEDIR"Backuplist-"$BACKUPDATE".txt.gz) \
    | mail -c $EMAILCC -s "Zimbra $TYPE Backup Log on $HOSTNAME" $EMAIL
}

a) I've altered the naming of the backuplist file to follow the format used by the data files, e.g. 38_Zimbra_Backup_03-October-2009_LIST.txt instead of Backuplist-03-October-2009.txt. Doing this ensures the files are matched and relocated along with the .dar and .md5 files when a full backup is run, instead of leaving them orphaned to clutter up the current backup directory.

b) The logic for counting total backup runtime in hours:mins:secs in the original script doesn't quite work and backups taking greater than 1 hour miss-report the number of minutes by not deducting 60 for each hour elapsed, e.g. 1:89:42 is reported instead of 1:29:42. After the change the displayed format is slightly different but elapsed time is shown correctly.

c) I added the backup $TYPE in the summary statement.

Christian