Wish we had that kind of coin. 
I agree with
@roamer_1 . Before the advent of cloud computing, one common disaster recovery strategy was to have a "warm backup site" or "active/passive" - basically an offline (not taking traffic from users) site whose configuration, software, and databases were periodically or continuously synced with the active site. In the event of a failure, you just point your DNS servers at the passive site and open the hole in the firewall to allow traffic through, and the passive site becomes the new active site.
But it's kind of a pricey option for a small site like this because you double your hosting costs. A less sophisticated option is to make sure to take periodic backups of the site, and move these somewhere else for safekeeping. This means you may lose some data if the hosting provider completely kicks you off or you otherwise lose access. Any posts on the site since your last backup are obviously lost. At the same time, one should have a documented (and ideally scripted) procedure to bring a replacement site online, and that process should be updated and tested everytime there's any significant change to the site (like upgrading the software).
In disaster recovery planning, the time difference between the most recent data in the live site and the most recent data in the backup is called the "Recovery Point Objective" (RPO). The amount of time you take to get your backup site running is called the "Recovery Time Objective" (RTO).
I've worked on a few small web apps over the years, as a way to earn extra money, and on both of those the biggest issue was absolutely zero notes about what had been done and the previous developer was long gone. I tend to take really good notes and document what I do, because I've been burned coming back to my own work after many years and not remembering what I had done. Unfortunately it seems most never learn this lesson.
