The entire point is that crash recovery fails because you rarely test it. By making it the one and only code path, by definition, you will be testing it all the time, so it is much more likely to work in the first place.

(The obvious counterargument being that if there are different ways in which the software can crash, this is still not an adequate defense.)

I always tell clients that backups are boring but restores are very exciting.

If you make restores boring, then you're closer to resilience.

If you have a backup procedure for mass storage, practice restoring that data.

Crashing more often would test that better.