Backup y Recovery

Estrategias de respaldo, comandos SAV/RST, BRMS, gestion de medios, restore de objetos y planificacion de disaster recovery en IBM i.

Por que importa el backup

IBM i es un sistema extraordinariamente fiable, pero ningun sistema es inmune a fallas de hardware, errores humanos, desastres naturales o ataques. Un backup solido es la ultima linea de defensa contra la perdida de datos.

Linux / x86

•Backups con tar, rsync, Bacula, Veeam
•Base de datos y SO se respaldan por separado
•Snapshots de VM o contenedor
•Restore granular requiere herramientas externas
•Cada servicio tiene su propio backup (pg_dump, mysqldump)
•Recovery suele ser manual y propenso a errores

IBM i

•Backup integrado al SO (SAVLIB, SAVOBJ, SAVSYS)
•Un solo backup cubre SO + BD + aplicaciones
•Save-while-active permite backups sin detener el sistema
•Restore granular nativo (objeto por objeto o biblioteca completa)
•BRMS automatiza toda la gestion de backups
•Recovery guiado con procedimiento estandar

Ventaja clave: En IBM i, los datos, programas, configuracion de seguridad y definiciones de objetos son todos objetos del SO. Un SAVLIB guarda todo junto: tablas, indices, programas, areas de datos, colas de datos y sus autoridades.

Comandos de backup (SAV)

IBM i tiene un conjunto de comandos de backup nativos que cubren desde un objeto individual hasta el sistema completo. Todos empiezan con SAV (save) y escriben los datos a un medio (cinta, save file o disco virtual).

Comandos principales

SAVSYS

Guarda el sistema operativo, objetos del sistema, perfiles de usuario, configuracion de seguridad y datos de configuracion. Requiere estado restringido.

SAVLIB

Guarda una biblioteca completa con todos sus objetos (archivos, programas, areas de datos, etc.). El comando mas usado para backup de aplicaciones.

SAVOBJ

Guarda objetos individuales de una biblioteca. Permite seleccionar por tipo, nombre o fecha de modificacion.

SAVCHGOBJ

Guarda solo los objetos modificados desde la ultima fecha/hora de referencia. Es la base del backup incremental.

SAVSECDTA

Guarda datos de seguridad: perfiles de usuario, listas de autorizacion y configuracion de autoridades.

SAVCFG

Guarda la configuracion del sistema: lineas, controladores, dispositivos, descripciones de red.

SAV

Guarda objetos del IFS (Integrated File System). Usado para archivos en /home, /QOpenSys, /www.

CL — Ejemplos de backup

SAVLIB LIB(MILIB) DEV(*SAVF) SAVF(QGPL/MILIBSAVF)
  Guardar biblioteca MILIB en un save file

SAVLIB LIB(MILIB) DEV(TAP01)
  Guardar biblioteca MILIB en cinta

SAVOBJ OBJ(CLIENTES FACTURAS) LIB(MILIB) DEV(*SAVF)
  OBJTYPE(*FILE) SAVF(QGPL/TABLAS)
  Guardar solo archivos especificos

SAVCHGOBJ OBJ(*ALL) LIB(MILIB) DEV(*SAVF)
  SAVF(QGPL/CAMBIOS) REFDATE('03/01/26')
  Guardar solo lo modificado desde el 1 de marzo

SAVSYS DEV(TAP01)
  Guardar el sistema operativo completo (estado restringido)

SAVSECDTA DEV(*SAVF) SAVF(QGPL/SECDTA)
  Guardar datos de seguridad

SAV DEV('/QSYS.LIB/QGPL.LIB/IFSSAVF.FILE')
  OBJ('/home/fernando/*')
  Guardar archivos del IFS

Estrategias de respaldo

La estrategia de backup depende de los requerimientos de RPO (cuanta perdida de datos es aceptable) y de la ventana de tiempo disponible para el backup.

Backup completo (Full Save)

Guarda todo el sistema. Se hace con el sistema en estado restringido (solo consola activa). Es el backup mas seguro pero requiere detener el servicio.

CL — Full System Save (GO SAVE)

GO SAVE
  Opcion 21 = Sistema completo (SAVSYS + SAVLIB *NONSYS + SAV)
  Opcion 22 = Datos del sistema (SAVSYS + SAVSECDTA + SAVCFG)
  Opcion 23 = Datos de usuario (SAVLIB *ALLUSR + SAV /home)

  La opcion 21 es el backup mas completo. Requiere estado restringido.
  Las opciones 22 y 23 se pueden hacer por separado para reducir
  la ventana de downtime.

Backup incremental

Guarda solo los objetos modificados desde el ultimo backup completo. Reduce drasticamente el tiempo de backup pero el restore es mas complejo.

CL — Backup incremental

SAVCHGOBJ OBJ(*ALL) LIB(MILIB) DEV(*SAVF)
  SAVF(QGPL/INCR0312) REFDATE('03/11/26') REFTIME('230000')
  Guardar objetos modificados desde las 23:00 del 11 de marzo

SAVCHGOBJ OBJ(*ALL) LIB(MILIB) DEV(*SAVF)
  SAVF(QGPL/INCR0312) REFCHGDATE(*SAVLIB)
  Usar como referencia la fecha del ultimo SAVLIB

Esquema tipico semanal

Lun

INCR

Mar

INCR

Mie

INCR

Jue

INCR

Vie

FULL

Sab

—

Dom

FULL+SYS

Lun-Jue: SAVCHGOBJ incremental | Vie: SAVLIB completo | Dom: GO SAVE opcion 21

Save While Active

Save-While-Active (SWA) permite hacer backups sin detener las aplicaciones ni poner el sistema en estado restringido. El sistema toma un checkpoint logico (punto de sincronizacion) y guarda los datos tal como estaban en ese momento, mientras las aplicaciones siguen trabajando.

CL — Save While Active

SAVLIB LIB(MILIB) DEV(*SAVF) SAVF(QGPL/MILIBSWA)
  SAVACT(*LIB) SAVACTMSGQ(QSYSOPR)
  Save-while-active a nivel de biblioteca
  Notifica al operador cuando se alcanza el checkpoint

SAVLIB LIB(MILIB) DEV(*SAVF) SAVF(QGPL/MILIBSWA)
  SAVACT(*SYNCLIB) SAVACTMSGQ(QSYSOPR)
  Save-while-active sincronizado a nivel de biblioteca
  Todos los objetos de la biblioteca se sincronizan al mismo punto

SAVLIB LIB(MILIB OTRALIB) DEV(TAP01)
  SAVACT(*SYSDFN) SAVACTMSGQ(QSYSOPR)
  Save-while-active con sincronizacion definida por el sistema

Niveles de sincronizacion: *LIB sincroniza todos los objetos de una biblioteca. *SYNCLIB asegura consistencia entre objetos dependientes. *SYSDFN deja al sistema decidir el mejor nivel. Para la mayoria de los casos, *LIB es suficiente.

Requisito: Las tablas deben estar bajo journaling para que save-while-active funcione correctamente. Si una tabla no esta journaleada, el sistema puede necesitar bloquearla brevemente durante el checkpoint.

BRMS (Backup Recovery and Media Services)

BRMS es un producto licenciado de IBM (5770-BR1) que automatiza y gestiona todo el proceso de backup. Es como un "Veeam" o "Bacula" integrado al SO, pero mucho mas simple porque ya conoce todos los objetos del sistema.

Que ofrece BRMS

Politicas de backup

Define que se guarda, cuando, y a que medio. Se ejecuta automaticamente segun la politica.

Gestion de medios

Controla cintas y save files. Sabe que datos hay en cada volumen y cuando expiran.

Catalogo de recovery

Mantiene un registro de todos los objetos guardados y en que medio estan. Facilita restores selectivos.

Reporte de recovery

Genera automaticamente el procedimiento de recovery completo paso a paso, personalizado para tu sistema.

CL — Comandos BRMS

WRKPCYBRM *BKU                       Trabajar con politicas de backup
STRBKUBRM CTLGRP(*BKUGRP)           Iniciar backup segun grupo de control
WRKMEDBRM                            Trabajar con medios (cintas)
WRKMLMBRM                            Media Library Manager
STRRCYBRM OPTION(*SYSTEM)            Generar reporte de recovery
WRKOBJBRM                            Ver catalogo de objetos salvados

Gestion de medios

Los datos de backup se pueden guardar en distintos tipos de medios. Cada uno tiene ventajas segun el escenario.

Cinta fisica (TAP01)

Medio tradicional. Alta capacidad (hasta 30TB por cartucho LTO-9). Ideal para offsite y retension a largo plazo. Requiere hardware dedicado.

Cinta virtual (VRTOPT/IMGCLG)

Emula una cinta usando espacio en disco. Los datos se escriben en archivos de imagen que luego se pueden copiar a cinta real o a otro servidor.

Save File (*SAVF)

Objeto del sistema que almacena datos de backup dentro de una biblioteca. Facil de transferir por FTP o copiar entre sistemas. Limitado por espacio en disco.

Cloud Storage

Usando IBM Cloud Storage Solutions for i, se pueden enviar backups a S3, Azure Blob o IBM Cloud Object Storage.

CL — Save files

CRTSAVF FILE(QGPL/MILIBSAVF)        Crear save file
SAVLIB LIB(MILIB) DEV(*SAVF) SAVF(QGPL/MILIBSAVF)  Guardar en SAVF
DSPSAVF SAVF(QGPL/MILIBSAVF)        Ver contenido del save file
CLRSAVF FILE(QGPL/MILIBSAVF)        Limpiar save file para reutilizar

CPYTOSTMF FROMMBR('/QSYS.LIB/QGPL.LIB/MILIBSAVF.FILE')
  TOSTMF('/home/backups/milib.savf')
  Copiar save file al IFS para transferir por FTP/SFTP

SAVSAVFDTA SAVF(QGPL/MILIBSAVF) DEV(TAP01)
  Copiar un save file a cinta

Comandos de restore (RST)

Los comandos de restore son el espejo de los de save. Cada SAV tiene su RST correspondiente. El restore puede ser de una biblioteca completa, objetos individuales, o el sistema entero.

CL — Comandos de restore

RSTLIB SAVLIB(MILIB) DEV(*SAVF) SAVF(QGPL/MILIBSAVF)
  Restaurar biblioteca completa desde save file

RSTLIB SAVLIB(MILIB) DEV(*SAVF) SAVF(QGPL/MILIBSAVF)
  RSTLIB(MILIB_COPY)
  Restaurar a una biblioteca diferente (para comparar)

RSTOBJ OBJ(CLIENTES) SAVLIB(MILIB) DEV(*SAVF)
  SAVF(QGPL/MILIBSAVF) OBJTYPE(*FILE)
  Restaurar un solo objeto

RSTOBJ OBJ(CLIENTES) SAVLIB(MILIB) DEV(*SAVF)
  SAVF(QGPL/MILIBSAVF) OBJTYPE(*FILE)
  RSTLIB(MILIB) MBROPT(*ALL) ALWOBJDIF(*ALL)
  Restaurar forzando diferencias de autoridad

RSTSECDTA DEV(*SAVF) SAVF(QGPL/SECDTA)
  Restaurar datos de seguridad

RSTCFG DEV(TAP01) OBJTYPE(*ALL)
  Restaurar configuracion del sistema

RST DEV('/QSYS.LIB/QGPL.LIB/IFSSAVF.FILE')
  OBJ('/home/fernando/*')
  Restaurar archivos del IFS

Cuidado con RSTLIB: Restaurar una biblioteca reemplaza los objetos existentes. Si necesitas recuperar solo un objeto, usa RSTOBJ para ser selectivo. Siempre verifica el contenido del save con DSPSAVF antes de restaurar.

Restore a biblioteca diferente: El parametro RSTLIB(MILIB_TEST) permite restaurar una biblioteca con otro nombre. Esto es muy util para verificar el backup o comparar datos entre la version actual y la respaldada.

Disaster Recovery

Un plan de disaster recovery (DR) define como restaurar el sistema completo ante una perdida total. La clave es tener documentado y probado el procedimiento antes de que ocurra el desastre.

Componentes de un plan DR

Inventario del sistema

Documentar modelo, version de SO, productos licenciados, PTFs, configuracion de red, IP addresses.

Medios de recovery

Backup completo (GO SAVE opcion 21) almacenado offsite. Incluye cintas de SAVSYS, SAVLIB y SAV.

Procedimiento de restore

Pasos detallados: 1) Instalar LIC, 2) RSTSYS, 3) RSTCFG, 4) RSTSECDTA, 5) RSTLIB de cada biblioteca.

Hardware de contingencia

Servidor alternativo (propio o de un proveedor de DR) con capacidad suficiente para correr la carga.

Pruebas periodicas

Realizar un DR drill al menos 1-2 veces al anio. Documentar tiempos, problemas y correcciones.

Comunicacion

Lista de contactos, proveedores de IBM, numeros de contrato de soporte.

El reporte de recovery de BRMS: Si usas BRMS, el comando STRRCYBRM OPTION(*SYSTEM) genera automaticamente un documento con todos los pasos necesarios para restaurar tu sistema especifico, incluyendo el orden correcto de los medios y los comandos exactos a ejecutar.

Buenas practicas

Verificar los backups

Un backup que no se puede restaurar es inutil. Verificar periodicamente con DSPSAVF y hacer restores de prueba.

Almacenamiento offsite

Al menos una copia de backup debe estar fuera del datacenter fisico. Puede ser en cinta offsite o en cloud.

Documentar el procedimiento

El procedimiento de restore debe estar documentado y accesible fuera del sistema (impreso o en otro servidor).

Regla 3-2-1

3 copias de los datos, en 2 tipos de medio diferentes, con 1 copia offsite. Aplica tambien en IBM i.

Monitorear los backups

Configurar alertas para backups fallidos. Revisar el QHST y los mensajes de QSYSOPR despues de cada backup.

Journaling activo

Mantener journaling activo en todas las tablas criticas. Es prerequisito para save-while-active y alta disponibilidad.

SQL — Monitorear backups via SQL

-- Ver historial de saves de una biblioteca
SELECT SAVE_TIMESTAMP, SAVE_COMMAND, SAVE_DEVICE,
       SAVE_FILE_NAME, SAVE_ACTIVE_OPTION
FROM QSYS2.SAVE_HISTORY
WHERE LIBRARY_NAME = 'MILIB'
ORDER BY SAVE_TIMESTAMP DESC
FETCH FIRST 10 ROWS ONLY;

-- Verificar que todas las bibliotecas criticas tienen backup reciente
SELECT L.SCHEMA_NAME,
       S.SAVE_TIMESTAMP AS ultimo_backup,
       DAYS(CURRENT_DATE) - DAYS(DATE(S.SAVE_TIMESTAMP)) AS dias_sin_backup
FROM QSYS2.SYSSCHEMAS L
LEFT JOIN LATERAL (
  SELECT SAVE_TIMESTAMP FROM QSYS2.SAVE_HISTORY
  WHERE LIBRARY_NAME = L.SCHEMA_NAME
  ORDER BY SAVE_TIMESTAMP DESC
  FETCH FIRST 1 ROW ONLY
) S ON 1=1
WHERE L.SCHEMA_NAME IN ('MILIB', 'PRODLIB', 'APPLIB')
ORDER BY dias_sin_backup DESC NULLS FIRST;

BRMS BR2 — Nueva version en IBM i 7.6

A partir de IBM i 7.6, BRMS 5770-BR1 ya no se entrega. Es reemplazado por BRMS 5770-BR2, disponible como suscripcion. Si usas BRMS, la migracion a BR2 es obligatoria antes de actualizar a 7.6.

Interfaz web moderna

BR2 incluye una interfaz web accesible en http://<sistema>:2088. Permite gestionar backups, medios y monitorear operaciones desde el browser. Tambien incluye un boton SQL que muestra las queries equivalentes para cada tabla.

Soporte MFA

Con MFA habilitado en IBM i 7.6, la pantalla de login de BRMS muestra "Next" en lugar de "Log In". Despues de ingresar usuario y password, se solicita el segundo factor de autenticacion.

Migracion de BR1 a BR2

CL — Pasos de migracion BR1 a BR2

-- 1. Respaldar la biblioteca BRMS
SAVLIB LIB(QUSRBRM) DEV(*SAVF) SAVF(BACKUPLIB/SAVBRMS)

-- 2. Remover los servicios SQL de BRMS
CALL QBRM/Q1AOLD PARM('INSTALL ' 'RMVSQLSERV' 'N' '00')

-- 3. Eliminar el producto BR1
DLTLICPGM LICPGM(5770BR1) OPTION(*ALL)

-- 4. Instalar BR2
RSTLICPGM LICPGM(5770BR2) DEV(OPTVRT01)

-- 5. Aplicar los Group PTFs mas recientes de BRMS

Cambio de autoridad

En 7.6, las operaciones de BRMS con cinta requieren que el usuario tenga tanto *IOSYSCFG como *SAVSYS como autoridades especiales.

Cloud Storage Solutions for i

IBM Cloud Storage Solutions for i (5733-ICC) provee una conexion nativa desde IBM i a almacenamiento cloud via protocolos como S3. Permite guardar archivos y objetos directamente en la nube, integrando con BRMS para backups cloud-based.

Capacidades

Guardar archivos y objetos IBM i directamente en almacenamiento compatible S3
Integracion con BRMS para backups a cloud
Comandos de Cloud Storage Solutions para operar con recursos cloud
API para que aplicaciones accedan al almacenamiento cloud
Version actual: 1.2 (ya no soporta FTPS, migrar a protocolos mas seguros)

Consejo: Cloud Storage Solutions es ideal para implementar la regla 3-2-1 de backup: 3 copias, en 2 tipos de medios diferentes, con 1 copia offsite. La copia offsite puede estar en IBM Cloud Object Storage, AWS S3 u otro provider compatible.

Preparacion para IBM i 7.6

La clave para una instalacion o upgrade exitoso de IBM i 7.6 es la preparacion. Se puede comenzar dias o semanas antes sin requerir downtime.

Requisitos de hardware

Servidor IBM Power con procesador Power10 (firmware FW1060+)
Minimo: 0.05 CPU, 4 GB RAM, 2 adaptadores seriales virtuales
Load source de 35 GB minimo
No soporta Power9 ni anteriores

PTFs requeridos para upgrade

Desde versionPTFs requeridos

IBM i 7.4MF71557, MF70925, MF70909

IBM i 7.5MF71558, MF70806, MF70885

Checklist de preparacion

Verificar que el DST QSECOFR esta habilitado y no tiene password por defecto
Migrar de BRMS BR1 a BR2 si se usa BRMS
Revisar "Memo to Users" para IBM i 7.5 (si se viene de 7.4) y 7.6
Ejecutar CHKPRDOPT para detectar problemas existentes
Revisar Job Schedulers para jobs que deben correr post-upgrade
Ejecutar RCLSTG SELECT(*DBXREF) para rebuild de cross-reference de Db2
Aplicar permanentemente todos los PTFs de 5770-999
Hacer GO SAVE Option 21 (backup completo) inmediatamente antes del upgrade

Tip: Descargar y ejecutar el IBM Pre-Upgrade Verification Tool for IBM i antes del upgrade. Detecta problemas potenciales automaticamente.

Gestion del Sistema Networking en IBM i