You need to be aware of potential mismatches between data stored in the database and data stored in flat files following recovery using stored backups. These mismatches may require addressing with application‑specific code. Generally, if data is essential to the integrity of the information contained in the database, then it should be stored in the database, not in external flat files.
As a general concept, where an application has dependencies on volatile external flat files, you may need to store some sort of history or header information in the database for such files, so that the database can be linked to the state of the flat file; for example:
Has the file been processed yet?
Is the file on disk the same version as the database thinks it is?
Should the file actually be there?
Does the file even exist?
You may need to provide application code that can handle any or all of the above conditions.
If no backup and recovery strategy is in place for files related to this database instance (for example, JADE binaries, third‑party binaries, and miscellaneous files), consider including the backup and restoration of those files appropriately within your chosen database backup and restore processes.
Making your database available again in the most up‑to‑date state as is possible in the timeframe your business can accept is the reason you implement a backup strategy.
The up‑time requirements of your database, how long you are prepared to accept it being unavailable when disaster strikes, and how much updating can be lost are the major factors you must consider when developing your strategy.