Cita:
Originalmente Escrito por mocelet
Bienvenido al foro Dtrote, las preguntas de fiabilidad siempre son interesantes.
La respuesta rápida es que no debería preocuparte, pero el azar podría ser caprichoso, no hay nada 100% seguro.
La forma de detectar corrupción/integridad de datos es hacer un checksum, que es un algoritmo que te asegura devolver el mismo valor para un mismo conjunto de datos y un valor diferente si cambias incluso solo un bit. Te sonará el MD5, los CRC o los ECC (código de corrección de errores).
Aquí hay que prestar atención a todas las capas que hay, principalmente SQLite, la memoria RAM, el sistema de ficheros (YAFFS2, EXT4, etc.) y el propio medio físico (HDD, SDD, flash, etc. y su controlador)
Los medios físicos cuando escriben un bloque de datos escriben también un checksum para que al leerlo sepan que todo es correcto. Incluso en el caso de los códigos ECC pueden ayudar a recuperar la parte dañada. En cualquiera de los casos en el medio físico se marcará esa zona como defectuosa y no se vuelve a usar.
Si se pudieron recuperar los datos te los da, si no dará un error de lectura.
Más arriba tenemos el sistema de ficheros y la memoria RAM, que también puede incorporar o no su propio mecanismo de redundancia para asegurar la integridad de datos. Los equipos profesionales para servidores suelen llevar memorias RAM con ECC, los domésticos no.
Y ya por último tu aplicación, o más concretamente SQLite. En la web de SQLite dicen que está bastante bien protegido contra errores, bien recuperándose automáticamente o bien simplemente detectando la corrupción https://www.sqlite.org/howtocorrupt.html Usan checksums a la hora de escribir para comprobar que se escribió bien o hacer "roll-back", pero no parece que tenga un checksum global o por tabla (sería poco eficiente en cuanto la base de datos fuera grande), así que infalible no es.
Aun así, igual que hay gente que le toca el Euromillones... que un bit cambie en algún sitio y nadie se dé cuenta podría pasar (se llama data rot o bit rot). Improbable, sí.
EDIT: Sí que he tardado en escribir la respuesta jaja, se me adelantó @ Dexafree, ¡menos mal que no hemos contestado lo mismo! |
Gracias por la bienvenida y por dedicar el tiempo en elaborar una respuesta tan extensa. Me has aportado alguna que otra información que no conocía y después tendré que investigar.
En cuanto al checksum, tenía conocimientos de ello, de echo en la laptop, a la información más importante les he comprobado y guardado el md5.
Una alternativa que se me ocurría, para guardar de forma más segura a esto, era crear documentos de texto individuales y guardar el md5 al finalizarlo. El problema es que se haría muy tedioso tener cientos de documentos, y ni que hablar la comprobación de cada uno de ellos.
Así que tener una aplicación, me facilita mucho las cosas. El tema es que todas las notas están dentro de una misma base de datos y bueno ahí me empecé a preguntar la duda que planteo. Además de que todo lo que tenga que ver con la integridad de los datos, siempre me interesó.
Leyendo tu respuesta, me acordé de una prueba que realicé en un disco duro y que si en este tipo de memorias el resultado es el mismo, sería la solución a mi duda y además, podrían sentirse más seguros los que se preguntan lo mismo que yo.
La prueba surgió debido a que por ejemplo, en la laptop tengo un programa que al abrirlo y leer la base de datos realiza la modificación del md5 de la misma y yo me hacía esta misma pregunta.
Porque aunque guardara el md5, con abrir el programa, ya se modificaba y era imposible saber si era por un dato corrupto o era normal, ya que la base de datos era con tolerancia a errores.
Así que lo que hice fue tomar un disco viejo, aislar los sectores dañados en una partición y crear la base de datos. En esa misma base de datos, guardé la información y era como lo esperaba. La base de datos fue guardada como si nada y al abrirla, faltaban algunas notas.
Así que lo que hice fue comprobar el md5 de la base de datos y después volver a comprobarlo, y para mi sorpresa el md5 nunca era igual.
Claro, no era igual porque uno de los clusteres ocupados por la base de datos no era legible y el md5 cambiaba en cada comprobación.
¿Cuál es la conclusión que saqué?
Que no necesariamente se necesita un md5 para comprobar el estado del archivo y averiguar si la base de datos está correcta o está hubicada en sectores defectuosos.
Entonces, teniendo en cuenta la prueba que hice, lo que puedo hacer es, cada cierto tiempo, comprobar el MD5 de la base de datos actual de la aplicación y ver si el mismo no se modifica ante cada comprobación.
¿Esto será igual de efectivo en este caso de memoria flash que en la prueba realizada en el disco duro?