Caso · Ecommerce especializado
Continuidad de un ecommerce especializado
De copias sin comprobar a una recuperación documentada para un ecommerce especializado
Resumen
Problema
Para una tienda online, cada hora sin servicio o cada dato perdido es venta perdida. Tener copias no bastaba si nadie había comprobado que se podían restaurar ni cuánto tardaría.
Solución
Una operación de infraestructura con copias automáticas fuera del servidor principal, retención definida y un procedimiento de recuperación escrito.
Resultado observado
Las copias se hacen sin depender de que alguien las lance y la recuperación está documentada, así que no depende de la memoria de una persona.
Cambio observado, sin cifras publicadas. Solo publico métricas con punto de partida, periodo y fuente.
Antes y después
Qué pasos desaparecieron
«Antes» muestra cómo se hacía el trabajo y marca los pasos donde se atascaba o había que revisar a mano. «Después», el recorrido con el sistema en marcha.
Antes
- Copias sin una retención clara
- Restauración nunca comprobada
- Recuperación en la memoria de una persona
Después
- Copia programada de base de datos y archivos
- Guardada fuera del servidor principal
- Retención definida
- Recuperación documentada paso a paso
Piezas del sistema
- Tienda PrestaShop En producción, sin equipo técnico propio
- Copias automáticas y periódicas Base de datos y archivos
- Almacenamiento externo Un fallo del servidor no afecta a las copias
- Procedimiento de recuperación Escrito para que no dependa de una persona
Razonamiento
Cómo se decidió qué construir
-
Situación inicial
Había riesgo de perder pedidos, catálogo o clientes ante un fallo. Las copias no tenían una retención clara y nadie había documentado cómo recuperar la tienda.
-
Restricciones y riesgos
- La tienda no puede estar parada durante mucho tiempo sin perder ventas.
- El coste de almacenamiento de las copias tenía que ser razonable.
- No hay un equipo técnico interno que pueda actuar ante un incidente.
-
Qué se decidió
Copias automáticas y periódicas de base de datos y archivos, guardadas fuera del servidor principal, con una política de retención y un procedimiento de recuperación escrito.
Qué se descartó. Confiar únicamente en las copias del proveedor de alojamiento. No permitían controlar la retención ni garantizaban poder volver a un punto concreto.
-
Proceso y participación
La tienda definió cuánto tiempo sin servicio y cuántos datos podía permitirse perder. Yo me encargué de diseñar las copias, documentar la recuperación y operar la infraestructura.
-
Puesta en marcha
Las copias se pusieron en marcha de forma programada y se documentó paso a paso cómo restaurar la tienda.
-
Resultado
- Copias automáticas con retención definida.
- Procedimiento de recuperación documentado.
- Mantenimiento y operación continuados de la tienda.
Límites. No publico cifras de disponibilidad ni tiempos de recuperación medidos. Conviene probar la restauración de forma periódica y registrar cuánto tarda.
Detalle técnico Consultar arquitectura, integraciones y tecnologías
Por qué una copia no es un plan de recuperación
Una copia de seguridad solo tiene valor si se puede restaurar a tiempo. Las preguntas que importan son cuántos datos se pueden perder como máximo, cuánto tiempo puede estar la tienda sin vender y quién sabe cómo volver a ponerla en marcha.
Arquitectura de copias
- Copias automáticas y periódicas de base de datos y archivos, sin depender de que alguien las lance.
- Retención definida. Cuántas copias se guardan y durante cuánto tiempo, equilibrando coste de almacenamiento y capacidad de volver a un punto anterior.
- Copias fuera del servidor principal, para que un fallo del servidor no afecte también a las copias.
Despliegue y monitorización
- Procedimiento de recuperación escrito para que la restauración no dependa de una persona concreta.
- Revisión de que las copias se completan y actualizaciones de la plataforma.
Quién hizo este trabajo
Servicios relacionados
Guías relacionadas