just in case you’re not aware of it: We’re no official SUSE team, but volunteering fellow users. For official support, please contact SUSE, i.e. via SCC, and open a service request.
Is this “SAN” as in block storage (and if so, what file system is it), or actually file storage (i.e. NFS)?
Then the first thing to ask for, before doing anything else with the volume, is a snapshot of its current state. If it’s just some reconnect problem with an NFS server (like mentioned by Malcolm), the snapshot won’t hurt - but if it’s a block device and you run into replays or fsck, you want to make sure you can always revert to the original (though defective) state, in case your actions cause even greater loss of data.
Oh, and since it is important data: You already have made plans for scheduled backups, once you have recovered?
Do you have any indication of steps leading to the corruption? Any error messages on the SAN server side? Any indication of media errors? Further steps depend on what you’re actually facing.
If you’re using a block device: May it be the device was mapped to multiple machines in parallel?
If you see indications of media failure, it’d seem like a good idea to try to copy as much of the block device as available to a new device, ie. via ddrescue, before the affected disks show even more failures.
Once you have means to revert to the current state in case of further trouble, if it’s a block device, and if you can rule out media problems, you may want to try “fsck -n /dev/yourdevice” after umounting the file system ("-n" like in “just check, but change nothing”).
Let’s reassess the situation when you provide more details.