You can import with the auto-enter toggle off which will make sure none of your auto-enter fields get updated.
As to your backup strategy: the easiest way to restore is just put back the backup and not then figure out what the differential is between the backup and the live file. That's too labor intensive. But maybe not. In essence every backup strategy is built around these two questions:
- what is your restore point? To what point in time is it ok to restore. In other words: how much data are you willing to lose?
- what is the restore time? How long is it ok to be without the system as the restore operation is going on?
The answers to these questions decide how to set up the backup strategy - and quite frankly: how much money it will cost to make it so. If the client/business ay: we can't lose any data ever and you have to be up and running inside 5 minutes. Then that is an unrealistic expectation (FM does not offer hot-standby for instance so data can always be lost) and it is going to cost a lot of money to come close to this goal.
So going back to your description of trying to find the differential between the data in the backup and the live data: I would step up the backup frequency for the regular schedules and use progressive backups additionally to fit the 'restore point' requirement. That way you don't have to worry about doing imports.
Following on from that, if I am working on an updated version of the database and I wish to make this live, how would I go about importing the data from the older live version? My worry is that if I simply import the tables, modification times, record ids etc may be out of sync. What is a sensible approach? Should I have a restore script?
The problem is that currently all changes have to be done on a live database, which is risky.
This is a different topic than backups. The import process is straightforward but if you want to automate it without writing that automation from scratch, look into something like RefreshFM from Goya.