Respaldo de datos de inventario: plan b para tu cava

Un backup útil se demuestra restaurando

Imagina —como ejercicio, no como caso real— que el inventario digital queda inaccesible después del servicio. Todavía hay botellas en la cava, pero el equipo no puede consultar su identidad, propietario, ubicación o últimos movimientos. ¿Qué versión recuperarías, cuánto perderías y en qué momento volverías a operar con confianza?

Responder “tenemos una copia en la nube” no resuelve esas preguntas. Un respaldo de datos de inventario funciona cuando permite restaurar el conjunto completo y coherente, dentro de los objetivos acordados, en un entorno limpio y con criterios de aceptación verificables.

Esta guía se concentra en la recuperación técnica del inventario de cava. El plan de continuidad del restaurante completo —personas, comunicación, POS, reservas y procedimientos manuales— se desarrolla en backup de datos para restaurantes y contingencia de cava privada.

Inventaría lo que realmente necesitas recuperar

“La base de datos” suele ser solo una parte. Mapea componentes y dependencias:

Componente	Ejemplos	Dependencia de recuperación
Maestros	producto, añada, presentación, ubicación, identificador de botella	permiten interpretar movimientos y existencias
Estado actual	existencia, ubicación y estatus conocido	debe reconciliarse con el historial
Movimientos	recepción, asignación, traslado, servicio, ajuste y baja	orden, integridad y vínculos son críticos
Evidencia	fotografías, documentos y adjuntos	suele vivir en almacenamiento de objetos separado
Auditoría	conteos, discrepancias, aprobaciones y bitácora	requiere relación con registros y usuarios
Membresías	estado y relación autorizada con inventario	puede contener datos personales
Configuración	catálogos, unidades, permisos, reglas y mapeos	sin ella los datos pueden abrir pero no operar igual
Integraciones	IDs externos, checkpoints y colas pendientes	evita duplicar al reconectar POS u otros sistemas
Esquema y versión	migraciones, aplicación y dependencias	una copia nueva puede no abrir con software viejo
Claves	cifrado, secretos y credenciales de recuperación	deben protegerse y recuperarse por una ruta separada

Un CSV de botellas puede servir para consulta de emergencia o portabilidad. No conserva necesariamente relaciones, fotografías, historial, permisos, estados de procesamiento ni configuración. Trátalo como un artefacto adicional, no como respaldo completo.

Documenta también qué no se respaldará y cómo se reconstruye. Un componente omitido por decisión es diferente de uno olvidado.

RPO y RTO: cuánto dato y cuánto tiempo puedes perder

NIST define el Recovery Point Objective (RPO) como el punto en el tiempo al que los datos deben recuperarse después de una interrupción. En términos operativos, establece la pérdida de cambios que el restaurante tolera.

El Recovery Time Objective (RTO) es la duración dentro de la que debe restaurarse un proceso después de una disrupción para evitar consecuencias inaceptables. No es una promesa automática del proveedor: es un objetivo que necesita arquitectura, personal y pruebas.

Matriz por capacidad

Capacidad	Impacto si falta	RPO a decidir	RTO a decidir	Modo temporal
identificar botella y titular autorizado	riesgo de entrega incorrecta	según volumen de cambios	antes de reanudar entregas	detener salida o verificar con control alterno
registrar movimientos	pérdida de trazabilidad interna	según movimientos por turno	dentro de la ventana operativa	bitácora manual numerada
consultar fotografías	menor contexto de evidencia	puede diferir del transaccional	puede restaurarse en segunda fase	conservar referencias pendientes
ejecutar auditoría	retrasa control, no siempre servicio	según calendario	según siguiente conteo	posponer con autorización
generar análisis	no bloquea el movimiento inmediato	puede aceptar mayor antigüedad	después del núcleo operativo	suspender reportes

No asignes frecuencias “diaria, semanal y mensual” por costumbre. Si se registran cien movimientos entre copias y el RPO admite diez, el diseño falla. Si las fotos son evidencia necesaria en cada recepción, respaldarlas al final del mes tampoco funciona.

Mide la capacidad de restauración real, no el tiempo ideal escrito en una política. El RTO incluye localizar credenciales, provisionar entorno, descargar, descifrar, migrar, validar y autorizar la reapertura.

Diseña para distintos fallos

Un único backup no cubre todos los escenarios:

• borrado accidental: necesitas versiones anteriores y protección contra propagación;
• corrupción silenciosa: necesitas retención suficiente, validación y más de un punto;
• ransomware: necesitas copias inaccesibles para la cuenta comprometida;
• credenciales robadas: necesitas separación de identidades y controles de eliminación;
• falla de región o proveedor: necesitas copia y procedimiento fuera del mismo dominio de fallo;
• error de despliegue o migración: necesitas punto consistente antes del cambio y compatibilidad probada;
• pérdida de dispositivo: necesitas cifrado y recuperación de identidad;
• salida del proveedor: necesitas exportación completa, documentación de esquema y plazo de transición;
• eliminación legítima: necesitas que restaurar no reactive datos que debían permanecer eliminados.

La nube reduce algunos riesgos físicos, pero introduce configuración, cuentas, claves y dependencia del servicio. “Está en la nube” describe una ubicación, no una estrategia.

Backup, snapshot, réplica, sync y exportación

Mecanismo	Qué aporta	Qué no debes asumir
Backup versionado	copia separada para recuperar un punto anterior	que sea consistente o restaurable sin prueba
Snapshot	estado de un volumen o servicio en un momento	independencia de cuenta, región o corrupción lógica
Réplica	disponibilidad y continuidad ante cierta falla	protección contra borrado o corrupción replicados
Sincronización	disponibilidad de archivos en varios dispositivos	historial completo ni aislamiento de ransomware
Exportación CSV/JSON	portabilidad o consulta parcial	esquema, relaciones, adjuntos, permisos y bitácora
Imagen de sistema	entorno y software para reconstruir más rápido	actualidad de datos transaccionales

La sincronización replica altas, cambios y eliminaciones. Puede ser útil, pero el mismo comportamiento propaga un borrado o archivos cifrados. CISA advierte que backups automáticos en nube pueden no bastar si los archivos locales cifrados se sincronizan y sustituyen versiones sanas.

El servidor activo tampoco cuenta como segunda copia. Una réplica accesible con las mismas credenciales comparte gran parte del riesgo.

3-2-1-1-0 como principio, no garantía

Una extensión común de la regla 3-2-1 propone:

• 3 copias, incluida la de producción;
• 2 tipos de medio o dominios de fallo;
• 1 copia fuera del sitio principal;
• 1 copia offline, aislada o con inmutabilidad correctamente configurada;
• 0 errores detectados en verificación y restauración.

Es una ayuda de diseño, no una certificación ni la garantía de que ningún incidente alcanzará todas las copias. Dos servicios bajo la misma cuenta administrativa pueden fallar juntos. Un almacenamiento “inmutable” mal configurado puede ser eliminable, costoso o incompatible con obligaciones de eliminación.

CISA recomienda copias offline y cifradas de datos críticos y pruebas periódicas de disponibilidad e integridad en un escenario de recuperación. Ajusta la topología al análisis de amenazas y RPO/RTO del restaurante.

Crea copias consistentes

Copiar archivos de una base activa mientras cambian puede producir piezas de momentos distintos. Usa el mecanismo soportado por el motor o proveedor: snapshot consistente, dump transaccional, réplica detenida de forma controlada u otra estrategia documentada.

Para base de datos y fotografías separadas:

1. define un punto de corte;
2. registra versión de esquema y aplicación;
3. captura la base con consistencia transaccional;
4. genera un manifiesto de objetos esperado;
5. copia fotografías y adjuntos con sus metadatos;
6. guarda configuración y mapeos compatibles;
7. calcula checksums o controles de integridad;
8. firma o protege el manifiesto según el riesgo;
9. registra inicio, fin, tamaño, resultado y errores;
10. evita marcar éxito si falta un componente.

Una tarea que terminó con código exitoso no demuestra que todas las fotografías existan o que la base pueda abrir. La verificación técnica precede a la prueba de negocio.

Cifrado, credenciales y acceso

Cifra la copia en tránsito y reposo. Separa las claves de cifrado del medio respaldado; si ambas se pierden juntas, la copia es inútil. Si la misma cuenta comprometida puede leer producción, borrar backups y eliminar claves, el aislamiento es solo aparente.

Aplica:

• identidades distintas para crear, leer y eliminar copias cuando la plataforma lo permita;
• mínimo privilegio;
• autenticación multifactor para administración;
• aprobación adicional o demora para borrado masivo;
• alertas ante desactivación, fallo o cambio de retención;
• credenciales de emergencia guardadas y probadas;
• rotación con procedimiento que no inutilice históricos;
• registro de accesos y restauraciones.

No dejes un disco de respaldo conectado permanentemente al equipo que protege si el objetivo es aislamiento. Documenta custodia física, traslado, cifrado y destrucción al retirarlo.

Retención y datos personales

Más versiones ayudan contra corrupción tardía, pero aumentan costo, superficie de exposición y dificultad para eliminar datos. Diseña una política por tipo de copia y finalidad, no “guardar todo para siempre”.

Si membresías, fotografías, bitácoras o cuentas contienen datos personales, el restaurante debe considerar la LFPDPPP vigente: finalidades, seguridad, acceso, conservación y atención de derechos. El plan debe explicar cómo una baja o rectificación se conserva en un registro de control para no “resucitar” información al restaurar una copia antigua.

Documenta:

• retención operativa y cualquier obligación aplicable;
• bloqueo legal o contractual, si existe y está justificado;
• destrucción de medios y copias vencidas;
• procedimiento posterior a restauración para reaplicar eliminaciones y cambios;
• tratamiento de copias del proveedor al terminar el contrato.

Runbook de recuperación

Un runbook debe poder seguirlo una persona autorizada que no diseñó el sistema. Incluye contactos, dependencias, comandos o interfaz, decisiones y criterios de salida, sin exponer secretos dentro del mismo documento.

1. Declarar e aislar

Clasifica el incidente, detén escrituras cuando sea necesario y evita contaminar copias. Ante sospecha de intrusión, coordina con el plan de respuesta: restaurar encima de un entorno comprometido puede repetir el daño. Conserva evidencia según el protocolo.

2. Elegir punto sano

Compara hora del incidente, última verificación, antigüedad y posibilidad de corrupción silenciosa. El backup más reciente no siempre es el correcto. Calcula la brecha respecto del RPO.

3. Preparar entorno limpio

Provisiona infraestructura, versión de aplicación, esquema y secretos por rutas autorizadas. Mantén integraciones de salida desactivadas para que la prueba no envíe mensajes, duplique movimientos ni sobrescriba sistemas externos.

4. Restaurar en orden

Restaura maestros y configuración necesarios, base transaccional, objetos y fotografías, auditoría e índices derivados. Reconstruye cachés o búsquedas a partir de la fuente, no al revés.

5. Validar

Ejecuta checksums, conteos, integridad referencial, permisos y pruebas de negocio. Documenta pérdidas conocidas y excepciones.

6. Reconciliar la interrupción

Incorpora la bitácora manual con identificadores únicos y aprobación. No asignes timestamps falsos: registra cuándo ocurrió el evento y cuándo se capturó después. Evita duplicar operaciones que sí alcanzaron producción antes del fallo.

7. Reabrir por etapas

Autoriza primero consulta, después captura controlada y al final integraciones. Monitorea errores, conserva la evidencia del ejercicio y programa acciones correctivas.

Criterios de aceptación de una restauración

Integridad técnica

• la copia, manifiesto y checksums pasan;
• esquema y aplicación son compatibles;
• no faltan tablas, particiones, objetos ni índices esenciales;
• claves y secretos se recuperan sin exponerlos;
• las relaciones entre base y fotografías resuelven;
• los permisos restaurados siguen mínimo privilegio;
• integraciones permanecen bloqueadas hasta aprobación.

Integridad de negocio

• existencia inicial + movimientos válidos coincide con el estado calculado;
• una muestra de botellas puede localizarse por su identificador;
• fotografías y auditorías abren desde el registro correcto;
• transferencias conservan origen, destino y estado;
• no hay movimientos duplicados por reintento;
• una muestra física se reconcilia o deja diferencias explicadas;
• los cambios posteriores al punto recuperado están identificados.

RPO y RTO

• se registra el punto recuperado y la brecha real;
• se mide el tiempo desde declaración hasta servicio autorizado;
• se comparan resultados contra objetivos;
• cualquier incumplimiento genera una acción con responsable y fecha.

“Restauró en otra computadora” no basta si las fotos no aparecen, las relaciones están rotas o todos los usuarios recuperan permisos administrativos.

Ejercicios proporcionales

No impongas una periodicidad universal. Deriva la frecuencia del cambio del sistema, el riesgo y los objetivos. Combina:

• revisión de mesa: el equipo recorre decisiones y contactos;
• restauración de componente: recupera una base, objeto o versión eliminada;
• restauración aislada completa: reconstruye el servicio sin afectar producción;
• ejercicio de continuidad: opera temporalmente y reconcilia la bitácora;
• prueba de salida: recupera datos y documentación sin depender del proveedor actual.

Prueba después de cambios relevantes de esquema, proveedor, cifrado o personal, no solo por calendario. Guarda evidencia: copia usada, duración, errores, criterios, resultado y correcciones.

Preguntas al proveedor

• ¿Qué componentes exactos cubre el backup?
• ¿Cuál es el RPO/RTO contractual, si existe, y qué queda fuera?
• ¿Las copias usan otra cuenta, región o dominio de fallo?
• ¿Existe aislamiento, inmutabilidad y protección de borrado?
• ¿Cómo se cifran y administran claves?
• ¿Qué retención está incluida y cómo se elimina?
• ¿Quién puede solicitar o ejecutar una restauración?
• ¿Cómo se prueba integridad y cuándo fue el último ejercicio?
• ¿Qué ocurre con datos personales al restaurar?
• ¿Cómo obtengo base, fotografías, historial, configuración y esquema al salir?
• ¿Qué responsabilidades conserva el restaurante?
• ¿Qué sucede si el proveedor completo no está disponible?

No asumas que Kavasoft incluye una frecuencia, retención o restauración determinada. Confirma el alcance para restaurantes y revisa contrato, plan, exportaciones y procedimiento de soporte. Kavasoft es una plataforma; el restaurante conserva la custodia física de las botellas y su propio plan de continuidad.

Fuentes y lecturas recomendadas

• NIST: Recovery Point Objective, definición oficial del punto temporal al que deben recuperarse los datos.
• NIST: Recovery Time Objective, definición oficial del tiempo requerido para recuperar un proceso después de una disrupción.
• NIST Cybersecurity Framework 2.0, marco oficial para gobernar, identificar, proteger, detectar, responder y recuperar.
• CISA: StopRansomware Guide, recomendaciones sobre backups offline, cifrado, pruebas, integridad y recuperación ante ransomware.
• Cámara de Diputados: LFPDPPP vigente, referencia para seguridad, conservación y derechos relativos a datos personales en México.

Contenido relacionado

• Backup de datos para restaurantes
• Contingencia de cava privada: operación cuando falla el sistema
• Conciliación de auditoría de inventario
• Trazabilidad de botellas de vino