Please be advised that as of this writing zmblobchk in 10.0.8. NE has an issue correctly parsing the locator URIs on S3 Secondary Volumes, and will (incorrectly) report all such blobs there as missing.
This means that if you run zmblobchk with the "--missing-blob-delete-item" option against an S3 Secondary Volume (and possibly an S3 Primary Volume; I haven't tested this), zmblobchk will remove all of the legitimate blob entries from MariaDB ("items") thereby making those emails inaccessible to the user(s) until you restore MariaDB.
Suggest to use the "--volumes <volume id>" switch to restrict zmblobchk away from S3 volumes if you must run zmblobchk at all.
zmblobchk apparently works fine as always on block disk-backed volumes; not sure about how zmblobchk works with other supported Cloud and remote storage volumes.
Zimbra have created ZBUG-3675 for this issue.
FWIW, in my experience I have only had to run zmblobchk to correct user-facing NO_SUCH_BLOB errors after some sort of system crash, where there were legitimate email deletions just prior to the crash. On restart, Zimbra's MariaDB rolls back the uncommitted transactions related to the deletions, causing the user to continue to see the listing of emails previously deleted. Clicking on those email listings then triggers the "NO_SUCH_BLOB" error. I'm also given to understand that in very rare cases some IMAP clients when performing an EXPUNGE can cause Zimbra to delete the blobs on disk correctly, but not the corresponding MariaDB item entries.
IOW, running zmblobchk to fix actual NO_SUCH_BLOB errors should be a fairly rare occurrence, but at least until this bug is fixed, if you are running S3 Secondary volumes, running zmblobchk could cause a much greater issue; hence, this post.
Hope that helps,
Mark
P.S. We are using the Zimbra-provided com.zimbra.storemanagers.store.GenericStoreManager Store Manager Class. No idea if this issue applies when using other Store Manager Classes.
This means that if you run zmblobchk with the "--missing-blob-delete-item" option against an S3 Secondary Volume (and possibly an S3 Primary Volume; I haven't tested this), zmblobchk will remove all of the legitimate blob entries from MariaDB ("items") thereby making those emails inaccessible to the user(s) until you restore MariaDB.
Suggest to use the "--volumes <volume id>" switch to restrict zmblobchk away from S3 volumes if you must run zmblobchk at all.
zmblobchk apparently works fine as always on block disk-backed volumes; not sure about how zmblobchk works with other supported Cloud and remote storage volumes.
Zimbra have created ZBUG-3675 for this issue.
FWIW, in my experience I have only had to run zmblobchk to correct user-facing NO_SUCH_BLOB errors after some sort of system crash, where there were legitimate email deletions just prior to the crash. On restart, Zimbra's MariaDB rolls back the uncommitted transactions related to the deletions, causing the user to continue to see the listing of emails previously deleted. Clicking on those email listings then triggers the "NO_SUCH_BLOB" error. I'm also given to understand that in very rare cases some IMAP clients when performing an EXPUNGE can cause Zimbra to delete the blobs on disk correctly, but not the corresponding MariaDB item entries.
IOW, running zmblobchk to fix actual NO_SUCH_BLOB errors should be a fairly rare occurrence, but at least until this bug is fixed, if you are running S3 Secondary volumes, running zmblobchk could cause a much greater issue; hence, this post.
Hope that helps,
Mark
P.S. We are using the Zimbra-provided com.zimbra.storemanagers.store.GenericStoreManager Store Manager Class. No idea if this issue applies when using other Store Manager Classes.
Statistics: Posted by L. Mark Stone — Thu May 23, 2024 3:05 pm