Backup script issues

[dwmtractor]

OK, I tried this method from the command line on my Ubuntu 6.06 LTS install, and when I used the

su - zimbra -c "zmcontrol start"

method, although zmcontrol status showed all the modules running, the web UI shows red "X" by Spell, SNMP, MTA, and Antivirus as well as Status. Just going from root to su - zimbra and then running zmcontrol stop & start, and the only red X is by Status. I don't know why, or even where to look to find out why, but if I had to guess I wonder whether running the whole command from root results in some odd file permissions issues.

I'll be interested to hear how it works (or not) for SSS. . .by the way, you didn't say what version you were on. I presume "yum" means SuSe, but what release of Zimbra?

Whatever is going on, although I've had that red X by Status for a couple of weeks (despite stopping & restarting using the shell script backup every night), I am unable to tell that it hurts anything. The graphs and the nightly summary emails are clearly generated by other processes.

Dan

[SSS]

Originally Posted by phoenix

What release of Zimbra are you using and which operating system?

Yes, I should've posted that in the OP, hehe. It's Zimbra 4.5.9 GA, and the OS is Fedora 7.

Originally Posted by phoenix

I think that sudo may have some problems, try the following format for the command (using su - ):

su - zimbra -c "zmcontrol start"

I altered the script to use the su command you suggested above and it appears to start correctly now. Although check a further comment below about it.

Originally Posted by dwmtractor

although zmcontrol status showed all the modules running, the web UI shows red "X" by Spell, SNMP, MTA, and Antivirus as well as Status. Just going from root to su - zimbra and then running zmcontrol stop & start, and the only red X is by Status. I don't know why, or even where to look to find out why, but if I had to guess I wonder whether running the whole command from root results in some odd file permissions issues.
?

I actually got that issue a few times running the new script too. At one stage only the logger and ldap modules were running according to the admin console, but zmcontrol status said they're all up and running which is odd. I restarted the PC and the script seems to be behaving itself at the moment.


PS On a side note, dwmtractor, for your bash backup script it may be better if you have the rsync lines include the --delete parameter. At the moment it'll backup the zimbra folder into a backup folder then compress that folder into a tarball. The next time the script runs it'll just keep adding and updating new files to the backup folder without deleting old files/folders, which could cause junk to build up over time?

Including the --delete option in the command gets rid of files in the destination folder that don't exist at the source.

[dwmtractor]

Originally Posted by SSS

PS On a side note, dwmtractor, for your bash backup script it may be better if you have the rsync lines include the --delete parameter. At the moment it'll backup the zimbra folder into a backup folder then compress that folder into a tarball. The next time the script runs it'll just keep adding and updating new files to the backup folder without deleting old files/folders, which could cause junk to build up over time?

Including the --delete option in the command gets rid of files in the destination folder that don't exist at the source.

Excellent suggestion, SSS, I'm going to make that mod to the script right now.

It looks from this man page like the syntax should be -e --delete. Therefore the whole line will be revised to:

rsync -avHK -e --delete /opt/zimbra/ /backup/zimbra

Thank you!

Dan

[mmorse]

Gonna slowly turn this into a larger script eh?
I made some slight edits for ya to look at - the reasons can be found in the history notes: Open Source Edition Backup Procedure - History - Zimbra :: Wiki
(posting here because I don't know if you both have minor edit emails turned on)

Side track: If you want some fun checkout rotating rsync incermentals & even easier try a rsnapshot setup - it saves a boatload of space

Use it in a more live mode via a crontab and you should really end up with all the important stuff (though for the first 'full' of the entire set that you make be sure that zimbra's stopped) - or throw it into an existing cold script/crontab.

To grab 'exactly what's going on with your box' you could run it on redologs...
zmprov mcf zimbraRedoLogDeleteOnRollover FALSE (then reboot so it applies) should get you decently started.
You can adjust the size by modifying zimbraRedoLogRolloverFileSizeKB (102400 is the 100MB default).

[dwmtractor]

Thanks to sss and Mike for the addition of the Zimbra version check on the script. I moved it down to after the second rsync so as to not have it blown away in the rsync, while preserving the ability of --delete to get rid of the temp files that would otherwise be left over from the first live rsync.

Mike's idea of rsnapshot is an interesting one that could take the shell script from single-backup to a whole incremental stack. I don't have time to play with it now but it's certainly worth exploring!

[SSS]

With the zimbra version thing I put in the wiki bash script, the script is usually run as root thus the rsync commands run as root too. When I was setting up my script I was getting permission denied errors for the creation of the zimbra_version.txt so I chmod 777 the zimbra backup folder and it worked.

Just make sure that where the txt file is going, the zimbra user has write access. But yeah, more sensible where it is now after the second rsync.

[dwmtractor]

Originally Posted by SSS

With the zimbra version thing I put in the wiki bash script, the script is usually run as root thus the rsync commands run as root too. When I was setting up my script I was getting permission denied errors for the creation of the zimbra_version.txt so I chmod 777 the zimbra backup folder and it worked.

That makes sense and I would not have thought of it till my own was erroring out. . .that little factoid ought to be added to the wiki. Do you want to go ahead and put it there, probably as a note along with the one on alternate su and the other on logging?

[mmorse]

Thought I threw in /backup/zimbra/conf/ which should be owned and writable by zimbra.zimbra after the rsync.
(Thought it would be better than messing with permissions)

# Create a txt file in the backup directory that'll contain the current Zimbra server version. Handy for knowing what version of Zimbra a backup can be restored to.
sudo -u zimbra zmcontrol -v > /backup/zimbra/conf/zimbra_version.txt
# or examine your /opt/zimbra/.install_history

[dwmtractor]

Originally Posted by mmorse

Thought I threw in /backup/conf/ which should be owned and writable by zimbra.zimbra after the rsync.
(Thought it would be better than messing with permissions)

So you did. That is the version currently on the wiki. Since SSS originally had it before the rsync, the permissions would not yet have been set.

Thanks for the clarification, Mike! No wiki edit necessary!