If someone would pay for it I'd write that book. There are lots of different methods for different scenarios. There are some books on it but they're either very dry and technical or have very few examples.

Here's the cliffs notes version for your situation:

1. Build a server. Make an image/snapshot of it.

2. Build a second server from the snapshot.

3. Use rsync to copy files your PHP app writes from one machine ('primary') to another ('secondary').

4. To make a "safe" change, change the secondary server, test it.

5. To "deploy" the change, snapshot the secondary, build a new third server, stop writes on the primary, sync over the files to the third server one last time, point the primary hostname at the third server IP, test this new primary server, destroy the old primary server.

6. If you ever need to "roll back" a change, you can do that while there's still three servers up (blue/green), or deploy a new server with the last working snapshot.

7. Set up PagerDuty to wake you up if the primary dies. When it does, change the hostname of the first box to point to the IP of the second box.

That's just one way that is very simple. It is a redundant active/passive distributed system with redundant storage and immutable blue/green deployments. It can be considered high-availability although that term is somewhat loaded; ideally you'd make as much of the system HA as possible, such as independent network connections to the backbone, independent power drops, UPC, etc (both for bare-metal and VMs).

You can get much more complicated but that's good enough for what they want (redundancy) and it buys you a lot of other benefits.