Copias de seguridad de un VPS: qué comprobar antes de contratar

Las preguntas que hacer

Frecuencia y conservación: lo que puede perder

Dos duraciones resumen una política de copias de seguridad:

• La pérdida máxima admisible (RPO, recovery point objective): la cantidad de trabajo que acepta perder. Una copia cada noche supone como máximo 24 horas; una base de datos que registra pedidos todo el día gana añadiendo el archivado continuo de su registro de transacciones.
• El tiempo máximo de interrupción (RTO, recovery time objective): el tiempo durante el que el servicio puede permanecer detenido. Depende del volumen que restaurar y, sobre todo, de quién restaura, y cuándo.

La conservación responde a otra pregunta: ¿hasta dónde puede remontarse? Un borrado detectado al día siguiente se recupera con la copia de la víspera. Una intrusión discreta, una corrupción silenciosa o un error en un proceso automático a veces se detectan más tarde: hace falta entonces un punto de restauración anterior al problema. Para los archivos a largo plazo, contables o reglamentarios, una exportación mensual guardada aparte completa la copia de seguridad del servidor.

Dónde están las copias de seguridad, y quién puede borrarlas

Una copia de seguridad protege de lo que le ocurre al servidor. Por eso vive en otro lugar:

• Un espejo de discos (RAID) protege de una avería de disco, y replica fielmente en el segundo disco un borrado o un cifrado malicioso hecho en el primero. Es una protección del hardware, no una copia de seguridad.
• Una instantánea (snapshot) en el mismo almacenamiento permite volver atrás rápidamente tras una actualización fallida, pero desaparece con el almacenamiento que la contiene.
• Una copia de seguridad fuera de la máquina, en un almacenamiento separado, sobrevive a la pérdida del servidor. Cifrada antes de salir, sigue siendo ilegible para quien no tiene la clave.

Un punto que a menudo se olvida: una copia de seguridad que se puede borrar desde el servidor también puede borrarla un intruso que haya tomado el control del servidor. Las copias hechas y guardadas por el proveedor, fuera del alcance del servidor copiado, escapan a ese riesgo.

El caso de las bases de datos

Una base de datos escribe de forma continua. Una copia de sus archivos hecha mientras funciona la captura tal como estaría tras un corte de corriente: PostgreSQL y MySQL saben arrancar de nuevo desde ese estado, reproduciendo su registro. Para una restauración fina, tabla por tabla, o hacia otra versión, se añade una copia lógica:

pg_dump -Fc -d mi_base -f /copias/mi_base-$(date +%F).dump
mysqldump --single-transaction --routines mi_base | gzip > /copias/mi_base-$(date +%F).sql.gz

Lanzadas cada noche por una tarea programada, antes de la hora de la copia de seguridad del servidor, estas exportaciones quedan incluidas en ella, y también pueden copiarse a un almacenamiento propio.

La regla 3-2-1

La regla que recomiendan las agencias de ciberseguridad cabe en tres cifras: 3 copias de sus datos, en 2 soportes diferentes, de las cuales 1 fuera de las instalaciones. En un VPS, se traduce así: los datos en servicio en el servidor, la copia de seguridad hecha por el proveedor fuera de la máquina, y una exportación regular de lo que más importa (la base de datos, los archivos subidos por sus usuarios) a un almacenamiento propio.

restic -r sftp:usuario@almacenamiento.example.com:/copias init
restic -r sftp:usuario@almacenamiento.example.com:/copias backup /copias

Probar una restauración

Una copia de seguridad se demuestra restaurándola. Una vez por trimestre, y después de cada cambio importante en el servidor:

1. Solicite o lance la restauración en un servidor de prueba, junto a la producción.
2. Compruebe que la aplicación arranca y responde.
3. Compare algunas cifras con la producción: número de filas de las tablas principales, fecha del último registro.
4. Anote el tiempo que ha llevado la operación: es su tiempo de interrupción real.

En un VPS administrado, estas copias de seguridad, su conservación fuera de la máquina y la propia restauración corren a cargo del proveedor: usted lo pide, y él restaura.

Si el servidor conserva datos personales, en la Unión Europea el RGPD (artículo 32) prevé, entre las medidas de seguridad apropiadas, la capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma rápida en caso de incidente físico o técnico, así como un proceso de verificación, evaluación y valoración regulares de la eficacia de esas medidas. Una prueba de restauración fechada es la forma más sencilla de acreditarlo.