Copias y recuperación: integración directa

En tu empresa ya existen ERP, sistemas de facturación y plataformas de pago que no puedes reemplazar. Si la estrategia de backup y recuperación no habla su mismo idioma, el proceso se vuelve una carga y un riesgo. En este artículo verás, paso a paso, cómo enlazar tus copias de seguridad con los sistemas que ya usas, sin romper flujos ni generar sobrecarga.

Con qué se tiene que hablar

Antes de diseñar cualquier política de respaldo, haz un inventario de los componentes críticos que forman tu arquitectura actual:

• ERP y CRM (por ejemplo, SAP Business One, Microsoft Dynamics, Odoo). Estos gestionan datos maestros, transacciones y reportes financieros.
• Bases de datos (PostgreSQL, MySQL, SQL Server). Son el núcleo de la información operativa.
• Plataformas de facturación electrónica que envían comprobantes a SUNAT.
• Sistemas de pagos integrados con Yape, Plin, Niubiz, Izipay.
• Herramientas de monitoreo y gestión de incidencias (Zabbix, Grafana, ServiceNow).

Cada uno de estos elementos expone al menos una API o conector que permite extraer datos de forma programática. La clave está en definir puntos de extracción que se alineen con los ciclos de backup ya establecidos (diario, semanal, mensual). Por ejemplo, si tu ERP genera snapshots cada 24 h, programa la copia de seguridad de la base de datos justo después del cierre de la jornada para evitar bloqueos.

Integra backups donde ya existen APIs y horarios de extracción para evitar duplicidades.

SUNAT y facturación electrónica

Requisitos legales

La SUNAT exige que los comprobantes electrónicos (facturas, boletas, notas de crédito) se almacenen por 5 años y que estén disponibles para una auditoría en cualquier momento. Además, el archivo debe poder ser reconstruido íntegramente a partir del backup.

Qué exige el proceso

1. Retención inalterable: los archivos XML deben quedar en un repositorio que garantice integridad (hash SHA‑256) y que no pueda ser modificado.
2. Acceso rápido: en caso de requerimiento, la información debe estar disponible en menos de 48 horas.
3. Trazabilidad: cada restauración debe quedar registrada con usuario, fecha y motivo.

Errores típicos

• Backup fuera de horario de emisión. Se pierden facturas generadas en la ventana de corte y se rompe la cadena de custodia.
• Almacén sin versionado. No se pueden recuperar versiones previas de un XML que haya sido corregido.
• Falta de pruebas de restauración. Se asume que el backup funciona, pero al intentar recuperar se descubre que el archivo está corrupto.

Cómo conectar: utiliza el endpoint de consulta de comprobantes que la mayoría de los proveedores de facturación electrónica (e‑Fact, Nubefact) ofrecen. Programa una extracción incremental cada 6 h y envía los archivos a tu solución de backup mediante un connector SFTP o una API REST que acepte multipart. Así mantienes la retención requerida sin interferir con el proceso de emisión.

Cobros y bancos

Plataformas de pago locales

• Yape y Plin: apps de transferencia instantánea que exponen webhooks para notificar cada operación.
• Niubiz y Izipay: pasarelas de pago con APIs de conciliación que permiten obtener reportes diarios.

Cómo se conectan de verdad

1. Webhooks: configura la URL de tu middleware para que reciba notificaciones en tiempo real. Cada webhook debe incluir un identificador de transacción que luego puedas cruzar con tu base de datos de ventas.
2. Batch de conciliación: programa una extracción nocturna (por ejemplo, a las 02:00 h) que descargue el reporte de todas las transacciones del día anterior.
3. Persistencia en backup: almacena los logs de webhook y los archivos de conciliación en el mismo bucket donde guardas los respaldos de la base de datos. Usa una estructura de carpetas por fecha (/backups/pagos/2026/10/25/).

Puntos críticos

• Idempotencia: los webhooks pueden llegar duplicados; tu proceso de ingestión debe descartarlos para evitar registros inflados.
• Retención: la normativa peruana requiere conservar los comprobantes de pago por 5 años; planifica la política de ciclo de vida del storage para mover los archivos a cold storage después de 2 años.
• Pruebas de recuperación: al menos una vez al trimestre, restaura un lote de transacciones y verifica que los montos coinciden con los reportes bancarios.

Qué pedirle al proveedor

APIs y documentación

• Especificación OpenAPI/Swagger: facilita la generación de clientes y la validación de contratos.
• Versionado de API: solicita que el proveedor mantenga versiones paralelas (v1, v2) y que comunique cambios con al menos 30 días de antelación.
• Límites de cuota: conoce el número máximo de llamadas por minuto y planifica un buffer en tus scripts de backup para no excederlos.

Cuando la otra parte cambia

1. Webhook de cambios: algunos proveedores emiten un evento cuando actualizan su esquema. Suscríbete a ese webhook para actualizar tu mapeo automáticamente.
2. Entorno de pruebas: exige un sandbox que reproduzca fielmente los endpoints de producción. Ejecuta tus pruebas de integración allí antes de migrar cambios.
3. Contrato de nivel de servicio (SLA): incluye cláusulas que garanticen tiempo de respuesta (< 200 ms) y disponibilidad (> 99.5 %). Si el SLA se incumple, el plan de backup debe poder operar en modo offline durante al menos 48 h.

Checklist rápido para el proveedor

• API documentada con OpenAPI.
• Versionado claro y calendario de deprecación.
• Webhooks de eventos críticos (cobro, factura, error).
• Sandbox disponible y sincronizado.
• SLA que cubra disponibilidad y latencia.

Conclusión

Al alinear tus copias de seguridad y planes de recuperación con los sistemas que ya utilizas —ERP, facturación electrónica y pasarelas de pago— reduces el tiempo de recuperación, cumples con la normativa SUNAT y evitas sorpresas cuando un proveedor modifica su API. Define puntos de extracción claros, usa los conectores nativos (API, webhooks, SFTP) y establece pruebas de restauración periódicas. Con esa disciplina, tu estrategia de backup deja de ser una tarea aislada y pasa a ser una pieza integral del flujo operativo de tu empresa.