Un proveedor que empieza a respaldar a sus clientes vive una progresión en tres tiempos. Los cinco primeros clientes: todo va bien, se leen los informes. Los veinte siguientes: se ojean. Más allá: ya no se leen, y se descubre el día en que un cliente pide una restauración sobre una copia detenida desde hace seis semanas.
No es un problema de rigor. Es un problema de diseño.
Por qué el informe diario por correo no aguanta
El modelo por omisión de muchas soluciones: cada copia envía un informe, se reciben todos, se miran.
Con cincuenta clientes y tres máquinas por cliente, son ciento cincuenta correos al día. Algunos reflejos aparecen por sí solos: una regla de clasificación los coloca en una carpeta, luego se consultan «cuando hay tiempo», luego nunca más.
El vicio de construcción está ahí: el informe diario señala lo que ha ocurrido, no lo que no ha tenido lugar. Una copia que falla envía un correo de error. Una copia que no arranca en absoluto —puesto apagado, agente desinstalado durante un cambio de máquina, servicio detenido— no envía nada. El silencio es indistinguible de la calma.
La alerta que cuenta: la ejecución que no se produjo
El vuelco se produce cuando se invierte la lógica: en lugar de esperar una señal de error, se vigila la ausencia de una señal esperada.
Una alerta de no arranque útil tiene tres propiedades:
Se ajusta por máquina, no globalmente. Un portátil que respalda tres veces por semana y un servidor que respalda todas las noches no tienen el mismo umbral. Un umbral único produce o ruido o puntos ciegos.
Tiene en cuenta los servidores múltiples. Si replica o si tiene varios servidores de copia, un puesto que ha respaldado en otro sitio no debe disparar una alerta. Una solución que interroga a los otros servidores antes de alertar le evita las falsas alarmas, y las falsas alarmas son lo que mata una supervisión, porque se acaba ignorándolas todas.
Se puede consultar, no solo enviar. Un correo se pierde. Un panel que muestra los estados en curso se lee en treinta segundos por la mañana.
El panel como punto de partida
El objetivo de la mañana no es comprobarlo todo: es saber en una pantalla si hay algo que hacer.
En concreto, un estado que distinga las situaciones: error, advertencia, no arrancada, bloqueada, copia en curso, restauración en curso, replicación en curso, control de integridad, copia de Microsoft 365. Cada una pide una acción distinta, o ninguna.
El filtrado por perímetro cuenta tanto como los estados mismos. Un técnico que gestiona diez clientes no debe ver los cincuenta: el ruido hace la vista inservible.
Los permisos por técnico
Es un asunto que se posterga y que acaba bloqueando.
Mientras uno está solo, todo el mundo es administrador. Con tres técnicos llegan las preguntas: ¿debe un primer nivel poder relanzar una copia? Sí, es el objetivo. ¿Modificar una regla de conservación? No, eso puede borrar versiones. ¿Restaurar en casa de un cliente? Según los casos.
Una granularidad fina —del orden de medio centenar de permisos con nombre— permite responder a esas preguntas una vez y después contratar sin reabrir el debate. La pregunta correcta: ¿cuál es la acción más destructiva que este perfil puede desencadenar?
Los informes que llegan al cliente
Coexisten dos realidades: lo que usted vigila, y lo que su cliente ve.
El cliente no necesita las ciento cincuenta líneas diarias. Necesita, a intervalos regulares, una página legible que diga qué está protegido, con qué profundidad, y si todo va bien. A su nombre, no al del fabricante: es usted quien presta el servicio.
Es también el documento que saca en la reunión anual cuando le preguntan para qué sirve la línea «copia de seguridad» de la factura.
La prueba de restauración, que hay que planificar como una tarea
Todo lo anterior vigila que las copias tengan lugar. Nada garantiza que sean restaurables.
La prueba de restauración es la única comprobación que cuenta, y es también la primera que se abandona por falta de tiempo. Dos formas de sostenerla en el tiempo:
- El control de integridad automático del lado del servidor, que vuelve a leer los datos y compara las huellas después de cada copia o según una regla por máquina. No sustituye a una restauración, pero detecta la corrupción silenciosa sin ocupar a nadie.
- Una restauración real por cliente y por año, planificada como una tarea de mantenimiento. Un archivo, una carpeta, y una vez cada dos o tres años un sistema completo en los clientes críticos.
El segundo punto tiene un beneficio comercial a menudo subestimado: un informe de restauración fechado es el argumento más sólido del que dispone frente a un competidor que no producirá ninguno.
Una organización que aguanta
| Frecuencia | Lo que se hace |
|---|---|
| Cada mañana | Un vistazo al panel, filtrado sobre las anomalías |
| Cada semana | Tratamiento de las máquinas silenciosas y de las advertencias recurrentes |
| Cada mes | Revisión de los volúmenes, las cuotas y el espacio de disco restante |
| Cada trimestre | Una restauración de control, documentada |
| Cada año | Revisión del perímetro con el cliente: qué ha cambiado en su sistema de información |
La última línea es la que da beneficio. Un cliente que ha añadido un servidor, una aplicación de negocio o un recurso compartido sin decírselo tiene un agujero en su protección, y descubrirlo en una revisión, y no en un siniestro, es lo que le permite seguir siendo su proveedor.
BeBackup fue concebido por un proveedor informático para su propio parque: consola multicliente, alertas de no arranque calculadas por máquina, permisos finos e informes en marca blanca. Ver la página de proveedores o pedir una demostración.