¿Qué es una copia de sistema?
Una copia de sistema (system copy) es el proceso de duplicar un sistema SAP completo creando un clon con todos sus datos, configuraciones y desarrollos. El sistema resultante es funcionalmente idéntico al original pero puede ejecutarse en hardware diferente, con diferente nombre de sistema (SID), y servir propósitos distintos.
Las copias de sistema son una de las operaciones técnicas más complejas que ejecuta SAP BASIS. Involucran la base de datos completa, filesystems de aplicación, ajustes de configuración y coordinación con múltiples equipos para validar que el sistema copiado funciona correctamente.
Casos de uso de copias de sistema
El refresh de QAS es el caso más común. Los entornos de calidad deben refrescarse periódicamente con datos de producción para mantener condiciones de testing realistas. Con el tiempo, los datos en QAS se vuelven obsoletos o se corrompen por pruebas repetidas, necesitando restauración desde producción.
La creación de sistemas de sandbox proporciona entornos aislados para proyectos específicos, pruebas de conceptos, training de equipos o demostraciones. Estos sistemas se crean copiando PRD o QAS y después se desconectan del landscape principal.
Los sistemas de formación (training) se crean para entrenar usuarios sin riesgo de afectar datos productivos. Requieren copia desde producción seguida de anonimización de datos sensibles para cumplir regulaciones de protección de datos.
La preparación de upgrades beneficia de sistemas de prueba creados específicamente para validar el proceso de upgrade antes de ejecutarlo en producción. Se copia PRD a un sistema temporal donde se ensaya el upgrade completo.
Las migraciones de hardware copian sistemas desde servidores antiguos a nuevo hardware como parte de renovación de infraestructura o consolidación de datacenters.
Tipos de copias de sistema
Una copia homogénea mantiene el mismo sistema operativo y la misma base de datos en origen y destino. Por ejemplo, copiar desde Linux/Oracle a Linux/Oracle. Este es el escenario más simple porque no hay conversión de formatos.
Una copia heterogénea cambia el sistema operativo y/o la base de datos. Por ejemplo, migrar desde Windows/SQL Server a Linux/HANA, o desde AIX/DB2 a Linux/Oracle. Requiere conversión de formatos de datos y es significativamente más complejo.
Las copias de mandante duplican solo un mandante específico dentro del mismo sistema o a otro sistema. Es más rápido que copiar el sistema completo pero solo aplica cuando se necesitan datos de un mandante particular.
Las copias de tabla permiten copiar selectivamente tablas específicas entre sistemas. Útil para sincronizar datos maestros específicos sin copiar todo el sistema, aunque requiere cuidado para mantener consistencia referencial.
Planificación de la copia
La planificación comienza definiendo el objetivo: qué sistema se copia, hacia dónde, y con qué propósito. Esto determina el procedimiento específico y los ajustes post-copia necesarios.
El dimensionamiento del sistema destino debe validarse. Si se copia PRD (1TB de datos) a QAS, ¿tiene QAS suficiente almacenamiento? ¿La configuración de memoria y CPU del destino es adecuada para los datos que recibirá?
La ventana de mantenimiento debe programarse considerando cuánto tiempo llevará la copia. Copias grandes pueden requerir 12-24 horas o más. El sistema origen típicamente debe estar detenido o en modo restringido durante el backup inicial.
Las dependencias deben identificarse: conexiones RFC que el sistema destino tiene configuradas hacia otros sistemas, jobs batch que ejecuta, interfaces con aplicaciones externas. Todas estas configuraciones requerirán ajustes post-copia.
La comunicación a stakeholders es crítica. Los usuarios del sistema destino deben saber que perderán sus datos actuales. Los equipos de desarrollo deben saber que transportes pendientes en el sistema destino se perderán y deberán re-importarse.
Proceso de copia homogénea
El proceso estándar para copia homogénea comienza con un backup completo de la base de datos del sistema origen. Este backup debe ser consistente, típicamente tomado con el sistema SAP detenido o en modo backup online si la base de datos lo soporta.
Los filesystems de aplicación SAP también deben respaldarse. Esto incluye /usr/sap con los binarios y perfiles, /sapmnt con archivos compartidos, y el directorio de transportes si no es compartido entre sistemas.
En el sistema destino, si existe una instalación SAP previa, debe desinstalarse completamente: borrar la base de datos antigua, eliminar directorios SAP, limpiar entradas en /etc/services y archivos de configuración del sistema operativo.
La restauración de la base de datos carga el backup del origen en el servidor de base de datos destino. Dependiendo del tamaño, puede llevar varias horas. Durante la restauración deben monitorizarse logs para detectar errores tempranamente.
La restauración de filesystems copia los directorios SAP desde el backup del origen al destino. Esto puede hacerse mediante restore de backup formal o simplemente copiando directorios si ambos sistemas están accesibles simultáneamente.
Uso de SWPM para copias
SWPM (Software Provisioning Manager) tiene escenarios específicos para system copy. Automatiza muchos pasos manuales del proceso y es el método recomendado por SAP para copias homogéneas y heterogéneas.
SWPM guía el proceso paso a paso: detención del sistema origen, backup de base de datos, preparación del destino, restauración, y ejecución de pasos post-copia. Genera logs detallados de cada fase facilitando troubleshooting si surgen problemas.
Para copias homogéneas simples, SWPM puede no ser necesario si BASIS tiene experiencia realizando backups/restores manuales. Sin embargo, para copias heterogéneas o migraciones a HANA, SWPM es prácticamente obligatorio.
Post-copia obligatoria
Inmediatamente tras restaurar la base de datos y filesystems, el sistema destino es un clon exacto del origen, incluyendo su SID. El primer paso post-copia es cambiar el SID del sistema usando herramientas SAP o mediante procedimientos manuales si el cambio de SID no es necesario.
Los perfiles de instancia deben ajustarse para reflejar el nuevo hostname, direcciones IP, y potencialmente diferente configuración de memoria y work processes si el hardware destino difiere del origen.
Las conexiones RFC configuradas en el sistema copiado apuntan a los destinos del sistema origen. Todas estas conexiones deben revisarse mediante SM59 y actualizarse para apuntar a los sistemas correctos desde el contexto del sistema destino.
Los jobs batch programados en el sistema origen se copian también. Muchos de estos jobs no deben ejecutarse en el sistema destino (por ejemplo, jobs de interfaces con sistemas externos que solo deben correr en producción). Deben revisarse mediante SM37 y desactivarse según sea apropiado.
Las impresoras configuradas en el sistema origen probablemente no existen o no son apropiadas en el destino. La configuración de spool debe revisarse y ajustarse para el nuevo entorno.
Los usuarios del sistema origen se copian con sus contraseñas. Por seguridad, las contraseñas de usuarios privilegiados deben cambiarse inmediatamente en el sistema destino, especialmente si se copia desde producción a un entorno menos seguro.
Gestión de transportes post-copia
Uno de los aspectos más complejos post-copia es gestionar los transportes. Si se refresca QAS desde PRD, todos los transportes que estaban importados en QAS pero no en PRD se "pierden" porque QAS ahora contiene exactamente lo que PRD tiene.
Antes de la copia, debe documentarse qué transportes están en QAS pero no en PRD. Estos transportes deben re-importarse tras la copia para que los desarrollos en curso no se pierdan.
La configuración TMS del sistema copiado apunta al landscape del sistema origen. Mediante STMS debe reconfigurar el sistema destino para su rol correcto en el landscape (típicamente QAS) y verificar que las rutas de transporte están correctas.
El directorio de transportes compartido debe apuntar a la ubicación correcta para el sistema destino si es diferente del origen.
Ajustes específicos por sistema
Si se copia PRD a QAS, ciertas configuraciones críticas de producción deben desactivarse en el destino: interfaces con bancos, EDI con partners comerciales, envío automático de emails a clientes externos, y conexiones a sistemas de pago.
Los parámetros de configuración del sistema pueden necesitar ajuste. QAS típicamente tiene menos recursos que PRD, requiriendo reducir número de work processes, ajustar memoria, y modificar configuraciones de performance.
Las licencias SAP son específicas de cada sistema. El sistema destino necesita su propia licencia instalada mediante SLICENSE. La licencia del origen no es válida en el destino porque verifica el hardware key.
Copias heterogéneas y migraciones
Las copias heterogéneas que cambian plataforma de sistema operativo o base de datos son proyectos significativamente más complejos. SAP proporciona herramientas específicas según el tipo de migración.
La migración a SAP HANA es el caso heterogéneo más común actualmente. SAP proporciona Database Migration Option (DMO) de Software Update Manager (SUM) que combina migración de base de datos con upgrade de versión SAP en un solo proceso.
Las migraciones heterogéneas requieren conversión de formatos de datos. Los tipos de datos de Oracle difieren de SQL Server que difieren de HANA. La herramienta de migración maneja estas conversiones pero pueden surgir incompatibilidades que requieren intervención manual.
El tiempo de migración heterogénea es considerablemente mayor que homogénea. Una copia homogénea de 1TB puede llevar 8-12 horas, la misma migración heterogénea puede llevar 24-48 horas o más.
Anonimización de datos
Cuando se copian sistemas productivos a entornos no productivos (especialmente training o desarrollo), regulaciones como GDPR pueden requerir anonimización de datos personales.
La anonimización reemplaza datos sensibles (nombres, direcciones, emails, datos bancarios) con datos ficticios manteniendo la estructura y relaciones. Los registros permanecen para testing pero no identifican personas reales.
SAP proporciona herramientas de anonimización y servicios profesionales para implementar estrategias de anonimización. También existen soluciones de terceros especializadas en este problema.
La anonimización debe ejecutarse inmediatamente tras la copia, antes de dar acceso al sistema a usuarios, para garantizar que datos personales nunca son accesibles en el entorno no productivo.
Validación post-copia
Tras completar todos los ajustes post-copia, debe validarse exhaustivamente que el sistema funciona correctamente. La validación técnica incluye verificar que todas las instancias arrancan, los work processes están activos, la base de datos es accesible y no hay errores críticos en logs.
La validación funcional requiere coordinación con usuarios de negocio. Deben ejecutar transacciones clave para confirmar que los procesos críticos funcionan: crear pedidos de venta, registrar facturas, ejecutar reportes. Esta validación detecta problemas de configuración que la validación técnica podría perder.
Las pruebas de integración verifican que conexiones RFC funcionan correctamente, interfaces con sistemas externos se comportan según esperado (aunque probablemente apuntando a sistemas de test, no producción), y los jobs batch necesarios se ejecutan correctamente.
Troubleshooting de problemas comunes
Los errores de arranque post-copia frecuentemente se deben a configuraciones de red incorrectas (hostname o IP que no resuelven), filesystems montados en rutas incorrectas, o permisos de archivos y directorios incorrectos en el sistema operativo destino.
Los problemas de base de datos pueden incluir tablespaces que no se extendieron correctamente durante restore, archivos de datos en ubicaciones inesperadas, o parámetros de base de datos que referencian el hostname antiguo.
Los errores de conexión RFC son comunes porque las configuraciones copiadas apuntan a sistemas incorrectos. Todas las conexiones RFC deben probarse mediante SM59 y actualizarse según sea necesario.
Los problemas de transportes tras refresh de QAS requieren identificar qué transportes deben re-importarse y en qué orden. La documentación de transportes pre-copia es crítica para resolver estos problemas eficientemente.
Automatización de copias
Las organizaciones que ejecutan copias frecuentemente (por ejemplo, refresh mensual de QAS) se benefician de automatización. Scripts pueden automatizar pasos repetitivos: detención del sistema, backup, restore, y pasos post-copia estándar.
Las herramientas de backup empresariales (Commvault, Veeam, NetBackup) frecuentemente tienen módulos específicos para SAP que simplifican backups y restores de sistemas completos.
La automatización debe incluir validaciones: verificar que el backup completó exitosamente antes de proceder al restore, verificar espacio disponible en destino antes de iniciar restore, y ejecutar smoke tests automáticos post-copia antes de declarar éxito.
Documentación de la copia
Cada copia de sistema debe documentarse exhaustivamente: fecha de ejecución, sistemas origen y destino, versión de base de datos y SAP, tamaño de datos copiados, tiempo total del proceso, y cualquier problema encontrado con su resolución.
La lista de ajustes post-copia específicos de ese sistema debe mantenerse actualizada. Esta checklist acelera futuras copias evitando olvidar pasos críticos.
Los runbooks detallados de procedimiento de copia facilitan que diferentes miembros del equipo BASIS puedan ejecutar copias consistentemente, reduciendo dependencia de individuos específicos.
Consideraciones de licenciamiento
Copiar sistemas productivos a entornos no productivos no requiere licencias SAP adicionales siempre que los sistemas copiados se utilicen exclusivamente para testing, desarrollo o training, no para operaciones de negocio reales.
Sin embargo, las licencias de base de datos pueden tener términos diferentes. Oracle, SQL Server y otras bases de datos tienen políticas específicas sobre uso de copias que deben verificarse con los contratos de licenciamiento.
Temas relacionados
Para profundizar en copias de sistema, consulta:
Instalación de sistemas para la creación de nuevos sistemas desde cero como alternativa a copias.
Transportes SAP para gestionar transportes perdidos tras refresh.
Landscape SAP para entender el contexto de sistemas entre los que se copian datos.
Monitorización para validar el sistema post-copia.
Sistemas y mandantes para copias de mandante específicas.