Small and easy!

Every piece of data stored in Google is actually split into multiple chunks. Each chunk is encrypted using a different key!

That's a lot of keys? How are they managed? Well, there are Key Management Servers (KMS) that take all those keys and encrypt them to ensure they are safe. Of course, the keys used to encrypt these keys also need to be encrypted. This goes until you get to the Root KMS key. This key exists on only a few machines in the datacenter... and if you can take all of these out (keep in mind, resiliency is built in by design) then nobody can decrypt any keys underneath it! All the data is still there, but meaningless and lost forever. This is similar to @nzaman's thinking, but already done, only requires impacting a few machines rather than every machine.

So it's not the size of the bomb, but the location(s) that makes all the difference.

https://cloud.google.com/security/encryption-at-rest/default-encryption/

Or is it?

Google isn't silly enough to trust all its keys to a single data center. There is always a risk that some massive power outage etc. would compromise the keys (stored in memory only) and losing that data would be disastrous. So there are two fail safes:

The Root KMS Master Key Distributor, essentially a P2P backup with other datacenters:

Root KMS in turn has its own root key, called the root KMS master key, which is also AES256 and is stored in a peer-to-peer infrastructure, the root KMS master key distributor, which replicates these keys globally. The root KMS master key distributor only holds the keys in RAM on the same dedicated machines as Root KMS

And the Safes:

To address the scenario where all instances of the root KMS master key distributor restart simultaneously, the root KMS master key is also backed up on secure hardware devices stored in physical safes in highly secured areas in two physically separated, global Google locations. This backup would be needed only if all distributor instances were to go down at once; for example, in a global restart. Fewer than 20 Google employees are able to access these safes.

Now whether or not these backup strategies exist in your world, or can be avoided through other means (e.g. more than one 'bomb') is entirely up to your world-building.

As others discuss, EMP will damage the machines that access the data, but not the data. You mention that your forces are owners or insiders, who can alter the design to suit, but need to conceal it from line staff who work there. I cannot see a non-detectable way to wipe the software without damaging your hardware. If you use internal malware, and even one backup survives, you are exposed. But to an evil genius, hardware is cheap. Let insurance buy you new hardware and that opens you up to many options. For instnace

Plain old fire

Burn the place to the ground. Simple as that. Build the place out of materials that'll squeak by the fire codes, but then store things in there that will subtly add to and sustain the conflagration. By "subtle" I mean that what fuels office building fires is the office trim and file cabinets full of paper. The trim can be made endothermic, the paper cannot. What's ironic about 9/11 is the jet fuel flashed off quickly, the paper sustained the fire.

Likewise, start the fire with liquid or gaseous fuel and let the paper finish the job. Of course you'd need to either damage the sprinkler system or subvert it to your purposes. Also strive to use more burnable materials where excusable, such as you will want servers with plastic cases, and SSD rather than HDD.

Lastly you'll want what steel mills and refineries actually do need: fire-truck-proof gates. Those industries don't want the F.D. yokels charging in and throwing a water hose on a hot metal bottle or sodium fire. In your case you are worried about terror attacks, or some other thing. And make sure to have onsite security doors which get F.D. Approval, but then frustrate their entry. Just build your building to make it hard to fight fires in, so they switch to 'let it burn out' and containment.

Locating in an unfinished nuclear reactor would be a fun way to do it.

Sound Waves!

Years ago, I was working on some laptop theft prevention software, which in addition to a hardware alarm would activate a laptop's speaker. I had an odd situation on a particular Asus Aspire One laptop where the software would work great while testing, but every time a demo was done, it would BSOD. Naturally, this didn't make my client very happy. I worked on the problem for months trying to figure out what was going on. The problem never occurred on my laptop, only his demo laptop. I ended up buying extra laptops to test. At one point we went to go buy a second of that type of laptop. While looking up the model number, I found an article stating a particular fatal flaw. The speaker was mounted directly on top of the hard drive. At a particular frequency range, the hard drive would basically wreck the data coming out of it, which caused Windows to crash because swapfile was in-use because this laptop also had very little RAM. That particular frequency range happened to be almost exactly what I had chosen for my alarm sound effect. When I would test, the volume was way way down. But, during demos, we would crank it up and almost guarantee a blue screen.

This problem made me start to wonder about other places this could be a problem. Around the same time, some guy posted a video of himself screaming at a hard drive array, causing read latency to increase: https://www.youtube.com/watch?v=tDacjrSCeq4

Since then, I've thought that a particularly crafty malicious hacker could build a device with a bunch of ultrasonic transducers, and hidden somehow in a rack in a cage in a datacenter. With ultrasonic, while you can't hear it, you can create an interference pattern by using two lower frequencies that is in the range of what you need, while retaining the property of having an extremely directional beam. Your device could effectively shoot sonic lasers at particular devices in the datacenter, causing glitches-to-complete-failures in magnetic hard drives, all while not being heard by humans unless they were in the direct path at the time.

Most of the drives for bulk storage are magnetic, with read/write heads barely floating above the drive platters spinning crazy fast underneath. Everything has to be perfectly in balance.

SSDs don't have this trouble, so this method won't apply to them.

It isn't only a question of how big, but a question of where. EMP on the data bus is a different beast from EMP in the power supply, which is a different beast from a simple EMP generator within the room but not connected to anything.

Case 1: EMP in the data buses

The most difficult to create, but also the most devastating. You are supplying a high voltage in the cables through which the data passes. Assuming no intermediate devices burn out, your EMP will make it all the way to the storage drives and work their damage there. No guarantees that nothing can be recovered by forensic examination of the disks, but the disks themselves will be unusable.

Getting a high voltage pulse into those cables is near impossible, unless you have physical access to them, as the cables are shielded against EMP for precisely this reason. If you do have physical access, introducing malware or something similar is a better way to do things. If you're a three-letter agency, for instance, you'll find it more rewarding to spy on people's data, rather than deleting it.

Case 2: EMP in the power supply

By far easier than case 1 and far more likely to happen, given exposed transmission lines. Except that any data centre will have decoupling and power conditioning systems before the power supply gets anywhere near the data, to ensure no unwanted spikes or dips get through. Unless you're actually inside the data centre,or better yet, inside the actual server room, in case they have a final redundant decoupling system, you're not likely to do much damage.

Assuming everything goes your way, and you do successfully set off an EMP after bypassing all the protections, you'll destroy the servers, but probably not most of the data. They will need forensics to recover it, but it can be recovered. The electronics will be slagged, however, so the servers will probably be unusable.

Case 3: EMP inside the server room

Comparatively, the easiest way to cause some damage, but overall likelihood of causing less damage than a successful attempt at Case 1 or 2. Your EMP will weaken with the square of distance, so a million volts or so will be needed to get the whole room, given that the server enclosures will act as Faraday cages and protect their insides. With less voltage, you'll destroy everything nearby, with damage tapering off as you go further from ground zero. This depends on the geometry of the room and the kind of earthing in place. A rectangular room will take less damage than a square room; an L-shape will take less damage, unless the EMP goes off in the crook of the L.

Use paper stickers with housekeeping information to keep track of your disk drives!

How would it help? Well, the stickers can have flat coils inside, just like those stickers that make detectors at shop exits beep at you. The coils can do the EMP and degaussing stuff, while also doubling as an antenna for a small control chip. That tiny low-power chip, and the coil, can be powered from a relatively small capacitor, which can be hidden under the sticker too. (Or inside the case, in case of SSDs, as those rarely have big enough cavities on the outside to hide the capacitor in.) The capacitor is absolutely essential in the case that the disk is completely disconnected for maintenance or other reasons when the kill-switch is triggered. It is recharged when the disk is online.

Sticking that coil right to the disk's circuit board should allow for small enough capacitor to kill whatever chips are on the other side with EMP, or to degauss the platters. For SSDs that extra capacitor can also be connected directly to the board instead, frying all the flash chips as soon as the signal comes. Maybe that small controller could also be connected directly to the motor and the heads of an HDD, making it literally scratch out all the data by slowly spinning the platters under unparked heads.

Add a powerful enough wireless transmitter to cover the whole complex, and a big red button (or a small gray one) for the trigger, and you are set! Keep in mind, though, that if someone tears off a sticker and notices a capacitor that's not connected to anything, they might suspect something and take a closer look at the sticker... With that caveat in mind, I think the idea is quite plausible. Someone might have to figure out exactly how big the capacitor has to actually be, but at least for frying flash in SSDs you most definitely can buy powerful enough yet really small caps.

My original idea follows:

Software could, and would in the context of the story, be found and purged.

What about embedded software? Modern computers are very damn smart. Every sizable component has a CPU, be it a network adapter or a microSD card.

Intel AMT allows you to connect to a server remotely and work on it like it's in front of you: a display, a keyboard, you can even "plug in" your hard disk into it over the network. And the best part is, all this works as soon as you press the power button (some of it even before that), and it is completely out-of-band. That last bit means that any software working on this server will never see any AMT traffic, and it will think that you've actually opened up the case and attached that HDD.

Despite having all that functionality, AMT works almost entirely on the motherboard itself, doesn't touch the main CPU or RAM, and is almost invisible to the "main" system. It's code is very obscure, extremely platform-specific and proprietary. Only some very smart hackers managed to get into it (and find a few glaring security holes...), under the normal circumstances no one will ever touch it in any way other than through the official client software from Intel.

Every HDD and SSD has an embedded controller, too. Wiping an SSD "from the inside" is as simple as "forgetting" where the index for all of its flash memory is, maybe wiping that relatively small index beforehand for good measure. And on HDD you can just slow down the platters enough for the heads to land on them and dig trenches all over the surface. (The heads are too weak to magnetically damage the data quickly enough, so physically damaging the surface is the only way.)

All the network hardware also has embedded processors, even the "really" embedded ones in case of bigger devices that are like normal computers themselves on the inside.

What I'm getting at is, most people don't even realize that their microSD card may well be more computationally powerful than a PC from late 90s! No one ever really looks inside those embedded chips. Oftentimes you cannot even read the firmware from them, only flash the updates. (And thus their security is severely lacking oftentimes, except the "Security through Obscurity" kind.)

If some kind of backdoor is installed on that level, I doubt that anyone will ever notice it. At least not until it's exploited and forensics start digging into the chips. No "normal" software will be able to detect that something's wrong, you'd have to take the device apart and dig in with a JTAG debugger to even have a chance.

Let's say that one of the routers in the datacenter receives a malformed packet. It looks like it's a normal packet that got (unnaturally severely) corrupted in transit. Normally, it would be silently dropped, and higher level protocol, like TCP, will request retransmission. Suddenly, the router broadcasts that same packet over all its connections, and then immediately "dies", maybe requiring a firmware recovery procedure to continue functioning. Every server that receives the packet suddenly crashes due to CPU voltage dropping below acceptable minimum, and its disks experience catastrophic firmware failure that destroys all the data in a matter of seconds. A few more seconds later, the "smart" power supply infrastructure, which also received the packet of death, cuts the power to the whole complex. And perimeter routers just receive and drop the packet as they should, not a single bit of suspicious data gets outside.

In just 10 seconds or so, the datacenter inexplicably goes from perfectly fine and healthy to totally blacked out and dead. All the networking infrastructure is lacking any firmware to even work. All the data is lost, either in unintelligible fragments randomly scattered across several flash chips in each SSD, or literally scattered all over the insides of HDDs.

No one has any clue as to what has happened. Even if someone figures out later that the firmware of almost everything in the complex had peculiar bugs that just so happened to act together in such devastating manner, it can still look like it all was an accident. Since there are no traces of the packet that caused the whole mess, the only way someone might figure out that it was malicious is by contacting HDD vendors and finding out that the firmware slightly differs from what should have been there, but even that would be practically impossible to say for sure, due to how much things change internally during product life cycle.

And in that last bit lies the catch. That 'small team' of yours will have to reverse engineer the firmware of every HDD, SSD, motherboard, network card and router in the datacenter, plus the smart power supply system. There likely will only be just a few kinds of each component, since they are ordered in bulk, and the slight variations in hardware revisions should not be much of a problem, but that's still a huge load of work, and it will take time.

Plus, if any machine just so happens to be offline, as in "completely disconnected", its data will survive. The same goes for any disks that happen to be taken out at the moment. The only "safe" solution to that would be to have a small autonomously powered wireless bug on every HDD that will, when triggered remotely, turn on the disk, if it was offline, and order it to go kill itself. Or make it discharge a capacitor into a small flat coil glued to the disk. (Like those stickers that make detectors at shop exits beep at you. It can even have some housekeeping information printed on it, so that there is a reason for it to be there. No one needs to know that there is a coil inside the sticker. The capacitor will still be noticeable, though, unless you hide it under that sticker.)

Or, you know, you could just kill it with fire. But that is outside of my area of expertise.