Consulta sobre base de datos de aplicaciones

[Dtrote]

Hola amigos, soy nuevo por aquí!!!

Quisiera saber una opinión en base a su experiencia o conocimientos en la materia.

Resulta que descargue una aplicación en mi smartphone con Android y pensaba guardar bastantes notas y datos que tengo.

Mi duda es la siguiente:

Suponiendo que se daña 1 sector y el mismo estaba ocupado por un byte de la base de datos que contiene todas las notas e información.

Al iniciar la aplicación, ¿Iniciaría la base de datos con información corrupta o se volvería a crear desde cero?

Mi duda es debido a que son bastantes notas y si se llegase a encontrar algún sector dañado, me gustaría percatarme de ello para restaurar el backup.
Porque si quedase corrupta cierta información, ante tantas notas, sería imposible darse cuenta.

Gracias de antemano .

[Dexafree]

Buenas!

Primero de todo, veo que te acabas de registrar, así que bienvenido al foro!

Te recomiendo que te pases por la sección de presentaciones para que podamos conocerte un poquito mejor

Después, sobre la duda que comentas, te comento varias cosas:

1. Si te preocupa tanto la integridad y las copias de seguridad de tus notas, por qué no te planteas utilizar alguna solución que incluya backup en la nube?
Si vas a ser un usuario tan intensivo como parece, puede que te interese Evernote (su plan gratuito está medianamente bien): https://evernote.com/intl/es

Si las notas solo van a contener texto e imágenes, quizás con Google Keep ya te apañas:
https://keep.google.com

Si eres más manitas y te interesa tener una solución que no esté en la "nube de otro", siempre puedes montarte un Paperwork en un servidor que tu administres:
https://github.com/twostairs/paperwork

2. Si no la has desarrollado tu, pero estás decidido a utilizar esa aplicación, puedes intentar ponerte en contacto con el desarrollador para que integre la opción de backups
3. A las malas, siempre podrías utilizar programas de backup de datos de aplicaciones, como Titanium Backup, aunque suelen requerir de acceso root.
4. Finalmente respondiendo a tu pregunta, si se dañara un sector de la memoria (cosa no muy habitual), probablemente la aplicación arrancaría con la base de datos corrupta, aunque eso es bastante impredecible (si se daña el sector que tiene el inicio del fichero, la historia podría ser distinta, por ejemplo)

[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!

[Dtrote]

 Cita: Originalmente Escrito por Dexafree

Buenas!

Primero de todo, veo que te acabas de registrar, así que bienvenido al foro!

Te recomiendo que te pases por la sección de presentaciones para que podamos conocerte un poquito mejor

Después, sobre la duda que comentas, te comento varias cosas:

1. Si te preocupa tanto la integridad y las copias de seguridad de tus notas, por qué no te planteas utilizar alguna solución que incluya backup en la nube?
Si vas a ser un usuario tan intensivo como parece, puede que te interese Evernote (su plan gratuito está medianamente bien): https://evernote.com/intl/es

Si las notas solo van a contener texto e imágenes, quizás con Google Keep ya te apañas:
https://keep.google.com

Si eres más manitas y te interesa tener una solución que no esté en la "nube de otro", siempre puedes montarte un Paperwork en un servidor que tu administres:
https://github.com/twostairs/paperwork

2. Si no la has desarrollado tu, pero estás decidido a utilizar esa aplicación, puedes intentar ponerte en contacto con el desarrollador para que integre la opción de backups
3. A las malas, siempre podrías utilizar programas de backup de datos de aplicaciones, como Titanium Backup, aunque suelen requerir de acceso root.
4. Finalmente respondiendo a tu pregunta, si se dañara un sector de la memoria (cosa no muy habitual), probablemente la aplicación arrancaría con la base de datos corrupta, aunque eso es bastante impredecible (si se daña el sector que tiene el inicio del fichero, la historia podría ser distinta, por ejemplo)

Gracias por el tiempo que te has tomado en elaborar una respuesta tan extensa y, además por la bienvenida.
Sí, soy nuevo por acá, ya me voy a pasar a presentar...

Respondo por partes:

1 - La idea es no utilizar ninguna aplicación que guarde en la nube. Salvo que sea una aplicación que guarda la base de datos de forma cifrada, cosa que aún no encontré. Y si la encontrase, he probado varias y me he topado con una que satisface mis necesidades, almacena tareas, notas y agenda. Pero, no tiene para sincronizar la base de datos en la nube y además, no cifra todos los datos.

Con respecto a Paperwork, nunca lo había escuchado, ya me voy a poner a investigarlo un poco más, mientras tanto, voy a utilizar la aplicación que tengo.

2 - La aplicación que encontré, tiene para realizar backups, pero de forma local. No me preocuparía porque puedo automatizar con algún programa los backup periódicos hacia la MicroSD por ejemplo.

3 - Es una buena opción, pero, no es lo que busco.

4 - ¿Cuando dices "arrancaría con la base de datos corrupta" te refieres a la falta de algunas notas o a la base de datos inaccesible totalmente?

Porque lo que más me preocupa es que la base de datos se dañe en una parte y yo no me percate de ello a tiempo, como para restaurar el backup.

[Dtrote]

 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?

[mocelet]

 Cita: Originalmente Escrito por Dtrote

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.

Bueno, esto es otro caso radicalmente distinto al que exponías: que la escritura falle. Lo que es altamente improbable es que algo que está almacenado se lea mal y no te enteres.

Que algo se escriba mal o no se escriba (normalmente es que no se escribe), aunque bastante improbable puede pasar, más que nada porque hay varias cachés y buffers por medio, la escritura física solo se hace de vez en cuando. Si se va la luz, se reinicia el dispositivo o hay algún fallo gordo no llegará a escribirse lo último (y aun así, los dispositivos incorporan mecanismos para evitar en lo posible la pérdida de datos, y los sistemas de ficheros pueden llevar "journaling" que es un registro de eventos y su misión es detectar estos problemas).

[Dtrote]

 Cita: Originalmente Escrito por mocelet

Bueno, esto es otro caso radicalmente distinto al que exponías: que la escritura falle. Lo que es altamente improbable es que algo que está almacenado se lea mal y no te enteres.

Yo explicaba sobre la prueba que hice en su momento, pero, ahora que dices de la escritura, no sé si se me habrá saltado o lo tuve en cuenta (por ahí debo tener los resultados anotados).

La cuestión es que lo planteaba, más que nada porque me llamaba la atención la variación del md5 ante cada comprobación. Y ahora que dices que "es altamente improbable que algo se lea mal y no me entere " eso me confirma que si yo pruebo generar el md5 más de una vez y no cambia, ¿Me puedo fiar que dicha base de datos no debería estar ocupando ningún sector defectuoso y por ende, no faltaría ninguna nota?

No se si me entiendes a lo que voy...

[mocelet]

Si el MD5 te da el mismo resultado es que los datos son los mismos.

Los sectores defectuosos de todas formas los debería detectar el dispositivo de almacenamiento, que para algo llevan CRCs y tienen mecanismos de autocomprobación (SMART y compañía).

Y en los móviles, que suelen llevar memoria interna flash NAND, es que es el pan de cada día que haya áreas de la memoria defectuosas y los dispositivos están preparados para eso, cuando escriben los datos escriben con redundancia, si se estropea una zona se marca como deshabilitada, se recuperan los datos y se copian a otro sitio.

Y si hay un error de lectura insalvable por causas de fuerza mayor estoy convencido de que en la app saltará un error antes de arrancarse con información corrupta.

[Dtrote]

 Cita: Originalmente Escrito por mocelet

Si el MD5 te da el mismo resultado es que los datos son los mismos.

A eso mismo me refiero, pero según las pruebas que hice (en disco duro) más allá de que los datos sean los mismos, cuando la base de datos está ocupando un sector dañado, el md5 parece ser que cambia ante cada comprobación. ¿Y es muy lógico no? El sector dañado no puede ser completamente leído.
Ahora con las memorias NAND flash, no se si será lo mismo.

 Cita: Originalmente Escrito por mocelet

Y si hay un error de lectura insalvable por causas de fuerza mayor estoy convencido de que en la app saltará un error antes de arrancarse con información corrupta.

Mmm me cuesta fiarme, salvo que tenga pruebas que me lo demuestren (en esto de la tecnología, todo es posible).
Más que nada me cuesta confiar, por la cantidad de información que le quiero grabar.

No quiero ser tan complicado. Voy a ver si un amigo tiene un pendrive que yo había comprobado que tenía sectores aleatorios defectuosos y voy a hacer esta prueba del md5.

Supongo que debería obtener los mismos resultados que obtuve con el disco duro. Pero, por si a caso...