So, here's a few additional thoughts:

The fundamental idea is to ensure as much as possible that even if only a fraction of the data gets destroyed, such leftover signal as could still be recovered cannot be interpreted.

So, here's a few additional thoughts:

• Reduce redundancy In normal computing, we use duplicate data, error correcting codes and other similar techniques to ensure that even if some data gets mangled the original can be recovered. Here, that's just giving your adversary a free extra life, so we'll want to turn that off.
• Shuffle. In normal computing, we might localise data on a disk, so that data about the same topic gets grouped together. There are many reasons for this including efficiently accessing it, and giving your programmers a logical framework to reason about. But in this case, because the secret absoltely must not fall into enemy hands, do the opposite. When you write the data to the device, shuffle the bits around: first bit might be near the start, second near the middle, etc. The purpose of this is to ensure that even if your bomb only destroys half the data, the chunk that is left cannot be reasonably interpreted.
• Add interdependence. In normal computing, to interpret one bit, we read one bit. That is useful for your recovery adversary. Modern encryption standards, however, use a technique called block chaining to ensure that previous bits change the encryption of future bits. Perhaps run your basic encryption forward and backwards, so that all data is tangled into interpreting all data. Again, the purpose here is to squib-proof your encoding. Even if the bomb destroys a tiny fraction of the data, the attacker is left having to guess. (There are other more complete ways to add interdependence, but they'd require world-class understanding of coding theory)
• Use a lot of key. We want to make sure that they have to read several bits to correctly interpret one bit. There is a cipher called the "One time pad" which is mathematically unbreakable. That is, even an attacker with unlimited computational power can do no more than guess what the data said. It's also usually useless because you need at least as much key as you have data to encrypt, and if you had a technique to transmit that securely then you could just transmit the secret securely. Here, though, you can just put the key on the disk. The implication is that to understand one bit the attacker must correctly read 2, so if you manage to destroy either of the 2 you're safe. You can and should still use a more conventional encryption thing: the above forward and backwards chaining is strictly better. But the OTP approach inspires...
• Shard the data. This is where the "lots of key" option really comes into its own. Instead of putting the data and key all on one device, you have two physical devices, one has the key and the other has the OTP encrypted data. Mathematically, those are equivalent because it is strictly impossible to interpret either without the other. This gives you the good kind of redundancy: you can have two completely separate self-destruct mechanisms just in case the battery in one of your detonators happened to run down.
• All of the above. In particular: Remove redundancy, then generate a OTP and encrypt the real data with it, then encrypt both the OTP key and the data forwards and backwards with a block-chaining cipher, and then (separately) shuffle the bits of them both, and finally write them to the bomb-laden disks.

• Reduce redundancy In normal computing, we use duplicate data, error correcting codes and other similar techniques to ensure that even if some data gets mangled the original can be recovered. Here, that's just giving your adversary a free extra life, so we'll want to turn that off.
• Shuffle. In normal computing, we might localise data on a disk, so that data about the same topic gets grouped together. There are many reasons for this including efficiently accessing it, and giving your programmers a logical framework to reason about. But in this case, because the secret absoltely must not fall into enemy hands, do the opposite. When you write the data to the device, shuffle the bits around: first bit might be near the start, second near the middle, etc. The purpose of this is to ensure that even if your bomb only destroys half the data, the chunk that is left cannot be reasonably interpreted.
• Add interdependence. In normal computing, to interpret one bit, we read one bit. That is useful for your recovery adversary. Modern encryption standards, however, use a technique called block chaining to ensure that previous bits change the encryption of future bits. Perhaps run your basic encryption forward and backwards, so that all data is tangled into interpreting all data. Again, the purpose here is to squib-proof your encoding. Even if the bomb destroys a tiny fraction of the data, the attacker is left having to guess not just that data but how that data affects the encryption. (There are other more complete ways to add interdependence, but they'd require world-class understanding of coding theory)
• Use a lot of key. We want to make sure that they have to read several bits to correctly interpret one bit. There is a cipher called the "One time pad" which is mathematically unbreakable. That is, even an attacker with unlimited computational power can do no more than guess what the data said. It's also usually useless because you need at least as much key as you have data to encrypt, and if you had a technique to transmit that securely then you could just transmit the secret securely. Here, though, you can just put the key on the disk. The implication is that to understand one bit the attacker must correctly read 2, so if you manage to destroy either of the 2 you're safe. You can and should still use a more conventional encryption thing: the above forward and backwards chaining is strictly better. But the OTP approach inspires...
• Shard the data. This is where the "lots of key" option really comes into its own. Instead of putting the data and key all on one device, you have two physical devices, one has the key and the other has the OTP encrypted data. Mathematically, those are equivalent because it is strictly impossible to interpret either without the other. This gives you the good kind of redundancy: you can have two completely separate self-destruct mechanisms just in case the battery in one of your detonators happened to run down.
• All of the above. In particular: Remove redundancy, then generate a OTP and encrypt the real data with it, then encrypt both the OTP key and the data forwards and backwards with a block-chaining cipher, and then (separately) shuffle the bits of them both, and finally write them to the bomb-laden disks.