⚙️ Técnico

Copia de seguridad: RPO, RTO y prueba de restauración

Una copia que nadie ha restaurado no es una copia. Es una suposición: hay un archivo, alguien lo subirá y la tienda volverá. Mientras no lo compruebe en un entorno aparte, con el reloj, no lo sabe. Lo habitual es que la copia esté incompleta, o completa pero de hace dos semanas, o reciente pero en el servidor que acaba de caer.

9 min de lectura

Este texto le enseña dos cifras: RPO y RTO. Una vez fijadas, hablar de copias deja de ser técnico y pasa a ser una conversación sobre pedidos. Restaurar es una decisión de negocio, pagada en pedidos que después no estarán.

Por qué la copia es más difícil en una tienda que en una web corriente

Una web corporativa cambia cada varias semanas. La copia de ayer es casi idéntica a producción y restaurarla no cuesta nada. En una tienda los datos cambian cada minuto, y ahí está la diferencia.

Imagine que restaura una copia de hace 24 horas. Junto con la tienda devuelve la base de datos: pedidos del último día, estados de pago, stock, cuentas nuevas, códigos de descuento ya usados, devoluciones y reclamaciones. Los pedidos desaparecen, el dinero se queda. El cliente tiene el justificante de la pasarela y en su tienda ese pedido no existe. El proveedor ve la transacción, el almacén no ve nada y tres días después el cliente pregunta por su paquete.

Ese es el fondo del asunto: restaurar no es volver a la normalidad, es cambiar un problema por otro, más barato o más caro. Antes de hablar de frecuencia, sepa cuánto cuesta ese segundo problema.

RPO y RTO explicados en lenguaje llano

El RPO (Recovery Point Objective, la pérdida de datos máxima asumible) responde a esto: qué antigüedad puede tener la copia más reciente cuando llega la avería. Si la copia se hace a las tres de la madrugada y la avería llega a las seis de la tarde, su RPO real es de quince horas de pedidos que recomponer a mano.

El RTO (Recovery Time Objective, el tiempo máximo fuera de servicio) responde a la otra: cuánto puede estar offline, desde la avería hasta que la tienda acepta pedidos. No es tiempo de copiar archivos: es diagnóstico, decisión, restauración, verificación y conmutación del tráfico.

Ambas cifras salen de un dato que ya tiene: pedidos por hora. Tome los últimos 30 días y divida entre las horas en que vende. Una tienda con 200 pedidos diarios de 8 a 22 hace unos 14 por hora. Con un carrito medio de 40 EUR, cada hora revertida son unos 550 EUR y 14 pedidos que reescribir. Con un RPO de 24 horas, 336 pedidos, y nadie los reescribe en un día.

Ahora dele la vuelta. Si su equipo puede gestionar 20 pedidos recuperados de la pasarela y el correo, su RPO debería rondar la hora, no el día. Si su pico cae en noviembre, calcule con noviembre, no con julio. El RPO y el RTO no son constantes, y lo honesto es tener dos valores: el habitual y el de temporada.

Qué debe incluir la copia, porque los archivos solos no sirven

El error habitual es copiar el directorio de la tienda y darlo por cerrado. Una copia completa tiene cinco elementos:

  • la base de datos: pedidos, clientes, productos, precios, configuración de módulos,
  • los archivos: plantilla, módulos y extensiones, librerías, imágenes de producto y adjuntos,
  • la configuración del servidor y servicios: versión de PHP, reglas de reescritura, cron, colas, certificado, caché y buscador,
  • claves y variables de entorno: credenciales de base de datos, sales y claves de cifrado, tokens de API,
  • la documentación de todo lo que no está en la tienda.

Ese último punto se suele saltar y puede alargar la restauración varias horas. Son ajustes de servicios externos: configuración de la pasarela y direcciones de notificación de retorno, integración con almacén o ERP, transportistas y puntos de recogida, cuentas en comparadores, píxeles y etiquetas de marketing, registros DNS. Nada de eso está en la base de datos y ninguna copia del hosting lo incluye. Basta un documento con los servicios, los paneles y quién tiene acceso.

En WooCommerce se añade algo: si la tienda usa HPOS, la forma nueva de guardar pedidos, la copia debe ser coherente con las versiones de las extensiones, porque una restauración parcial descuadra las tablas de pedidos. En PrestaShop el problema frecuente son los módulos de pago y sus licencias, que a veces hay que activar a mano tras la migración.

La regla 3-2-1 en versión tienda

La regla es sencilla: tres copias, en dos soportes o dos ubicaciones distintas, y una fuera de la infraestructura del proveedor de hosting.

El tercer punto genera discusión. Una copia en un directorio al lado de la tienda, en el mismo servidor y cuenta, le protege de un único escenario: su propio error en contenido o configuración. No le protege de un fallo de disco, del bloqueo de la cuenta, de un servidor eliminado, de un error del proveedor ni de perder el panel. Si el incendio afecta a todo el edificio, la copia de al lado arde con el original.

Por el mismo motivo, una copia accesible desde la misma cuenta puede cifrarse con la tienda en un ataque de ransomware: al menos una debería ser inmutable o estar fuera de esa cuenta, con autenticación propia.

La prueba de restauración, única diferencia entre una copia y una suposición

La prueba de restauración es lo único que convierte la suposición en hecho:

  1. Restaura la copia en un entorno aparte, nunca en producción.
  2. Comprueba si la tienda arranca: portada, categoría, ficha de producto, acceso al panel.
  3. Recorre la ruta de compra hasta la confirmación, con pago en modo de pruebas.
  4. Compara cifras: pedidos, productos, clientes, y si el último pedido cuadra con la copia.
  5. Mide el tiempo hasta que la tienda podría recibir tráfico. Esa cifra es su RTO real, no el de una oferta.

Si la prueba sale peor de lo previsto, tiene dos caminos: acortar el RPO (copias más frecuentes) o el RTO (entorno de respaldo y procedimiento escrito). Ambos cuestan, pero ya conoce el precio de la alternativa.

En nuestro caso las copias se hacen cada 7 días en el paquete básico y la prueba una vez por trimestre, anotando resultado y tiempo. Si su RPO baja de un día, el básico no basta, y lo decimos antes de firmar.

Cuándo no restaurar la copia

Ante una avería el reflejo es el mismo: restaurar y quedarse tranquilo. Suele ser equivocado. El orden debería invertirse: primero diagnóstico, después decisión.

Haga el cálculo. La avería dura tres horas y la copia más reciente también. Restaurar devuelve la tienda sin los pedidos de esas horas: a 14 por hora, 42 registros que reescribir desde la pasarela y el correo, con sus stocks. Si afecta a un solo módulo, ese precio es absurdo.

Alternativas que conviene valorar antes:

  • reparación in situ: desactivar el módulo defectuoso, revertir una actualización, corregir la configuración,
  • restaurar solo los archivos, sin base de datos: funciona cuando el problema está en el código y los datos intactos, y no cuesta ni un pedido,
  • modo mantenimiento con información clara, pedidos por teléfono y correo, reparación en segundo plano sin presión.

Restauramos la copia cuando los datos están dañados o cuando diagnosticar cuesta más que las horas perdidas. Esa decisión la toma la propiedad de la tienda, no la persona técnica, porque sabe cuánto valen esos 42 pedidos.

Lista de control para su proveedor actual

Envíe estas preguntas a quien mantiene su tienda y pida respuesta escrita:

  1. ¿Cada cuánto se hace la copia y a qué hora?
  2. ¿Dónde está físicamente y es una infraestructura distinta de la tienda?
  3. ¿Cuánto se conserva y cuántas versiones anteriores tengo?
  4. ¿Quién tiene acceso y puedo acceder yo sin intermediarios?
  5. ¿Cuándo se restauró por última vez, en qué entorno y cuánto tardó?
  6. ¿Incluye la base de datos o solo los archivos?
  7. ¿Es una copia del hosting y, si lo es, de quién es y me la entregarán al terminar?
  8. ¿Recoge el contrato la devolución o el borrado de los datos al finalizar?

No obtener respuesta a la pregunta cinco es la señal más importante. La séptima incomoda: la copia del hosting es del hosting, se hace en sus condiciones y no siempre está disponible en un formato aprovechable.

Qué incluye nuestro servicio y qué se paga aparte

Las copias y la prueba trimestral forman parte de la supervisión de disponibilidad, desde 210 EUR netos al mes en el nivel Estándar. El servicio incluye la comprobación de la tienda cada 60 segundos, la verificación humana de la alerta en 15 minutos y una nota tras el incidente.

La restauración fuera de la ventana del servicio se factura según tarifas de intervención: laborables de 8 a 18, 35 EUR por hora; tardes y sábados, 52 EUR; domingos y festivos, 70 EUR. Lo decimos abiertamente: es la partida que más sorprende, y la diferencia entre una restauración nocturna y una diurna es un argumento más para fijar antes el RPO y el RTO, con calma.

Solicite una revisión de las copias de seguridad de su tienda. Comprobaremos qué se copia, restauraremos una copia en un entorno aparte, mediremos cuánto tarda y fijaremos su RPO y RTO. Detalles y formulario: /es/sla-help-desk.

Etiquetas: #kopie zapasowe #RPO #RTO #plan awaryjny #WooCommerce #PrestaShop
Compartir: 𝕏 in f

Mantente al día

Nuevos artículos sobre e-commerce y skalowaniu

Una vez a la semana, los viernes. Sin spam, sin relleno. Solo conocimiento práctico de personas que han migrado tiendas con más de 10M PLN de GMV al año.

🔒 Conforme al RGPD. Cancela la suscripción con 1 clic en el pie de cada correo.