If you've got good coverage, you'll have a great chance that they will. You've got to actively monitor your coverage though.

As far as backups go, a backup is only as good as it's age. If a startup is struggling to decide if they've got the resources for writing tests, they probably don't have the resources for maintaining a real-time database mirror either. You can argue that you should always back up before you roll out a code update, but the real world's not always like that.

If one is using Postgres as the DB it is not really necessary to set up a real-time database mirror to have a very robust error recovery strategy. (I can't speak about MySQL but there is probably a similar feature.)

All you need to do is configure the Point In Time Recovery feature, write a little backup script (mine is 165 lines of Python), and then call it from cron.

With PITR as long as you have the last backup and the archived WAL files made since the last backup you can recover to the SECOND before your program puked all over the DB.