Common problem, but IMHO the wrong direction to try to head. You could do some of this (eg follow the directions in perlsub to override open, close, override your key database functions, etc). However I think it would be a bad idea.

Far saner would be to try to move things towards two basic design ideas.

The first is transactions. Create a temporary space. Try to do work. If work succeeds then commit the transaction (ie copy from working to live), if it fails rollback (ie drop the temporary space), with appropriate locking if need be. Databases make this easy. You can do it, less reliably and with more work, with filesystems. It will help you avoid disentangling messes.

The second is keeping track of state somewhere. Have a simple table that registers a ton of jobs and their state. Every major step, mark the work as needing to be done, try to do it (with usual error handling, dying if something goes wrong, etc), and then if it succeeds mark it as having been done and mark the next thing as needing to happen.

That strategy results in code that (in my experience) will recover cleanly from most unexpected problems. Combine the two, and if a step has a problem you get notification, further damage is not done, and you are then left knowing which step went wrong and with the ability to investigate that one at your leisure. And then you can leave completing it for the next night when the process runs again.

Trust me on this. While a band-aid may be doable and may assist with your immediate situation, even incremental steps towards a saner architecture (like above) will make your life much better.

And, of course, try to create testing environments, use revision control, all of the usual good stuff...