6.0.2 Huge increase in disk usage?

[quietas]

OK, now what the heck happened after I upgraded from 5.0.18 to 6.0.1 (and now 6.0.2)? The disk usage has gone through the roof. I had been using under 150gigs total and now my usage is at 98% with 363 of 394gb used. I seem to have traced this to the backup folder and it's using far more than previously.

What happened? How can I fix it? Is this intended? Has no one heard of compression?

At the rate our mail had been growing, we should have had a couple years before needing new drives, but now we need them immediately and I'm deleting older backup sessions. 60gb of mail currently, but nearly 400gb with backups?

[Klug]

6.0 made "-z" default for zmbackup but with no compression.

This allows backup tools to be able to deal with the backup directory because there are no more hard links.

But no more hard links means lots of copies of blobs...
So lots of additional space used.

[Klug]

Additionnal info from Mike : [SOLVED] Compressing blobs in volume

And maybe you should not store your backups on the same volume/HD than your live data... Why not using an external iSCSI SAN or even an USB HD ?

[quietas]

I really wish they had put this in the release notes. That and made the text bold flashing and maybe neon. I'm scrambling atm to get some new SAS 1tb drives to make an HSM and replace a couple of my 146gb drives.

Will Zimbra automatically delete older backups to maintain current backup procedures and also free space for incoming new mail? Or will I need to eliminate older backups manually to free space?

[quietas]

Originally Posted by Klug

Additionnal info from Mike : [SOLVED] Compressing blobs in volume

And maybe you should not store your backups on the same volume/HD than your live data... Why not using an external iSCSI SAN or even an USB HD ?

$$$$ is what it came down to. I would love a SAN, any SAN. No $$$ in my budget for a SAN, I struggle even to have upgrades every 5 years. AD server is from 2002 and running Server 2k for example. As for USB, that is where I am routing the backups now, I set that up this morning as a hold over and my purchasing department is ordering a couple 1TB drives for me supposedly.

[Klug]

It is in the release notes.

•Backup. The default backup now is to backup files as a zip without
compression. Previous to 6.0, backups were not zipped. (Bug 31836)

But you're right, the side effect is not 8-((

ZCS will delete backups as per specified in your backup schedule (30 days by default).

[quietas]

Yeah, I read zip without compression as copied but not compressed. I realize now that it still would have compressed it and it seems like it did to a significant amount. I wonder if there are plans to implement an On/Off for compression in the future?

[cpalsgrove]

I just modified the zimbra crontab to do the backups without compression and it does it the old way which is working for us.

0 1 * * 0-5 /opt/zimbra/bin/zmbackup -i --noZip
0 1 * * 6 /opt/zimbra/bin/zmbackup -f -a all --noZip

[Klug]

Originally Posted by cpalsgrove

I just modified the zimbra crontab to do the backups without compression and it does it the old way which is working for us.

crontab might be rewritten by ZCS.

You should use zmschedulebackup to do changes.
CLI zmschedulebackup Network Edition only - Zimbra :: Wiki

[cpalsgrove]

Originally Posted by Klug

crontab might be rewritten by ZCS.

You should use zmschedulebackup to do changes.
CLI zmschedulebackup Network Edition only - Zimbra :: Wiki

The problem is that zmschedulebackup does not offer a flag for the --noZip option, only compressed and uncompressed zip options. If there is a flag that is not published in the usage notes that will give the --noZip option, I would love to use zmschedulebackup. I'll put in an enhancement request for that flag to be added unless someone can point out something that I'm missing.