If our organisation were to switch from a central-server VCS like subversion to a distributed VCS like git, how do I make sure that all my code is safe from hardware failure
I find this question to be a little bit bizarre. Assuming you're using a non-distributed version control system, such as CVS, you will have a repository on the central server and work in progress on developers' servers. How do you back up the repository? How do you back up developers' work in progress? The answer to those questions is exactly what you have to do to handle your question.
Using distributed version control, repositories on developers' servers are just work in progress. Do you want to back it up? Then back it up! It's as simple as that.
We have an automated backup system that grabs any directories off our our machines which we specify, so I add any repositories and working copies on my machine to that last, including both git and CVS repositories.
By the way, if you are using distributed version control in a company releasing a product, then you will have a central repository. It's the one you release from. It might not be on a special server; it might be on some developer's hard drive. But the repository you release from is the central repository. (I suppose if you haven't released, yet, you might not have one, yet.) I kind of feel that all projects have one or more central repositories. (And really if they have more than one, it's two projects and one is a fork.) This goes for open source as well.
Even if you didn't have a central repository, the solution is the same: back up work on developer's machines. You should have been doing that anyway. The fact that the work in progress is in distributed repositories instead of CVS working copies or straight nonversioned directories is immaterial.