Copias de seguridad que se han restaurado de verdad.
Para quién
Para empresas y administraciones con aplicaciones, portales o bases de datos que no pueden perderse, y sin nadie que tenga tiempo de comprobar que la copia sirve.
El problema
«Copias hay, creo.» Las configuró alguien hace años y nadie ha vuelto a mirarlas. No sabes qué se copia, dónde está ni cuánto tardarías en volver a funcionar. Y el día que hace falta, la copia está incompleta o nadie sabe restaurarla.
Cómo lo resolvemos
Hacemos inventario de lo que hay que copiar y lo copiamos cifrado, fuera del servidor. Después lo restauramos: levantamos la copia en un entorno aparte y comprobamos que la aplicación arranca con sus datos. Una copia que no se ha restaurado no cuenta.
Qué incluye
Inventario
Qué se copia, qué no y por qué: bases de datos, documentos y configuración.
Copias cifradas
Se cifran antes de salir del servidor y se guardan en otro sitio.
Pruebas de restauración
Restauramos de verdad en un entorno aparte, y queda apuntada la fecha y el resultado.
Vigilancia de las copias
Si una copia falla o no se hace, nos enteramos nosotros, no tú.
Procedimiento escrito
Los pasos para restaurar, por escrito y probados, para que no dependan de una persona.
Informe mensual
Copias hechas, pruebas de restauración y lo que haya fallado.
Cómo trabajamos
Empezamos por el inventario y por acordar contigo, por escrito, cada cuánto se copia y cuánto tiempo se guarda. Después las copias se hacen solas y nosotros las comprobamos. Cada mes recibes el informe con las pruebas de restauración. Si un día hay que restaurar de verdad, lo decides tú y lo hacemos nosotros.
Qué medimos
Copias hechas y copias fallidas, antigüedad de la última copia válida, fecha y resultado de la última prueba de restauración y tiempo que se tarda en restaurar.
Cómo está hecho
Copiamos tres cosas: la base de datos (un volcado coherente, no sus ficheros en caliente), los documentos y la configuración. En una instalación de Liferay eso es la base de datos PostgreSQL, la biblioteca de documentos y los ficheros de configuración. El índice de búsqueda de Elasticsearch no se copia: se regenera.
Las copias se cifran en origen, antes de salir del servidor, y se guardan en un almacenamiento distinto del de producción. Las claves de cifrado están en el gestor de secretos, no en el servidor ni en un fichero: sin ellas la copia no se puede leer.
La prueba de restauración sigue siempre los mismos pasos: se levanta la copia en un entorno aislado, se arranca la aplicación y se comprueba que responde y que los datos están. Si falla, se trata como una incidencia. La infraestructura está descrita como código, así que también se puede reconstruir el servidor, además de sus datos.
Las tareas de copia, sus scripts y el procedimiento de restauración quedan en tus repositorios. Si mañana lo opera otro equipo, tiene lo que necesita.
Preguntas frecuentes
¿Qué significa que una copia está comprobada?
Que la hemos restaurado en un entorno aparte y la aplicación ha arrancado con sus datos. Queda apuntado cuándo se hizo y cómo salió.
¿Cada cuánto se copia y cuánto tiempo se guarda?
Depende de cuánto trabajo puedes permitirte perder y de tus obligaciones legales. Lo acordamos por escrito antes de empezar y sale en cada informe.
¿Quién puede leer las copias?
Nadie sin la clave. Las copias se cifran antes de salir del servidor y la clave está en un gestor de secretos, con registro de quién accede.
¿Podéis haceros cargo de las copias de un sistema que no habéis montado?
Sí. Empezamos por revisar qué copias hay y por restaurar una. Lo que salga de esa prueba es el punto de partida.
También en Sistemas gestionados
Monitorización
Vigilancia de errores y de disponibilidad, con el arreglo ya preparado.
Despliegues
Cada cambio pasa por pruebas antes de producción, con vuelta atrás.
El siguiente paso
Cuéntanos cómo trabaja hoy tu empresa y te decimos por dónde empezar.