> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/es/pam/deploy-operate/backup-and-restore.md).

# Copia de seguridad y restauración

La copia de seguridad de la instalación (base de datos, configuración y grabaciones), dónde vive realmente cada una de esas cosas, y la restauración de prueba que convierte una copia en algo fiable.

## Qué es esto y cuándo usarlo

Esta página trata de la copia de seguridad **de la instalación**: la base de datos, la configuración y las grabaciones de sesión. Es lo que necesita para devolver el servicio tras perder un servidor.

No es la copia de seguridad de credenciales. Aquello es una funcionalidad aparte, una exportación cifrada de la bóveda, entregada por correo electrónico, SFTP o webhook, con la clave de descifrado repartida entre dos custodios, y existe para otro escenario: recuperar credenciales estratégicas sin restaurar el entorno en absoluto. Está documentada en [La bóveda de credenciales](/es/pam/administration/accounts/vault.md). Configure ambas; cubren desastres distintos.

{% hint style="danger" %}
**Una copia de seguridad que nunca se ha restaurado es una hipótesis.** Que el trabajo de copia informe de éxito demuestra que se escribió un archivo, no que de él pueda recuperarse nada. Todo lo que hay en [Cómo verificar que funcionó](#como-verificar-que-funciono) existe porque es precisamente en esa distinción donde fallan las recuperaciones.
{% endhint %}

{% hint style="warning" %}
**El material de origen de esta wiki no contiene un procedimiento de copia de seguridad.** La antigua base de conocimiento apuntaba a un documento sobre implementar y modificar rutinas de copia, y ese enlace está roto. Lo que sigue es lo que la plataforma está especificada para hacer y lo que hay que cubrir. No es una rutina que usted pueda ejecutar. Los comandos, la programación y los destinos de su instalación deben confirmarse con el soporte de implantación de DataDike.
{% endhint %}

## Qué tiene que estar en la copia de seguridad

Cuatro cosas, en tres sitios distintos. Una copia que solo cubre la primera es la forma más común de que una restauración fracase.

| Qué                                               | Dónde vive                                                                                                                                    | Por qué exige una reflexión aparte                                                                                                                                                                                                   |
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **La base de datos**                              | Interna al appliance                                                                                                                          | Guarda usuarios, activos, cuentas, autorizaciones y los registros de auditoría y de sesión. La plataforma soporta la copia y la recuperación de la base de datos y de la configuración del software                                  |
| **Configuración que no está en la base de datos** | El archivo de configuración del appliance, `/opt/datadike/config/config.txt`, donde se fijan los ajustes de syslog y el intervalo de limpieza | Los cambios en él solo surten efecto cuando los servicios se reinician, lo que también significa que un archivo restaurado no hace nada hasta que los servicios vuelven                                                              |
| **Grabaciones de sesión**                         | El backend de almacenamiento de objetos configurado en **Configuración del sistema › Almacenamiento › Almacenamiento de objetos**             | Por defecto es el backend `default`, de tipo Server, es decir, el sistema de archivos local del servidor. Si lo movió a un bucket externo, ese bucket se respalda en sus propios términos y una copia de la base de datos no lo toca |
| **La PKI del broker**, si usa un broker           | La VM del broker                                                                                                                              | Los certificados son el ancla de confianza de todos los gateways y conectores enrolados a través de ese broker                                                                                                                       |

{% hint style="warning" %}
**Respalde la VM del broker y direccione el broker por nombre DNS.** Perder la VM del broker sin copia de seguridad significa reinstalarla y volver a enrolar todos los gateways y conectores remotos. Y la dirección queda escrita en los certificados y en los tokens de enrolamiento: si el broker se direccionó por nombre DNS, puede apuntar ese nombre a una VM restaurada y los certificados siguen siendo válidos; pero si se direccionó por una IP literal, la dirección no puede cambiarse después sin reinstalar el broker.
{% endhint %}

## Qué está especificada la plataforma para hacer

Estas son las capacidades declaradas para la solución. Trátelas como la forma de lo que hay que exigir, y confirme cómo está configurada cada una en su instalación.

| Capacidad                | Tal como se declara                                                                                                                                                                                                |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Destinos                 | Copia y restauración de todos los datos y de la configuración, exportables a un servidor remoto por rsync o por recursos compartidos de red CIFS/NFS                                                               |
| Copias fuera del sitio   | Las copias de sistema, los registros, los vídeos y las credenciales pueden extraerse a un servidor de un centro de datos remoto, de modo que toda la configuración y todos los datos puedan restaurarse desde allí |
| Protección del contenido | Ninguna cuenta ni contraseña aparece en texto claro en el archivo de copia                                                                                                                                         |
| Retención de las copias  | Copias sin restricción de retención, cifradas y protegidas contra manipulación; informes y registros conservados en copia durante al menos diez años, y grabaciones de sesión durante al menos diez años           |
| Retención en línea       | Los informes y los archivos históricos siguen disponibles, sin restauración, durante al menos 360 días                                                                                                             |

## La copia de seguridad no es lo mismo que la alta disponibilidad

La arquitectura ya protege frente al fallo de un nodo: operación activo/activo, replicación de la base de datos con elección automática de primario, replicación de caché y de cola con failover, almacenamiento compartido entre nodos y una única dirección virtual por delante. Los objetivos de continuidad declarados son **RTO de una hora o menos y RPO de quince minutos o menos**.

Nada de eso es una copia de seguridad. La replicación propaga un borrado exactamente igual de rápido que propaga una escritura. La alta disponibilidad cubre que un nodo muera; la copia cubre que algo se borre, se corrompa o se cambie mal, incluido por usted mismo, durante una ventana de cambio.

## Antes de empezar

* **Decida el destino**, un servidor remoto por rsync o un recurso compartido CIFS/NFS, y confirme que el appliance puede alcanzarlo. Una copia fuera del sitio es lo que sobrevive al evento que se lleva el sitio principal.
* **Averigüe dónde están realmente las grabaciones.** Abra **Configuración del sistema › Almacenamiento › Almacenamiento de objetos** y anote qué backend está marcado como predeterminado. Es exactamente uno. Si es un bucket externo, su copia es un acuerdo aparte.
* **Confirme la copia de credenciales por separado**, incluido si hay dos custodios configurados: con uno solo, la clave no está repartida en absoluto. Consulte [La bóveda de credenciales](/es/pam/administration/accounts/vault.md).
* **Tenga dónde restaurar.** Una instancia de prueba no es equipamiento opcional; es el único sitio donde puede ocurrir la verificación de más abajo.
* **Haga una copia completa antes de cualquier cambio estructural**, y en concreto antes de habilitar y sincronizar una bóveda externa de almacenamiento de cuentas. La fuente lo destaca, junto con la recomendación de probar antes esa integración en un entorno de preproducción.

## Restauración

{% hint style="warning" %}
**No se pudo portar ningún procedimiento de restauración: la fuente no documenta ninguno.** Recurra al soporte de implantación de DataDike para la restauración de una instalación. Lo que sigue es lo que la fuente sí establece sobre las vías de recuperación, que conviene conocer *antes* de necesitarlas.
{% endhint %}

**Las credenciales pueden recuperarse sin restaurar el entorno.** La copia de credenciales puede abrirse con su clave de cifrado, de modo que, en un desastre, las credenciales estratégicas son recuperables incluso mientras la propia plataforma está indisponible. Esta es la vía de recuperación más rápida para el caso "necesitamos las contraseñas ahora mismo", y es completamente independiente de la restauración de la instalación.

**Recuperar la clave de cifrado de la copia exige varias personas.** El proceso de recuperación de la clave designa a administradores como custodios de partes de la clave, y un número predefinido de ellos debe estar presente para reconstruirla durante la recuperación ante desastres.

{% hint style="danger" %}
**La clave de la bóveda no debe estar en manos de una sola persona.** Eso es un requisito de diseño de la solución, no una preferencia. También significa que la recuperación es una actividad programada y con varias personas: averigüe ahora quiénes son los custodios y si todos siguen en la organización, en lugar de averiguarlo durante el incidente.
{% endhint %}

**Un broker restaurado conserva sus certificados solo si se direccionó por nombre DNS.** En caso contrario, el broker se reinstala y todos los gateways y conectores remotos se vuelven a enrolar.

## Cómo verificar que funcionó

Esta es la sección que importa. Restaurar es la única prueba de una copia de seguridad, y las comprobaciones de abajo están ordenadas de forma que cada una cubra una laguna que la anterior no puede ver.

1. **Restaure en una instancia de prueba**, nunca sobre producción. Si no puede decir la fecha de su última restauración de prueba correcta, no tiene una copia verificada, diga lo que diga el historial del trabajo.
2. **Compruebe `/api/health/` en la instancia restaurada**: `db_status` y `redis_status` ambos verdaderos. Esto confirma que la base de datos restaurada no solo está presente, sino que es alcanzable y responde.
3. **Compruebe Configuración del sistema › Componentes**: todos los componentes en **Normal**. Una restauración que devuelve la base de datos pero no los componentes produce una consola que carga y una plataforma que no puede abrir una sesión.
4. **Abra una sesión real** en la instancia restaurada, con un protocolo que use, y confirme que se completa y queda grabada.
5. **Reproduzca una grabación hecha antes de tomar la copia.** Esta es la comprobación que atrapa la laguna más habitual de todo el procedimiento: las grabaciones viven en un backend de almacenamiento, y una copia solo de la base de datos restaura todos los *registros* de sesión mientras faltan todas las reproducciones. Si la reproducción falla aquí, su copia no cubre las grabaciones.
6. **Confirme la fecha y la hora del servidor en la instancia restaurada.** Un reloj equivocado invalida los códigos OTP, de modo que los inicios de sesión con MFA fallan en un sistema por lo demás restaurado a la perfección. Consulte [Autenticación multifactor](/es/pam/administration/identities/mfa.md).
7. **Verifique la copia de credenciales en sus propios términos**: el trabajo tuvo éxito y cada custodio recibió su parte; dos partes, si configuró dos custodios.
8. **Anote la fecha, la versión restaurada y lo que falló.** El valor de una restauración de prueba está sobre todo en la lista de cosas que no funcionaron.

## Errores frecuentes

| Síntoma                                                                                       | Causa                                                                                                                                                                         | Solución                                                                                                                                    |
| --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| La instancia restaurada funciona, pero ninguna reproducción de sesión se abre                 | Las grabaciones viven en el backend de almacenamiento de objetos, que la copia de la base de datos nunca tocó                                                                 | Respalde también el backend de almacenamiento; compruebe qué backend es el predeterminado en **Almacenamiento › Almacenamiento de objetos** |
| Los archivos de grabación han desaparecido aunque los registros de sesión los siguen listando | La retención de la consola gobierna los registros de la base de datos; el ciclo de vida de los archivos es la política de ciclo de vida del propio bucket, configurada aparte | Alinee la política de ciclo de vida del bucket con su requisito de retención                                                                |
| Un evento antiguo de auditoría no aparece por ninguna parte                                   | Su ventana de retención venció y la limpieza nocturna borró el registro. No se muestra ningún error: un resultado vacío parece un "nunca ocurrió"                             | Fije los valores de retención frente a sus obligaciones de auditoría antes de necesitar la evidencia                                        |
| La copia de credenciales llega como un único archivo que un solo destinatario puede abrir     | Solo se configuró un custodio, así que la clave nunca se repartió                                                                                                             | Configure los dos custodios; consulte [La bóveda de credenciales](/es/pam/administration/accounts/vault.md)                                 |
| La clave de cifrado de la copia no puede reconstruirse                                        | Hay menos custodios disponibles que el número necesario para recuperar la clave                                                                                               | El umbral es un requisito de diseño; mantenga la lista de custodios al día y documentada                                                    |
| El broker se restauró, pero los gateways y conectores no vuelven a conectar                   | El broker se direccionó por una IP literal, así que sus certificados no pueden reapuntarse a una VM restaurada                                                                | Direccione el broker por nombre DNS. En caso contrario, reinstale el broker y vuelva a enrolar cada punto remoto                            |
| Un archivo de configuración restaurado parece no surtir efecto                                | La configuración del `config.txt` del appliance se lee cuando arrancan los servicios                                                                                          | Reinicie los servicios después de restaurar el archivo                                                                                      |
| El inicio de sesión con MFA falla en una instancia recién restaurada                          | Fecha y hora del servidor incorrectas, de modo que los códigos OTP se rechazan                                                                                                | Corrija el reloj del servidor                                                                                                               |

## Páginas relacionadas

* [La bóveda de credenciales](/es/pam/administration/accounts/vault.md)
* [Grabaciones de sesión](/es/pam/administration/audit/recordings.md)
* [Registro de auditoría](/es/pam/administration/audit/audit-trail.md)
* [Actualización](/es/pam/deploy-operate/upgrade.md)
* [Monitorización y salud](/es/pam/deploy-operate/monitoring.md)
