When usually the SAN storage LUN GPT table will get corrupted?

[Mallik7]

In the recent past, we noticed that in our environment that, few of the LUNs GPT table got corrupted, however the backup GPT is good.

Due to this, the backup jobs are getting failed as the transport mode is configured / selected using SAN.

We use SAN storage in our environment.

Can some one help me to understand better in which case scenario the primary GPT will get corrupted on the LUNs?

TIA

[a_p_]

Are the datastore LUNs presented to only ESXi hosts, or also to e.g. Windows hosts for backups?

In case they are presented to Windows, please ensure that automount is disabled, or the SAN policy is set to "Offline Shared" (depending on the Windows version) to prevent Windows from initializing to disk! This needs to be done before presenting the LUN to the server (or attaching the server to the SAN)!

Also be careful with Windows Servers that have Hyper-V enabled. I can't find this right now, but some time ago I read a blog post, which stated that Hyper-V always uses the SAN policy "Online", regardless of the configured value. I didn't verify this yet, so I can't tell you for sure whether this is the case with current WIndows versions.

André

PS: Please see your backup software vendor's documentation for recommendations about direct SAN backup configurations, and best practices.

[Mallik7]

the LUNs are presented to both ESXi hosts and Backup appliance.

we found that, most of the LUNs GPT table got corrupted. Not sure, what is the exact reason and we don't know when they were exactly corrupted !!

in which case, the primary GPT table will get corrupted ?

[a_p_]

... and Backup appliance

What type (vendor/model/version) of backup appliance is this?

Do the LUNs need to be presented to this appliance in R/W mode, or is it possible to present the LUNs in read-only mode?

André