Recupere el libro GnuCash antes de reproducir cualquier cosa
Para recuperar libros de GnuCash, primero identifique el libro real, su backend de almacenamiento y el tipo de información que falta. Una copia de seguridad de un libro fechado puede preservar un estado anterior completo. Un registro de transacciones tiene un propósito más limitado. Un archivo de bloqueo no contiene los datos de la cuenta. Por lo tanto, mantenga estos candidatos separados en lugar de intentar abrir cada archivo con nombres similares como un libro de reemplazo.
Registre una cuenta distintiva, una transacción que sepa que desapareció y el último guardado confiable. También tenga en cuenta si el libro utiliza almacenamiento de archivos XML o un servidor SQL. Esta distinción cambia el método de recuperación. Un procedimiento de reproducción de registros para un libro XML no debería convertirse en una instrucción de reparación general para cada base de datos de GnuCash.
Preservar el libro y los archivos circundantes
Cierre GnuCash y copie el directorio de libros superviviente antes de probar a los candidatos. Incluya copias de seguridad y registros fechados, manteniendo sus nombres de archivos originales. Conserve todos los archivos adjuntos legítimos o documentos fuente separados que necesite para la verificación. Luego trabaje en una segunda copia. Esto evita que un guardado o reproducción exploratoria reemplace la única fuente que todavía representa el estado anterior al incidente.
Si el libro permanece abierto con información útil, guarde una copia de recuperación nativa por separado a través de la interfaz compatible. Mantenga también un informe de referencia cuando sea práctico. El informe puede ayudar a comparar saldos y transacciones, pero no reemplaza el libro editable. Etiquete la fecha y el alcance del informe para saber qué estado describe realmente.
Ruta nativa 1: abrir una copia de seguridad de un libro con fecha existente
- Busque una copia de seguridad fechada asociada con el libro deseado.
- Cópielo a un directorio de recuperación separado sin cambiar el original.
- Abra la copia de seguridad copiada en una instalación de GnuCash compatible.
- Guarde el candidato aceptado con un nombre de archivo de trabajo diferente.
Para flujos de trabajo basados en archivos compatibles, GnuCash puede conservar copias de seguridad completas de libros fechadas cuando las guarda. Inspeccione los archivos reales y sus marcas de tiempo en lugar de asumir que existe una copia de seguridad. Una copia de seguridad preserva al estado de su propio hito, lo que puede omitir trabajos posteriores. Compare la transacción faltante distintiva antes de decidir si el candidato cumple con su objetivo de recuperación.
Compare más que el saldo inicial
Inspeccione varias cuentas relevantes y una transacción anterior y posterior al incidente. Compare también la moneda esperada y el contexto de fecha. Un libro puede abrirse correctamente mientras representa otro hogar, otro año o una revisión anterior. Los nombres de cuentas familiares por sí solos son una prueba débil cuando has copiado un libro varias veces durante la resolución de problemas anterior.
Mantenga el libro actual por separado hasta que se complete la comparación. Una copia de seguridad anterior puede recuperar una transacción eliminada y perder entradas posteriores válidas. Decida cómo preservar esas diferencias deliberadamente en un candidato en activo. No sobrescriba el libro actual simplemente porque la copia de seguridad muestra un total más tranquilizador a primera vista.
Ruta nativa 2: inspeccionar un registro de transacciones XML coincidente
- Conserve el último libro XML guardado y sus archivos de registro asociados.
- Confirme que el registro de candidatos pertenece exactamente a ese libro y sesión.
- En un libro copiado, utilice la importación de archivos .log de Replay GnuCash compatible solo para transacciones simples adecuadas.
- Compare las transacciones restauradas y los informes relacionados antes de aceptar el resultado.
Un registro de transacciones no es una copia de seguridad completa del libro. Registra ciertos cambios de una sesión y necesita una base guardada adecuada. Esta ruta no se aplica indiscriminadamente al almacenamiento SQL ni a todas las operaciones comerciales. Si el trabajo faltante involucra facturas, pagos u otras estructuras comerciales, evite tratar la reproducción de registros como un método confiable de restauración completa.
Haga coincidir el tronco con su base
Compare el nombre del libro original y la cronología de la sesión antes de elegir un registro. Un registro asociado con una copia de seguridad o un libro de prueba diferente puede describir otra secuencia de cambios. Consérvelo como evidencia, pero no lo reproduzca en una base no relacionada solo porque su marca de tiempo es reciente. La relación entre el libro guardado y el registro es más importante que la simple similitud del nombre del archivo.
Inspeccione el resultado transacción por transacción alrededor del período recuperado. Un equilibrio plausible no establece que todas las relaciones o registros sean correctos. Si la repetición produce duplicados inciertos o entradas inesperadas, mantenga separados el original y el candidato de prueba. Regrese a una copia de seguridad completa y coherente o reconstruya las entradas faltantes verificadas a partir de registros autorizados en lugar de acumular repeticiones más inciertas.
Ruta nativa 3: reabrir el libro existente correcto
- Consulte la ruta completa del libro actualmente abierto en GnuCash.
- Compare las entradas de archivos recientes con el nombre de archivo activo previsto.
- Abra un candidato copiado desde la ubicación correcta del proyecto.
- Confirme una transacción reciente distintiva y la estructura de cuenta esperada.
Se puede producir una pérdida aparente al abrir una copia de seguridad anterior y luego continuar trabajando allí. La barra de título y la ruta completa pueden exponer esa situación. Busque el libro activo real y copias divergentes útiles antes de declarar eliminados los últimos datos. Un nombre de archivo más largo que contenga varias marcas de tiempo puede ser una pista de que el trabajo continuó en una copia de seguridad.
Mantenga distintos los libros divergentes
Si dos libros contienen diferentes cambios útiles, consérvelos con etiquetas de origen claras. Compare sus transacciones reales y su cronología antes de decidirse por un enfoque de recuperación. No los combine copiando fragmentos de bases de datos internas o importando todas las exportaciones disponibles a la vez. Eso puede crear duplicados y al mismo tiempo ocultar qué fuente proporcionó un registro en particular.
Para obtener una pequeña diferencia, reconstruya solo la información faltante verificada en un libro aceptado por separado utilizando el flujo de trabajo normal de la aplicación. Mantenga la evidencia fuente y un breve registro de los cambios. Se trata de una reconstrucción controlada, no de una recuperación histórica automática. La distinción le ayuda a evaluar la incertidumbre restante y explicar el resultado más adelante.
Ruta nativa 4: restaurar una copia de seguridad completa apropiada para el backend
- Identifique si el libro utiliza XML, SQLite u otro motor SQL compatible.
- Localice una copia de seguridad existente coherente y adecuada para ese tipo de almacenamiento.
- Restaure un candidato copiado a través del flujo de trabajo compatible correspondiente.
- Ábralo en GnuCash y compare los registros específicos del incidente.
Los libros respaldados por SQL necesitan una estrategia de respaldo adecuada a su backend. No asuma que los archivos .log cercanos proporcionan un mecanismo de reversión general compatible. Para una base de datos de servidor, conserve la copia de seguridad legítima de la base de datos y utilice su procedimiento de restauración documentado. Para un archivo de base de datos local, conserve una copia cerrada coherente en lugar de mezclar archivos de sesiones no relacionadas.
Preservar el estado original del backend
Una conversión a otro formato de almacenamiento cambia el artefacto de trabajo. Si la conversión es necesaria para una investigación de recuperación legítima, realícela en una copia y documentela. Mantenga la fuente intacta. Un libro convertido exitosamente aún puede omitir información o representar un hito anterior, así que compare el contenido después de la conversión en lugar de juzgar el éxito por la existencia del nuevo archivo.
Inspeccione también la compatibilidad de la versión de la aplicación utilizada para la prueba. Una actualización puede cambiar la forma en que se almacena o lee un libro. Conserve el candidato anterior antes de cualquier conversión o migración. Esto evita que la compatibilidad de la versión se confunda con la pérdida de datos originales y le brinda un punto de comparación claro si aparece un nuevo problema.
Distinguir archivos bloqueados de datos de libros
Una advertencia de bloqueo sobrante después de un bloqueo no establece que falta el libro. GnuCash utiliza archivos relacionados con bloqueos para coordinar el acceso; esos archivos no son copias completas de sus cuentas. Confirme que no haya otra sesión legítima que siga usando el libro antes de realizar cualquier acción relacionada con el bloqueo. Conserve primero el candidato de datos real.
Investigar la advertencia en contexto
Registre el mensaje exacto y la ruta del libro. Una segunda instancia en ejecución, otro usuario o un bloqueo obsoleto pueden producir diferentes situaciones de acceso. Siga las instrucciones admitidas de la aplicación para la condición específica. No elimine archivos arbitrarios con una extensión familiar mientras aún no esté seguro de qué archivo contiene el libro en vivo.
Si el libro se abre después de resolver un problema de acceso, inspeccione la transacción de destino y guarde una copia aceptada por separado. La restauración del acceso y la restauración de datos son resultados diferentes. Una apertura exitosa puede revelar que no se perdió ninguna transacción o puede revelar un período faltante genuino que aún requiere una comparación de respaldo.
Utilice informes como prueba de verificación
Elija informes que correspondan a los registros afectados por el incidente. Compare fechas, selección de cuentas y filtrado antes de interpretar una diferencia. Un informe con otro período puede parecer inconsistente incluso cuando las transacciones subyacentes sobreviven. Mantenga la configuración del informe con sus notas comparativas para que el resultado siga siendo repetible.
Verifique transacciones individuales detrás de un total
Un total coincidente puede ocultar una entrada omitida compensada por otro error. Inspeccione algunas transacciones distintivas, sus fechas, montos, cuentas y descripciones comparándolas con evidencia independiente. Esta es una verificación de la integridad de los datos, no una recomendación para cambiar el tratamiento financiero. La recuperación debería reproducir registros verificados en lugar de inventar ajustes para forzar un equilibrio que coincida.
Si reconstruye una transacción faltante a partir de un registro autorizado, etiquételo en las notas de recuperación. Conservar la evidencia original y el libro previo a la reconstrucción. Un resultado de trabajo útil aún puede diferir del archivo histórico exacto, especialmente cuando el texto de la nota, los archivos adjuntos u otro contexto no sobrevivieron.
Trate los registros comerciales como algo más que cambios de saldo
Las funciones comerciales pueden mantener relaciones más allá de los montos visibles de las transacciones. Una repetición o reconstrucción parcial que restablezca el equilibrio puede dejar esas relaciones incompletas. Prefiera una copia de seguridad completa y coherente del libro para estos casos e inspeccione las estructuras de aplicación relevantes. No trate un simple mensaje de éxito del registro de transacciones como prueba de que las facturas y los pagos se devolvieron correctamente.
Comparar relaciones explícitamente
Cuando sea relevante, inspeccione la factura real o el registro de factura, su transacción asociada y el estado esperado de la solicitud. Preserve a los candidatos inciertos y obtenga ayuda adecuada para cada solicitud antes de aceptar una recuperación parcial complicada. Una afirmación de restauración confiable necesita evidencia sobre las relaciones de las que depende la tarea, no simplemente una figura familiar en un registro de cuentas.
Si no sobrevive una fuente completa, documente la brecha restante y reconstruya solo lo que los registros independientes respaldan a través del flujo de trabajo normal de la aplicación. Mantenga la información reconstruida distinta de la información restaurada directamente. Esto hace posible una revisión posterior y evita presentar un estado empresarial inferido como si proviniera intacto de una copia de seguridad.
Cómo solucionar un bloqueo durante la entrada simple
Supongamos que se produce un bloqueo después de varias transacciones normales pero antes del siguiente guardado de un libro XML. Conserve el último libro guardado, su copia de seguridad fechada y el registro de sesión correspondiente. Primero compare el estado guardado. Si las entradas que faltan se ajustan a las condiciones de recuperación de registros simples admitidas, pruebe el registro coincidente en un libro copiado e inspeccione las entradas recuperadas exactas.
Rechazar un resultado de repetición poco claro
Si el candidato crea duplicados o no coincide con la sesión conocida, deje de usar esa copia de prueba. Guárdalo como evidencia y regresa a la base intacta. No reproduzca registros repetidamente hasta que el equilibrio parezca correcto. Seleccione otro candidato coherente o reconstruya las entradas faltantes verificadas a partir de registros autorizados, preservando la incertidumbre y la información de origen.
Después de aceptar un resultado, guárdelo con un nombre de archivo nuevo y claro y vuelva a abrir una copia. Compare nuevamente la misma muestra de transacción y configuración del informe. Esto verifica la persistencia así como la operación de recuperación inicial. Conserve la base y los registros originales hasta que el libro aceptado pase la revisión que realmente necesita.
Trabajar con una copia de seguridad anterior abierta por error
Imagine que al libro actual parece que le falta una semana de trabajo, pero su nombre de archivo contiene una marca de tiempo antigua. Consérvelo e inspeccione el historial de archivos recientes y el directorio activo esperado. Otra copia puede contener la semana que falta. Compare transacciones distintivas en lugar de asumir que el archivo con marca de tiempo tiene autoridad porque fue el que abrió hoy.
Conservar el trabajo válido de ambas copias
Es posible que la copia anterior ahora contenga nuevas entradas que realizó después del cambio accidental. Guarde ambos libros y enumere las diferencias reales. Reconstruir un estado aceptado controlado sólo después de comparar los registros y la cronología. Registre qué información proviene de qué fuente para que un revisor posterior pueda distinguir la recuperación del trabajo de entrada ordinario en curso.
Cree un inventario de recuperación de libros antes de elegir un candidato
Enumere cada libro superviviente con su ruta completa, tipo de almacenamiento, hito aproximado y el registro distintivo que contiene. Mantenga copias de seguridad fechadas, libros en vivo y copias de prueba en filas separadas. Este inventario ayuda a explicar por qué dos expedientes plausibles no están de acuerdo. La marca de tiempo más reciente del sistema de archivos puede reflejar una operación de copia, mientras que un candidato de apariencia más antigua puede contener la última secuencia de transacción válida que necesita.
Identificar un período de recuperación específico
Elija un pequeño período alrededor del incidente y enumere varios registros que pueda verificar de forma independiente. Incluya una transacción antes de la pérdida y una que se espera después. Esto establece un límite para la comparación. Es más útil que decir que falta una semana, porque la aparente brecha puede reflejar un filtro de informe, un libro equivocado o un trabajo ingresado en otra copia.
Compare el mismo período en cada candidato utilizando configuraciones consistentes de cuenta y fecha. Registre qué registros aparecen realmente en lugar de depender de totales de informes configurados de manera diferente. Una comparación clara puede revelar una copia de seguridad nativa útil sin ninguna repetición ni reconstrucción. También puede mostrar que el libro actual contiene trabajos posteriores válidos que debes conservar antes de aceptar una fuente anterior.
Distinguir una vista filtrada de las transacciones faltantes
Un registro o informe puede ocultar información a través del período y filtros seleccionados. Verifique esos controles antes de retroceder el libro. Busque una descripción distintiva u otro detalle confiable y no ambiguo. Si la transacción existe en otra parte del mismo libro, investigue su cuenta y contexto de fecha en lugar de asumir que los datos se eliminaron del almacenamiento.
Mantenga los cambios de vista separados de los cambios de registro
Ajuste la vista en un contexto de trabajo y compare la transacción subyacente. No edite fechas o cuentas simplemente para que aparezca una entrada en el informe esperado. Eso cambiaría los datos en lugar de diagnosticar la pantalla. Registre el entorno que explicó la aparente ausencia para que el mismo malentendido no provoque otro intento de recuperación más adelante.
Si el registro realmente no existe, conserve el libro actual y pase a una comparación de respaldo coherente. La ausencia de una entrada no establece que todas las cuentas deban revertirse. Una reconstrucción más estrecha a partir de evidencia autorizada puede preservar información útil posterior, pero debe seguir siendo una decisión deliberada con su fuente registrada.
Haga coincidir registros XML con una línea de tiempo escrita
Para una investigación adecuada del libro XML, tenga en cuenta la base guardada, el inicio de la sesión y el registro asociado con esa sesión. Conserve los nombres originales y un conjunto de prueba copiado. El propósito es establecer una relación específica, no ordenar todos los registros por fecha y reproducirlos automáticamente. Un registro de otro libro divergente puede describir cambios que no pertenecen a la base elegida.
Deténgase cuando las estructuras empresariales estén involucradas
Si la sesión relevante incluye acciones comerciales, evite tratar una simple repetición de registro como un procedimiento de rescate general. El equilibrio visible y las relaciones comerciales de la aplicación son cosas diferentes. Prefiere una copia de seguridad completa y consistente y una revisión adecuada de la aplicación específica. Una transacción que parece correcta en un registro aún puede tener una relación incompleta con otro registro comercial.
Este límite también se aplica cuando no se puede determinar qué contenía la sesión de registro. Preservar la evidencia en lugar de experimentar con el libro vivo. Una decisión cautelosa de utilizar una copia de seguridad completa o una reconstrucción manual documentada es más confiable que aceptar una repetición incierta porque su total final se asemeja a una cifra esperada.
Revisar un candidato repetido contra registros independientes
Si una prueba de registro simple compatible es apropiada, compare el resultado con la muestra de transacción que preparó. Inspeccione fechas, descripciones, montos, asignaciones de cuentas y duplicados inesperados. Mantenga la salida de la prueba separada de la base guardada. Un mensaje de reproducción completa establece que se ejecutó una operación, no que reconstruyó la sesión exacta que pretendía.
Compruebe si hay entradas duplicadas o fuera de lugar
Una entrada puede aparecer dos veces o pertenecer a otra cuenta, dejando plausible un total más amplio. Comparar identidades individuales y la secuencia circundante. Si el resultado no es claro, conserve la copia de prueba y regrese a la fuente intacta. No elimine entradas de forma especulativa hasta que las cifras le resulten familiares; eso haría que la recuperación fuera más difícil de auditar.
Registre qué transacciones aceptó y cuáles quedaron inciertas sin inventar detalles históricos. Es posible que una nota o un archivo adjunto no sobreviva incluso cuando el monto de la transacción sí lo haga. Mantener esos límites visibles le permite continuar con un libro utilizable y al mismo tiempo distinguir los datos restaurados directamente de la información reconstruida posteriormente.
Evaluar una copia de seguridad completa según su alcance real
Una copia de seguridad puede preservar el libro nativo y al mismo tiempo excluir recibos, extractos u otras pruebas vinculadas externas. Identifique qué archivos de soporte necesita la tarea actual y verifíquelos por separado. Es posible que un libro que se abre correctamente aún deje un archivo adjunto requerido no disponible. Conserve la información de la relación en lugar de eliminar las referencias rotas para que la copia de trabajo luzca más limpia.
Pruebe los documentos de respaldo de forma independiente
Abra un documento copiado representativo en su aplicación correspondiente y compare una página o fecha distintiva. Un nombre de archivo por sí solo no establece que sobreviviera la evidencia correcta. Mantenga al candidato original sin cambios durante la prueba. Si otro documento sustituye la fuente que falta, etiquete esa sustitución en lugar de dar a entender que proviene de la copia de seguridad del libro nativo.
Para un archivo grande, tome muestras de diferentes períodos y tipos de archivos que sean importantes para el incidente. Registre el alcance de su cheque. Una muestra exitosa respalda el material probado; no prueba que todos los apegos estén completos. Mantenga una lista sin resolver para que las brechas importantes permanezcan visibles durante el trabajo continuo.
Maneje libros divergentes sin sobrescritura ciega
Supongamos que el libro vivo original contiene el trabajo más reciente, mientras que una copia fechada contiene entradas realizadas después de que alguien abrió el archivo equivocado. Conserve ambos y compare las diferencias reales. No elija uno únicamente por su ruta o marca de tiempo. El resultado aceptado puede requerir la reconstrucción de información faltante verificada a través de flujos de trabajo de entrada normales de GnuCash en un libro de trabajo separado.
Mantenga un registro de origen para cada reconstrucción
Utilice detalles de transacción no ambiguos y el registro de respaldo autorizado para documentar lo que recreó. Conserve el libro previo a la reconstrucción. Esto hace posible revisar el resultado aceptado e identificar qué valores provienen directamente de una fuente nativa versus reingresos posteriores. Evite cambiar registros no relacionados mientras la recuperación inmediata permanece en comparación.
Si las diferencias son complejas, defina un objetivo de aceptación limitada antes de continuar. Recuperar un conjunto utilizable de entradas ordinarias y restaurar un estado comercial histórico completo son tareas diferentes. La evidencia y la revisión necesarias para uno no deben convertirse en una afirmación sin fundamento sobre el otro.
Preservar la coherencia del backend durante la copia
Para un candidato respaldado por archivos, prefiera una copia cerrada estable en lugar de copiar archivos mientras la aplicación los cambia. Para un servidor backend, utilice el mecanismo de copia de seguridad consistente legítimo para esa base de datos. Un directorio lleno de archivos recientes individualmente no necesariamente representa un estado coherente de la base de datos, y mezclar componentes de diferentes momentos puede crear otro problema.
Registre cualquier conversión de almacenamiento
Si convierte un libro copiado para una investigación legítima, conserve el original intacto y anote el formato de entrada y la versión de la aplicación. Compara el contenido después. Una conversión exitosa no establece que todas las relaciones sigan siendo correctas o que el archivo resultante refleje el hito del incidente original. Trate la conversión como un paso adicional con sus propios controles.
Mantenga el resultado nativo aceptado o específico del backend separado de los experimentos fallidos. Un conjunto de fuentes claro y un registro de recuperación son más útiles que varios archivos renombrados como finales. La siguiente persona debería poder identificar el libro verificado y comprender qué candidatos originales siguen siendo relevantes para las preguntas no resueltas.
Pruebe el libro aceptado como una restauración real
Abra un hito aceptado copiado en el entorno de aplicación previsto. Compare las transacciones del incidente, la configuración consistente del informe y una cuenta representativa no relacionada. Esto verifica tanto la recuperación objetivo como el contexto más amplio. Un archivo que simplemente se abre aún no ha demostrado que admita la tarea de contabilidad que necesita reanudar.
Preservar la evidencia de aceptación
Mantenga el hito de origen, el período de comparación, las brechas conocidas y los registros de respaldo en una breve nota de recuperación. Luego conserve una copia de seguridad consistente fuera de la copia de trabajo activa a través del acuerdo de protección elegido. La prueba práctica es si ese conjunto conservado puede reproducir el libro verificado, no simplemente si un proceso de copia de seguridad informa que copió un archivo.
Cuando la recuperación del almacenamiento puede ayudar a los archivos GnuCash
PandaOffice Drecov puede ayudar a recuperar libros locales eliminados, copias de seguridad fechadas, registros o registros de respaldo legítimos desde un almacenamiento legible. No puede inventar transacciones que nunca alcanzaron el almacenamiento persistente ni convertir un archivo bloqueado en un libro completo. Prefiera primero las copias de seguridad existentes coherentes y el libro en vivo correcto, y reduzca las escrituras donde puedan permanecer los candidatos eliminados.
Paso 1: identificar el almacenamiento real del libro
Seleccione la unidad o partición que contenía el libro local, su directorio de respaldo o registros de respaldo. Distinga una base de datos local de una fuente respaldada por un servidor. Mantenga la salida recuperada en otro almacenamiento saludable. Si la fuente informa repetidos errores de lectura de hardware o desconexiones, evalúe esa condición antes de continuar con un análisis de recuperación de software de rutina.
Paso 2: comparar candidatos a libros coherentes
Revise las rutas disponibles, los nombres, las fechas, los tamaños y las vistas previas admitidas. Conserve libros completos y plausibles y sus registros asociados sin fusionar sesiones no relacionadas. El texto de la transacción reconocible no prueba que un candidato contenga un libro completo y consistente. Mantenga las alternativas hasta que GnuCash pueda abrir una copia de trabajo y usted pueda inspeccionar los registros relevantes.
Paso 3: restaurar en otro lugar y verificar registros
Recupere archivos seleccionados en un destino separado y conserve un conjunto de fuentes intacto. Abra un libro completo copiado a través del flujo de trabajo de backend adecuado y luego compare las transacciones, las cuentas y los informes del incidente. Utilice la reproducción de registros solo dentro de sus condiciones verificadas. Registre la información reconstruida y las relaciones no resueltas antes de aceptar el libro de trabajo restaurado.
Preservar un hito de libro comprobable
Mantenga el libro nativo aceptado o la copia de seguridad de backend consistente, su registro de recuperación y la evidencia independiente utilizada para la verificación. Pruebe una restauración copiada con una transacción e informe distintivos. Esto proporciona una ruta práctica para regresar a un estado de datos conocido en lugar de depender de un directorio de copias de seguridad cuyo contenido nadie ha verificado.
Recursos de recuperación relacionados
Explore las opciones de recuperación relevantes: Recuperación del disco duro, Recuperación de disco duro externo.
Para conocer otro caso de recuperación y sus comprobaciones prácticas, lea la guía de recuperación relacionada.
Consulte la guía del proveedor para la versión instalada: documentación oficial de recuperación 1, documentación oficial de recuperación 2, documentación oficial de recuperación 3.
