Zimbra Product Lifecycle Updates and Clarifications

[L. Mark Stone]

Zimbra have updated the Product Lifecycle web page: https://www.zimbra.com/product/product-lifecycle/ by extending and clarifying support coverage for Zimbra 9.0.0, and Zimbra 10.0.x and Zimbra 10.1.x individually. Specifically:

1. End of BOTH General Support AND Technical Guidance for Zimbra 9 is now extended to June 30, 2025.

2. Zimbra 10.0.x also goes End of General Support on June 30, 2025.

3. Zimbra 10.z.x (excluding 10.0.x) goes End of General Support on December 31, 2026.

This change is quite welcomed in that it now allows us to spread our customers' Rolling Upgrades over a longer period.

All the best,
Mark

[ghen]

This is very good news indeed, and particularly gives more time to migrate to the new license implementation.

Thanks for sharing.

[Klug]

Thanks for the head up.

Hopefully 10.x backup will be S3-compatible before 9.0 goes out of support.

[L. Mark Stone]

Thanks for the head up.

Hopefully 10.x backup will be S3-compatible before 9.0 goes out of support.

10.x zmbackup is not fully compatible with S3, at least not with S3 HSM Centralized (now Unified) Storage volumes migrated via a Rolling Upgrade from 8.8.15 in our case. We can back up small mailboxes, like under 1GB-2GB, but anything larger and zmbackup sometimes fails to back up all blobs in the account. In any event, the backup rate even of successful mailbox backups we have observed is sometimes as low as ~10GB/hour.

Until Zimbra fixes this, we have moved to an alternate backup strategy.

We have encouraged our 9.0 customers who have a need to migrate to 10.x sooner rather than later to provision block storage to replace S3 and then do a volume-to-volume move using zxsuite before upgrading to 10.x. If you have S3 and move to 10.x, there is currently no way to get off of S3 - recall zmmboxmove calls zmbackup on the source server as part of the move process.

Presently, the only way to do volume-to-volume moves with 10.x is via SOAP, which is not (yet) fully supported.

So yes, the End of General Support extension for both Zimbra 9.0.0 and Zimbra 10.0.x is most welcome indeed, to give Zimbra more runway to fix these issues.

Separately, we do not recommend S3 for HSM storage with Zimbra 10.x given the current zmbackup engine. Notwithstanding the current defects, it's not cost effective.

Zimbra 10.x backups are periodic Fulls plus Incrementals, whereas the NG Backup is essentially Full Once and Forever Incrementals, with pruning. Much like Apple Time Machine. With Zimbra 10.x, each time you do a Full backup, any cost benefit from S3 Intelligent Tiering you may have had is removed, since reading an object in S3 moves the object back up to the FA, the most expensive tier.

Slower sc1 disks as backup targets are less expensive than S3 FA storage (here in the US, 1.5 cents per GB provisioned per month for sc1 disks versus 2.3 cents per GB per month for S3). Even that though is still a cost increase over what we had with the NG backups which could read S3 volumes at a fast speed.

With best regards to all,
Mark

[Klug]

Hi Mark, thank you for your detailed input.

In our case, we have our own S3 storage (MinIO running on top of ZFS - we do not have enough storage to deal with to setup a MinIO-only infrastructure).
It was not really about S3 storage cost, it's about the way we built the infrastructure and the needed changes (that have costs too).

I already said that several months ago: while it was NG-modules, Synacor were pushing people to use S3 (and centralized) for HSM and backup.
This was the way to go, we built our infrastructure around this and it's been working quite well since.
The day they moved away from NG-modules, all of this came to an end.
The HSM could still use S3 but in another way (so we have to provision twice the storage to migrate) and as you say, it's not cost effective because of zmbackup.
The backup is back to 3.0 days (full + incremental), we have to provision block storage again.

I do think Synacor is very aware of this (S3 vs block storage + costs issues) and hope 10.2 (maybe) would bring us a clever fix to all of this.

[dbayer]

In our case, we have our own S3 storage (MinIO running on top of ZFS - we do not have enough storage to deal with to setup a MinIO-only infrastructure).

Hello,

Sorry to burst in with an off-topic question. But how have you found the performance of running MinIO on top of ZFS? I've been thinking about doing the same, but assumed it would be too much overhead.

Thanks,
Daniel

[Klug]

Sorry to burst in with an off-topic question. But how have you found the performance of running MinIO on top of ZFS? I've been thinking about doing the same, but assumed it would be too much overhead.

The performance is "not very good" in this setup, but it's not just because of ZFS underneath, it's mostly (I think) because Minio is not meant to do that (it's suppose to with with lots of nodes with lots of disks).

I've just setup (this week-end) a new (old) server for with ZFS and Minio:
- Debian with 6.8.12 kernel
- 2 x E5-2630 0 @ 2.30GHz
- 64 GB of RAM (more RAM would be better)
- RAIDZ2 volume with 12 x 8 TB hard-drive and a special volume on SSD (800 GB Intel datacenter SSD)
- Minio setup as "single disk" on a dedicated pool of the RAID2 volume

So if you want me to do some specific benchmark on it, I'd be glad to do them.

[dbayer]

Sorry for taking so long to reply.

I don't have anything specific. As I haven't put much research into this yet. I have an EDMS (Mayan) that could store PDF's in S3 storage. Right now storing them on EXT3 in a virtual Machine on top of ZFS seems to work fine. So this was more me wondering if it is even worth putting in the effort to switch it to Minio.

Thanks for your feedback,
Daniel