Стратегия получить восстановление из поврежденных файлов?
Я и мой коллега пытаемся внедрить механизм восстановления поврежденных файлов на встроенном оборудовании.
Это может произойти при определенных обстоятельствах, например, пользователь снимает батарею во время записи файла.
Орз, но теперь у нас есть только одна идея:
- Создайте дублированные файлы резервных копий и скопируйте их обратно, если ввод-вывод опасных файлов не завершен должным образом.
Это глупо, как будто файлы резервных копий также повреждены, мы просто мертвы.
У вас есть предложения или хорошие статьи по этому поводу?
Заранее спасибо.
2 ответа
Зависит от того, какая ОС и т. Д. И т. Д., Но в большинстве случаев вы можете скопировать во временное имя файла и в качестве последнего завершающего шага переименовать файлы в правильное имя.
Это означает, что окно (WOOPS) Opertunity Of Potential S****p ограничено интервалом, когда происходит переименование.
Если операционная система поддерживает хорошую структуру каталогов, и вы разумно размещаете файлы, вы можете дополнительно уточнить это, скопировав новые файлы во временный каталог и переименовав каталог, чтобы WOOPS стал интервалом между "переименовывать цель для сохранения" и "переименовывать темп" к цели".
Это становится еще лучше, если ОС поддерживает каталоги Soft link, тогда вы можете "ln -s target temp". В большинстве операционных систем замена мягкой ссылки будет "атомарной" операцией, которая будет работать или не работать без каких-либо беспорядочных промежуточных состояний.
Все эти параметры зависят от наличия достаточного пространства для хранения полной старой и новой копии в файловой системе.
Читайте о журнале базы данных и файлах журнала базы данных.
База данных (например, Oracle) имеет очень надежную запись файлов. На самом деле не используйте Oracle. Используйте их шаблон дизайна. Шаблон дизайна выглядит примерно так. Вы можете заимствовать эти идеи, фактически не используя фактический продукт.
Ваша транзакция (т. Е. Вставка) будет получать блок, который будет обновлен. Обычно это находится в кэш-памяти, если нет, он читается с диска в кэш-память.
Копия "до изображения" (или сегмента отката) сделана из блока, который вы собираетесь написать.
Вы изменяете копию кэша, записываете запись в журнал и ставите в очередь запись в БД.
Вы фиксируете изменение, что делает изменение кэша видимым для других транзакций.
В какой-то момент средство записи в БД завершит изменение файла БД.
Журнал представляет собой простой круговой файл очереди - записи - это просто история изменений с небольшой структурой. Он может быть воспроизведен на нескольких устройствах.
Файлы БД являются более сложными структурами. У них есть "номер транзакции" - простой последовательный подсчет общих транзакций. Это кодируется в блоке (двумя разными способами), а также записывается в контрольный файл.
Хороший администратор базы данных гарантирует, что контрольный файл реплицируется на разных устройствах.
Когда Oracle запускается, он проверяет контрольный файл (ы), чтобы найти, какой из них, вероятно, будет правильным. Другие могут быть повреждены. Oracle проверяет файлы DB, чтобы увидеть, какие из них соответствуют контрольному файлу. Он проверяет журнал, чтобы узнать, нужно ли применять транзакции, чтобы получить файлы с правильным номером транзакции.
Конечно, если произойдет сбой во время записи всех копий журнала, эта транзакция будет потеряна - с этим ничего не поделаешь. Однако если произойдет сбой после записи в журнал, он, вероятно, восстановится без проблем.
Если вы потеряете носитель и восстановите резервную копию, есть вероятность, что файл журнала можно будет применить к восстановленному файлу резервной копии и обновить его. В противном случае старые файлы журнала должны быть воспроизведены, чтобы получить его в актуальном состоянии.