Like @HaukeLaging said,
dmsetup table --showkeys might show the master key of a still open LUKS container (might not work for LUKS2 containers, see also 6.10 How do I recover the master key from a mapped LUKS1 container?).
You could copy like the first 128M of the device then experiment with it at home.
ssh root@server head -c 128M /dev/sdxy > sdxy.img
hexedit master.key # hexedit or xxd -r -p to produce binary file
hexdump -C master.key # to verify correctness
cryptsetup luksAddKey --master-key-file master.key sdxy.img
cryptsetup luksOpen sdxy.img luksxy
file -sL /dev/mapper/luksxy
If you get random data instead of a known filesystem or LVM header, it was the wrong key or there is some other problem with the LUKS header.
You can run the same experiment on the server directly, but there may be possible side effects with another device / duplicate UUIDs appearing etc. so it's better to do it on a separate machine or inside VM.
If the LUKS header is damaged so luksAddKey doesn't work, you can also luksFormat a new one. However in that case in addition to the master key, you also must specify the correct cipher and data offsets.
However, if you have any doubts regarding this LUKS container, you should backup all your files while the machine is still running. Storing the master key all over the place also circumvents the LUKS security concept, so it's best to make a new LUKS container with new master key from scratch.