Case #08060616, JetError - 529, JET_errLogDiskFull, Log disk full

[micy]

Hi.
I had issues with a local repository in VB365. I opened a ticket, but I’m not satisfied with the resolution. Below, I’ll describe my experience communicating with support. Has anyone else encountered a similar issue, and how did you resolve it?

============
***Me:
I’ve been using VB365 8.0.3 on a virtual WS2022 for several months. I keep WS up to date.
I back up mail from M365 to a local drive with the ReFS file system. I expand it as needed.
Two days ago, I added two mailboxes to the job and an error occurred:
"JetError - 529, JET_errLogDiskFull, Log disk full".
The relevant repository was full. The added mailboxes were small. The 20 GB increase was more than enough.
I also restarted the server. The job ended with the same error. AI suggested to me that ReFS is not supported in VB365 for local disks
with a JET database. But the VB365 documentation says that ReFS is supported.
I tried to perform a restore from the repository, but nothing loaded. An error was reported stating that the repository was corrupted.
I was already preparing to create new repositories with NTFS and forget about the 120-day-old backups in the corrupted repository.
Then it occurred to me to check Windows Update. Because I had previously had a problem with another Windows server where updates were queued
and waiting to be installed. Here on this server with VB365, updates were also waiting to be installed. So I performed the installation, and then suddenly everything was OK.
The backup was readable, even the most recent one with the added mailboxes, even though the job had previously ended with the error mentioned above.
Subsequently, the job also ran successfully.
What happened? Why did the pending installation of updates cause errors? What do the developers say about this? I would hate for this situation to happen again.
============
***Support:
This might not have been solved by the Windows Update directly,
but by the server restart. After a Jet Error, a restart would
clear out the bad log files which might show the database as damaged/corrupted.
We cannot be sure how the Windows update interacted with the software, but again, most likely, restarting the server (even multiple times), might have cleared the errors.
============
***Me:
I don't like that answer. Are you saying that the VB365 app sometimes needs to be restarted multiple times? Is it that unstable? That's not normal. I sent the logs. What do they show?
============
***Support:
When I mentioned that restarting might solve Jet Errors, I meant only Jet Errors. You do not need to restart the software on a regular basis. The nature of the jet errors, and the way the Jet blue databases work (repository.adb files that we use for the repositories), make it that clearing out their cache (log files) would help address any issues during the logging process.
While not being the case for each Jet error, restarting can sometimes address some of those errors.
============
***Me:
Is the Jet database error unrelated to the Veeam Backup for M365 application? This application uses the Jet DB, which is located on the repository. It’s a database that belongs to VB365. After all, there isn’t a third-party DB engine running that works with the database on the repository. Who is to blame for the Jet DB getting corrupted in some way? It’s VB365’s fault. So either let it handle the error on the fly, or just state clearly that a VB365 restart is required—or, for simplicity’s sake, a full server restart. What am I supposed to do with this error? Try restarting the server several times and check after each restart to see if it helped? Veeam should put that in the documentation. I’m furious.
============
***Support:
I apologize for the inconvenience. A server restart is not the solution for when you encounter Jet errors, but it does help. Usually, if the error persists, we can repair the damage done to the database, if that was the case.
In your situation, all the errors seemed to have been cleared by a server restart, so that is just a coincidence, not the default way of approaching these situations.
Whenever you encounter any errors though, please reach out to us initially, so that we can properly address any errors or damage done to the databases.
============
***Me:
The developers should look into this and find out what happened. I'm not the only one. I've found several similar cases on the internet.
============
No response yet. The case is still open.

[Mildur]

Hi micy,

JET database corruption can have multiple root causes. In most cases, it’s not the application writing to the database that is at fault. A few reasons we’ve seen in other support cases include:
- Faulty hardware
- Not enough free space for database file growth / transaction logs
- Trying to run the backup repository on an SMB share

For investigating JET DB issues, you’ll need to continue with our Customer Support team. If you don’t get answers in a reasonable time, please use the “Talk to a Manager” button to escalate your case to Support Management (see KB2320).
If Windows Updates were really the root case, then it's more likely that something has happened to the jet db components (managed by the operating system, not Veeam products).

AI suggested to me that ReFS is not supported in VB365 for local disks with a JET database. But the VB365 documentation says that ReFS is supported.

Correct: ReFS is supported, but NTFS is recommended. From a product standpoint, there’s no real benefit to using ReFS with Veeam Backup for Microsoft 365.
If you still decide to use ReFS, follow our best practices and disable Integrity Streams on the ReFS volumes.

As a general recommendation for repositories in Veeam Backup for Microsoft 365, we recommend using Object Storage as the repository type. Object storage is typically more reliable and provides better performance than JET DB–based repositories, and it also adds beneficial features such as encryption, immutability, and copy jobs.

Best regards,
Fabian

[micy]

Hello Fabian.
Thank you for your answer.
I think I’ll switch to NTFS, even though I previously configured ReFS according to best practices.
Is there a documented and supported procedure for moving backups to another local drive and continuing to use it for backups?
Thanks. Milan

[Mildur]

Yes, we documented the procedure in KB3067 (Directly Copying Backup Data):

The summarized steps for your use case:
1.) Stop all backup jobs that are using the proxy.
2.) For each backup job using the repository that will be migrated, open backup job settings and specify to temporarily use a different repository (just create a new repo which you will delete afterwards).
3.) Remove all jet db based repositories which will be migrated from the Veeam Backup for Microsoft 365 console.
4.) Stop all Veeam Backup for Microsoft 365 services.
- Veeam Backup for Microsoft 365 Service
- Veeam Backup Proxy for Microsoft 365 Service
5.) Move the repository folder (entire folder structure) to the volume (copy/paste).
6.) Start the Veeam Backup for Microsoft 365 services.
7.) Add the migrated folder as a new backup repositories
8.) Edit backup job from Step 2 and reconfigure them to use the repository added from the new location.

First backup after the migration may take longer. It will be a full scan of your source objects, but still an incremental backup (only new or changed items will be transferred to the backup repository.

Best,
Fabian

[micy]

Thanks.
Milan