El día que se caiga el servidor, ya sabemos cuánto tarda en volver.

Cómo trabajamos

1. 01

   Levantamos qué hay y cuánto puede estar caído

   Se inventaría qué servidores existen, qué corre en cada uno, dónde viven hoy el correo y los archivos, y quién tiene los accesos. Con dirección se define, sistema por sistema, cuántas horas puede estar detenido y cuánta información se puede perder sin que duela. Esos dos números deciden el diseño y el precio; sin ellos, cualquier propuesta es una adivinanza.

2. 02

   Decidimos qué se mueve y qué se queda

   No todo conviene en la nube. Se entrega por escrito el destino de cada sistema —nube, sitio o mixto— con lo que cuesta al mes cada opción, para que la decisión la tome la dirección con el costo a la vista y no el catálogo del proveedor.

3. 03

   Migramos por bloques, con el sistema anterior encendido

   Se mueve en ventanas fuera del horario de operación y por partes, no de un jalón. El sistema anterior queda prendido hasta que el nuevo responde, y si no responde se regresa esa misma noche. En correo, los buzones se copian completos antes de tocar el registro que dirige los mensajes, para que nadie pierda su historial.

4. 04

   Dejamos el respaldo puesto y restauramos uno antes de cerrar

   Respaldo diario con una copia fuera del sitio, guardada de forma que un secuestro de datos no la pueda borrar. Antes de dar por terminada la migración se restaura un respaldo contra el sistema real —no contra el listado del proveedor— y se cronometra. Ese número es la línea base contra la que se compara cada mes.

5. 05

   Escribimos, ensayamos y luego operamos el plan de caída

   Queda por escrito a quién se le habla, en qué orden se levanta cada sistema y qué se le dice al cliente mientras tanto. Un plan que solo se archiva no sirve: se ensaya. De ahí en adelante servidores y red quedan monitoreados dentro de la póliza, y cada mes recibes cuántas restauraciones se probaron y cuánto tardó cada una.

Lo que ya construimos

1. 02.1Operación de una flota de servidores propios en producción. Cada despliegue guarda la versión anterior y se puede regresar a ella; la base de datos no se revierte sola, y lo decimos antes.
2. 02.2Respaldos con copia fuera del sitio y política contra secuestro de datos.
3. 02.3Restauración de un respaldo verificada contra el sistema real, no contra el listado del proveedor.

Preguntas

¿Cuánto cuesta subir los servidores de mi empresa a la nube?

El costo se arma con tres partes que conviene ver por separado. Primera: la renta mensual de la infraestructura, que depende de cuántos servidores hay, cuánta información se guarda y qué tan rápido tiene que volver si se cae. Segunda: la póliza mensual de operación, que se cobra por el tamaño de la operación —hasta 20 equipos, de 20 a 100, o más de 100 equipos y varias plazas—. Tercera: la migración inicial, que se cotiza una sola vez con alcance cerrado. El equipo nuevo, las licencias y el cableado no entran en la cuota mensual: se cotizan aparte y con el margen escrito en la cotización.

¿Se detiene la operación mientras migran? ¿Cuánto tarda?

La migración se hace por bloques y en ventanas fuera del horario de trabajo, con el sistema anterior encendido hasta que el nuevo responde, así que la mayor parte del cambio no la nota nadie. Sí existe un corte real y programado: la copia final de una base de datos que se sigue moviendo obliga a detenerla un rato. Esa ventana se define con fecha y duración estimada antes de empezar, no sobre la marcha, y si el sistema nuevo no responde dentro de ella, se regresa al anterior esa misma noche.

¿Todo tiene que irse a la nube? Acabamos de comprar un servidor.

No. Una carga estable y predecible —un ERP con los mismos veinte usuarios de lunes a viernes— suele salir más barata en un servidor propio bien puesto que en renta mensual, y hay sistemas que se vuelven lentos si el dato tiene que viajar. Lo que casi siempre conviene mover primero es el respaldo, el correo y los archivos, porque son justo lo que se pierde cuando el sitio falla. Y hay que decirlo al revés también: si todo se va a la nube, el internet pasa a ser tan crítico como la luz, así que el diseño tiene que incluir un segundo enlace o dejar en sitio lo que no puede parar.

¿Cómo sé que mi respaldo sí sirve, si nunca hemos restaurado uno?

Hoy no lo sabes, y esa es la falla más común que encontramos: el reporte del proveedor dice «exitoso» todos los días y nadie ha abierto nunca el archivo. La única prueba válida es restaurar contra el sistema real y comprobar que la empresa puede trabajar con lo que salió; revisar el listado del respaldo no es prueba. Aquí eso se hace y se cronometra, y cada mes se reporta cuántas restauraciones se probaron y cuánto tardó cada una. También decimos lo incómodo antes de firmar y no después del incidente: una versión de software se puede regresar a la anterior, pero una base de datos no se revierte sola.

¿El correo y las cuentas quedan a nombre de mi empresa o del proveedor?

A nombre de tu empresa. El dominio, las cuentas de correo, el almacenamiento de archivos y las licencias se contratan con los datos fiscales de la empresa, y la administración se entrega documentada a quien tú designes. Eso es lo que evita el problema clásico: que el correo de la empresa viva en la cuenta personal de un empleado y se vaya con él cuando renuncia. En una migración de correo los buzones se copian completos antes de cambiar el registro que dirige los mensajes, de modo que el historial no se pierde ni queda partido en dos.

¿Y si el servidor se cae un sábado a las once de la noche?

Los tiempos de respuesta comprometidos en la póliza corren en horario hábil: 30 minutos cuando la operación está detenida, 2 horas cuando un área no puede trabajar, 8 horas cuando hay una persona afectada con forma de seguir, y 2 días para solicitudes y mejoras. No hay guardia nocturna ni de fin de semana incluida en la póliza estándar, y se dice de frente en lugar de dejar que se descubra el sábado. Lo que sí trabaja de noche sin que nadie lo empuje es el monitoreo y el respaldo diario.