Welcome, if you would like to post a comment please register.
We also encourage you to explore all things Zimbra with our team and members of the community.
Hello
I have the follow problem in backup.
I take a full backup in weekly basis (stop all zimbra services and copy /opt/zimbra to another folder), but the size of store folder of backup is much larger that the real one.
Real store folder: 22G ./zimbra/store
Buckup store folder: 164G ./zimbra/store
You need to update your forum profile with the output of the following command (do not post the output in this thread):
Code:
zmcontrol -v
Quote:
Originally Posted by Nikos Lyberakis
Hello
I have the follow problem in backup.
I take a full backup in weekly basis (stop all zimbra services and copy /opt/zimbra to another folder), but the size of store folder of backup is much larger that the real one.
Real store folder: 22G ./zimbra/store
Buckup store folder: 164G ./zimbra/store
As a result, i have problem with disk space.
Does anybody know why that happens ?
Not really, you need to give more details on what method you're using to backup your Zimbra server.
# Outputs the time the backup started, for log/tracking purposes
echo Time backup started = $(date +%T)
before="$(date +%s)"
# Live sync before stopping Zimbra to minimize sync time with the services down
# Comment out the following line if you want to try single cold-sync only
# rsync -avHK --delete /opt/zimbra/ /backup/zimbra
# Remove old backup files - nikos
echo "Remove old backup files"
rm -Rf /backup/*
# which is the same as: /opt/zimbra /backup
# Including --delete option gets rid of files in the dest folder that don't exist at the src
# this prevents logfile/extraneous bloat from building up overtime.
# Now we need to shut down Zimbra to rsync any files that were/are locked
# whilst backing up when the server was up and running.
before2="$(date +%s)"
# Kill any orphaned Zimbra processes
echo "Kill any orphaned Zimbra processes"
kill -9 `ps -u zimbra -o "pid="`
# Only enable the following command if you need all Zimbra user owned
# processes to be killed before syncing
# ps auxww | awk '{print $1" "$2}' | grep zimbra | kill -9 `awk '{print $2}'`
# Copy to backup directory
echo "Copy to backup directory"
cp -Rp /opt/zimbra /backup
# Calculates and outputs amount of time the server was down for
after="$(date +%s)"
elapsed="$(expr $after - $before2)"
hours=$(($elapsed / 3600))
elapsed=$(($elapsed - $hours * 3600))
minutes=$(($elapsed / 60))
seconds=$(($elapsed - $minutes * 60))
echo "Server was down for: $hours hours $minutes minutes $seconds seconds"
# Display Zimbra services status
echo Displaying Zimbra services status...
su - zimbra -c "/opt/zimbra/bin/zmcontrol status"
As far as I'm aware, there should be no reason that your destination folder should have 'grown' that large by using that script. Have you done a comparison of the original directories and the destination ones to see if they're the same or what the differences are?
Below is the comparison.... as you can see, the big difference is in store folder
I don't dispute that the size of the folder is different but have you actually done a comparison of the files in those directory structure to see what, exactly, the difference is? Does the backup store folder contain additional files, are they older, are they large than the original i.e. what actually is consuming the space in the store folder?
i don't understand why your script does an rsync pre-shutdown, but a copy post-shutdown. i would think that would copy *all* of /opt/zimbra to /backup instead of just what's changed. it seems like you should just do another rsync.
Bugzilla
Wiki
Source
Backup - store folder increase rapidly 
Linear Mode
