Is everything on the product backlog a story?

Well, that depends... The reason you have the product backlog is that stakeholders have something to prioritize and so stakeholders get a rough sense when stuff will be available in a release.

The reason you have stories on the product backlog is that the format allows non developers to understand which user needs will be addressed. We specify who, what and why.

So to be able to answer the question if everything is a story, you need to ask yourself if everything you want to build can be expressed in that way. Of course, everything can be expressed in that manor, but sometimes it makes it just harder to read.

For example, the users wanted to switch columns in a grid. Well, of course you could write that as a story but as both developers and user understood "Change column order in usage quantity grid", why applying a format which in that case does not add to the readability.

It is often the same with defects or bugs or what ever you want to call it. I'm later going into the question if you should have bugs on your backlog (well, of course you shouldn't have defects in your system but you shouldn't have eaten that last sandwich either...) but if you do have bugs or defects on your backlog, writing them as stories probably just decreases the readability. The user knows (if they've experienced the problem) know what problem they want to be fixed.

And then there is all the other stuff. Like upgrading the test or development environment. Here I suggest a hybrid: for techie stuff: always include the why. Like for instance upgrading to SQL Server 2008: why should we do that? Otherwise non techies cannot see the benefit and therefor not rank it.