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. Configure ambas; cubren desastres distintos.
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.
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
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.
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.
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
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.
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.
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.
Compruebe
/api/health/en la instancia restaurada:db_statusyredis_statusambos verdaderos. Esto confirma que la base de datos restaurada no solo está presente, sino que es alcanzable y responde.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.
Abra una sesión real en la instancia restaurada, con un protocolo que use, y confirme que se completa y queda grabada.
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.
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.
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.
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
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
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
Atualizado
Isto foi útil?