01
Capacidad ajustable
Procesador, memoria y almacenamiento se dimensionan para la carga y se revisan cuando cambia.
Algunos cambios requieren reinicio o una ventana planificada.Infraestructura cloud y continuidad
Infraestructura cloud para que la operación siga funcionando.
Diseñamos, migramos y mantenemos servidores cloud, copias y planes de recuperación para empresas que no quieren depender de un único equipo físico.
Gijón, Asturias · Proyectos en España y mercados hispanohablantes cuando pueden prestarse en remoto.
- Servidor y aplicaciones
- Copias verificables
- Recuperación ensayada
- Responsable reconocible
El problema real
Comprar otra máquina puede conservar el mismo riesgo.
Si el ERP, los documentos y las integraciones dependen de un solo servidor, una avería, un cifrado o una pérdida del centro principal puede detener la operación.
Cloud permite distribuir ese riesgo, ajustar capacidad y preparar otro entorno. La continuidad aparece cuando también se definen copias, dependencias, responsables, RPO, RTO y pruebas.
Cuatro capacidades
Infraestructura que puede cambiar y recuperarse.
Cada capa se dimensiona para la carga. No todas las aplicaciones necesitan el mismo nivel de disponibilidad ni el mismo coste.
02
Copias con retención
Puntos de recuperación horarios, diarios y semanales cuando la política contratada lo permite.
El alcance, la retención y la última restauración quedan documentados.03
Réplica en otra zona
Servidor, discos, red y reglas pueden replicarse fuera del entorno principal según el servicio elegido.
La réplica no sustituye las copias históricas ni la validación del dato.04
Recuperación probada
El procedimiento se ensaya con una carga real, responsables claros y criterios de aceptación.
Los tiempos válidos son los medidos en el simulacro, no una cifra genérica.El recorrido completo
No basta con que exista una copia.
El objetivo es devolver un servicio útil, con sus datos, accesos y conexiones, dentro de un tiempo acordado.
- 01
Operar
La aplicación funciona en un entorno inventariado y monitorizado.
- 02
Copiar
Los datos conservan puntos de recuperación con una política conocida.
- 03
Replicar
Las cargas acordadas mantienen un segundo plano en otra zona.
- 04
Recuperar
Un simulacro valida el orden, las dependencias y el tiempo real.
RPO
Hasta qué punto anterior puede recuperarse sin superar la pérdida de datos aceptable.
RTO
Cuánto puede durar la parada hasta recuperar un nivel de servicio útil y validado.
Tres capas distintas
Backup, disaster recovery y alta disponibilidad.
Pueden convivir, pero resuelven preguntas diferentes. Separarlas evita pagar por una promesa que no cubre el riesgo real.
CapaPara qué sirveQué incluyeLímite que conviene recordar
Backup
Recuperar datos o volver a un punto anterior.
Archivos, discos, bases de datos o cargas definidas.
No garantiza por sí solo que la aplicación completa arranque.
Disaster recovery
Volver a operar tras perder el entorno principal.
Servidor, datos, red, accesos y dependencias acordadas.
Necesita RPO, RTO, responsables y un simulacro válido.
Alta disponibilidad
Reducir interrupciones ante fallos dentro de la arquitectura.
Componentes redundantes y conmutación según el diseño.
No sustituye copias ni un plan para un desastre amplio.
Cómo lo hacemos
Migrar con prueba. Recuperar con evidencia.
AMBG entiende la carga, prepara el cambio, conserva una vuelta atrás y mantiene el procedimiento después de la puesta en producción.
- 01
Inventariar
Aplicaciones, datos, usuarios, red, licencias, integraciones y puntos únicos de fallo.
- 02
Acordar
Qué debe volver, cuánto dato puede perderse —RPO— y cuánto puede durar la parada —RTO—.
- 03
Migrar y proteger
Se prepara el destino, la copia o la réplica; se prueba con usuarios y se conserva una vuelta atrás.
- 04
Simular y mantener
Se ejecuta la recuperación, se mide el resultado y se actualiza el procedimiento cuando cambia el entorno.
Tecnología en contexto
La plataforma se elige después de entender la carga.
Trabajamos con servicios como Plenit/Jotelulu o Microsoft Azure cuando encajan, y con modelos híbridos cuando la operación necesita conservar parte del entorno local.
Cómo decidir entre local, cloud e híbridoAntes de decidir
Tres guías para hacer mejores preguntas.
Contenido técnico escrito para dirección, operaciones y responsables de IT; sin convertir una arquitectura en una lista de siglas.
Preguntas frecuentes
Lo importante antes de firmar una promesa cloud.
¿Servidor local, cloud o modelo híbrido?
Depende de la aplicación, la conectividad, la latencia, los equipos conectados, la capacidad y el impacto de una parada. AMBG revisa la carga antes de recomendar migrar. Algunas empresas conservan una parte local y llevan a cloud aplicaciones, copias o réplicas.
¿Se pueden hacer copias cada hora?
Sí, hay servicios con puntos de recuperación horarios, diarios y semanales. La propuesta debe precisar qué se copia, cómo se crea el punto, cuánto se conserva, dónde queda y cuándo se restauró por última vez. No llamamos copia completa a lo que la plataforma documenta como snapshot o punto de recuperación.
¿Cuánto tarda en activarse el segundo entorno?
No existe un tiempo universal. Depende de la frecuencia de réplica, el tamaño, la arquitectura, los pasos manuales y las validaciones. Se acuerdan RPO y RTO por carga y el tiempo operativo se obtiene en un simulacro. Sin esa prueba no prometemos una recuperación en segundos.
¿Puede ampliarse o reducirse el hardware?
Los recursos cloud permiten ajustar capacidad sin comprar un servidor físico nuevo. Algunos cambios son inmediatos y otros requieren reinicio, reubicación o una ventana de mantenimiento. También se revisan licencias y coste antes de aplicarlos.
¿Cloud elimina el riesgo de avería física?
Reduce la dependencia de una única máquina en las instalaciones y traslada la operación del hardware a la plataforma. No elimina todos los fallos. La continuidad sigue necesitando redundancia, copias, monitorización, accesos y procedimientos probados.
¿Con qué plataformas trabaja AMBG?
Seleccionamos la plataforma según la carga, el nivel de continuidad y la operación del cliente. Podemos trabajar con servicios como Plenit/Jotelulu o Microsoft Azure, además de entornos híbridos. La marca no sustituye el diseño ni la responsabilidad operativa.
Revisión de 30 minutos
Trae una carga concreta, no una solución decidida.
Cuéntanos qué servidor o aplicación sostiene la operación, qué ocurre si se detiene y qué copia existe hoy. Revisaremos el riesgo y el siguiente paso razonable.
- Inventario y dependencia principal
- RPO y RTO que merece la carga
- Migración, backup o recuperación a evaluar