Backups are important. You can also run audit logs that run a script when you delete something and stores the deleted record in a deletes table and even have roll backs. Also, setting permissions to least privileges is important too so that people don't delete things they shouldn't. See CNS Audit plugin.
Oh yes, MBS plugin supports audits too. Audits record every change, deletion, etc.
Backups are your number one line of defense. hourly and progressive backups can narrow that window of where data might be entered, then deleted before they can be backed up considerably.
But it's not the only option. You can also set up a system that "marks" records as deleted without actually deleting them. Your system then has to be designed to hide such "deleted" records from the user so that they don't appear in found sets, portals, etc. But with such a change, "undeleting" a record is simply a case of finding that record and editing the field that marked it "deleted" so that it is no longer deleted.
In one of my solutions, employees take down phone messages from customers by entering the info into a FileMaker table. Their Delete button so marks these messages as "deleted" and a scheduled script finds all "deleted" messages more than 60 days old and deletes them each night--so a compromise between "permanent delete" and "Never delete" strategies is also possible..
You can also work with Custom Menus to hide the Delete button from users who do not need it or to force them to use a Delete script that logs the deletion.
I think not.
If your business rules/system requirements dictate that delete can not be permanent then you have to design the system to meet the requirements.
This is true of ANY software system.
How you implement it is up to you and the functionality present in the system.