fdisk -l does not show the disk. Same for df. lsusb sees it though.

How can I try and find out more about the cause?

This implies the immediate cause was corruption which affected the partition table; that "Apache was still running but replied with errors" fits with this, since the information in the partition table is only needed when mounting a partition. You can delete the entire table and the system should be mostly fine until a reboot.

As to what would have caused the corruption, power could be an issue. If you recover the filesystems, try sudo grep "Under-voltage" /var/log/syslog and see if that clue is there.

Of course if the partition table was corrupted, likely other data was as well. I've never run a Pi directly from a USB device,¹ but I assume it is DOS MBR formatted like the primary SD card would be, and not GPT (which there is not much purpose to that in this context). The MBR, which contains the partition table, is only a 512 byte block.

The thing to do in that case is to recreate the partition table with fdisk. This is one of two fundamental steps in formatting a block storage device, the other being creating the filesystems. The latter is what effectively "wipes" the storage, because it replaces the information needed to find specific pieces of data -- although the data will still be there, sorting it out may be difficult or impossible and is not a worthwhile pursuit in this context.

That means if you rewrite the partition table exactly as it was before, you will be able to access whatever is left of the filesystems. Which could be quite a bit, since the only thing you know for sure is damaged (this all assumes the problem is not a physical defect or damage to the stick) is the 512 byte partition table.

The easiest way to do this is to simple keep a copy of the MBR. From a running Pi, and referring to the SD card:

dd if=/dev/mmcblk0 of=mbr.copy bs=512 count=1 

You would use /dev/sda or whatever it is (note, not sda[N], where N is a number; that refers to partitions and not the block device itself. This leaves you with a 512 byte file you can stash somewhere(s) easily.

To replace it:

dd if=mbr.copy of=/dev/sda

Here I'm using sda to make it clear this probably isn't in a running system since at that point the storage has been borked. It is possible though, eg., if you had been able to log in in the "apache was still running scenario".

You could also do this from saved fdisk -l output but that is a bit tedious. Since you don't have either here, you could consult the original image used to create the card (you can run fdisk -l on a pi image file). Most likely, that's never been changed except to expand the root fs. If what you did was just fill the device, this is pretty simple. If you arbitrary divided into multiple partition, though, this may be tricky or impossible.

---

1. You might want to reconsider that strategy unless you have a good reason for doing so (an by that I do not mean, "it's got a faster read/write time", but that you actually need such in order to accomplish some goal). Obviously enough, it is not a safeguard against block storage corruption.