File hacked recovery strategy?
My colleague and I are trying to implement a broken file recovery mechanism on embedded hardware.
This can happen under certain circumstances, for example. the user removes the battery while writing the file.
Orz, but now we only have one idea:
- Create duplicate backup files and copy them if the dangerous I / O file won't execute correctly.
It's silly, as if the backup files are broken as well, we're just dead.
Do you have any suggestions or good articles?
Thanks in advance.
a source to share
Depends on what OS, etc., but in most cases what you can do is copy to a temporary filename, and as a final last step, rename the files to the correct name.
This means that the window (WOOPS) for operating the potential S **** p is limited to the interval when renaming occurs.
If the OS maintains a good directory structure and you decompose the files wisely, you can further refine this by copying the new files into the temp directory and renaming the directory so that WOOPS is between "rename target to save" and "rename temp to target".
It gets even better if the OS supports Soft directory links then you can "ln -s target temp". Most operating systems replacing the softlink will have an "atomic" operation that will or may not work without any messy state halfway through.
All of these options are dependent on having enough storage to store the full old and new copies on the file system.
a source to share
Read the database logging and database log files.
A database (like Oracle) has very reliable file writing. Don't actually use Oracle. Use their design template. The design model looks something like this. You can take these ideas without actually using the actual product.
-
Your transaction (i.e. insert) will fetch the block to update. Usually it is in memory cache, if not, it is read from disk to cache memory.
-
The "before picture" copy (or rollback) is made from the block you are about to write.
-
You modify the cache copy, write the entry to the log, and queue the entry in DB format.
-
You commit a change that makes the cache change visible to other transactions.
-
At some point, the DB creator will finish modifying the DB file.
The log is a simple round robin file - the entries are just a history of changes with little structure for them. It can be replicated across multiple devices.
DB files are more complex structures. They have a "transaction number" - a simple sequential count of total transactions. This is coded in the block (two different ways) and also written to the control file.
A good DBA ensures that the control file is replicated across devices.
When Oracle starts up, it checks the control file to find which one is likely to be correct. Others may be damaged. Oracle checks the database files to see which matches the control file. It checks the log to check if transactions need to be applied to get the files up to the correct transaction number.
Of course, if it fires while writing all copies of the log, that transaction will be lost - there is little that can be done about that. However, if it crashes after writing the log entry, it will probably recover without issue.
If you lose media and restore the backup, there is a chance that the log file can be applied to the restored backup file and updated. Otherwise, the old log files must be replayed to update it.
a source to share