6.0.2 Huge increase in disk usage?

[Rich Graves]

If I upgrade from 5.0.19 to 6.0.4 (we're waiting) and set --noZip, will blobs shared between 5.x and 6.x be hardlinked, or copied anew? If the latter, then I'm better off creating a new backup volume.

Looks like the new zip default is a clear win if you're relying on zimbra backups for DR, have a retention policy of 15 days or less, and/or spool zimbra backups off to tape. If you have another DR strategy (like a replicated SAN or a well-tested DRDB), retain backups for 30 days or more, have very high quotas (meaning lots of old mail, meaning high commonality among full backups), and/or rely on zimbra backups for individual account/folder/mmessage restores, then --noZip can win.

[maumar]

I think that zimbra techs have made a big error.
IMHO, you can change default, but if u do, u should change crontab script, too.
I mean, they could take 2 directions:
1. let the same default as in 5.x, --noZip
2. change default, but adding --noZip to /var/spool/cron/zimbra

letting sysadmins the choice to change backup strategy, if they want to do it.
this is only my very honest opinion.

[quietas]

As a followup, I have added more space since this issue arose, but it became a moot point. At some point this massive increase changed and it went back to using the normal amount. I think the 6.0.3 update did this.

I had updated to 6.0.3 by the time my new drives had arrived. (2x 1tb Segate ES2 for HSM) When I rebuild my server to add two drives I noticed that the drive usage was much lower. I looked back to our ghost image and noticed the same. I can't account for why, but I assume this was a silent pathc they added.

[maumar]

Originally Posted by cpalsgrove

I'll put in an enhancement request for that flag to be added unless someone can point out something that I'm missing.

Hi
have u added the RFE?
I just upgraded from 6.0.3 to 6.0.5 and my settings were wiped; it's useless to suggest to use zmschedulebackup to do changes, if zmschedulebackup has not the proper option.

[cpalsgrove]

Originally Posted by maumar

Hi
have u added the RFE?
I just upgraded from 6.0.3 to 6.0.5 and my settings were wiped; it's useless to suggest to use zmschedulebackup to do changes, if zmschedulebackup has not the proper option.

I made the RFE on November 12th and was given a quick response that what I was asking for was included in RFE 9594 which was added in 2006, more than 3 years before. When I just checked in on RFE 9594, it is targeted for the 7.0 release which isn't even on the roadmap yet. It's ridiculous that we're encouraged to use the zmschedulebackup that doesn't even give all of the options that we need, and we won't be able to properly use it until the next major release is out which could be another year or more. But, I've given up and I just copy out the crontab before I do an upgrade and paste back in the parts that I need. Interestingly enough, when I do a 'zmschedulebackup -q' it shows me the cron entries that I have made with the '--noZip' option, it just does not give me the option to set them that I have found.

[quietas]

I was a bit wrong on what happened when I upgraded actually. The previous upgrades were gone when I reformatted which is why my disk usage dropped. We're back up up to using nearly as much space for each backup as we do with our live mail. My HSM drives I added are what saved our bacon.

The simple ability to check a box in the admin GUI to enable zip compression would be perfect. I rarely need to use the backups and highspeed immediate access is not needed, so something that reduces space would be great.

[chauvetp]

Having this issue as well after the 5.0.19 to 6.0.5 upgrade. I've had to reduce the number of days our backups are on the system to a week (though I'm still backing up to tape).

[quietas]

To relieve our server of the storage crunch, I added a mirror of 2x1gb nearpoint SATA drives and then set them as the HSM. The main storage dropped significantly and I'm back up to a month of backups and the HSM is a bit less than half full.

[ewilen]

I entered two bugs that should cover the issues raised in this thread:

Bug 45634 - add noZip option to zmschedulebackup
Bug 45635 - Provide noZip option with Admin GUI, or ability to change default behavior.

[SimonSpring]

After Upgrade from 5.0.20 to 6.0.6 we noticed the same behaviour on one of our systems: Space is going down. We quickly found out, that the backups were consuming much more space, than before. Not knowing, what to do (and since Zimbra didn't found it necessary to inform through relase notes or what ever), we began to delete older backups, which is somewhat against the strategy.
Zimbra: Here are some Admins, which feel like they had been taken on a ride... what did you plan/think when changing backupprocedure not informing? Is there any proper relieve?