Copias de seguridad y clonación de AIX: mksysb, savevg y actualizaciones de bajo riesgo con alt_disk_copy

Objetivo

Realizar una copia de seguridad restaurable del rootvg de un sistema AIX, confirmar el contenido de una imagen mksysb sin restaurarla, y llevar a cabo una actualización de Technology Level con un respaldo en el mismo sistema en lugar de depender únicamente de una restauración desde cinta.

Requisitos previos

Acceso root; espacio suficiente en el medio de destino (unidad de cinta, archivo en un servidor NIM o disco local) para todo el contenido de rootvg; para alt_disk_copy, un disco adicional sin usar visible para lspv.

Pasos

Copia de seguridad con mksysb

1. Crear la copia de seguridad: mksysb -i /dev/rmt0 (a cinta) o hacia un archivo en un servidor NIM; mksysb respalda todos los datos JFS/JFS2 montados en rootvg, más la información suficiente para reinstalar el sistema operativo base.
2. Si la imagen podría usarse más adelante como base para otra máquina, planear responder «no» a la pregunta de «recuperar dispositivos» durante la restauración, de modo que se (re)descubra el árbol de dispositivos propio del destino en lugar del de la máquina de origen.
3. Para respaldar en cambio un grupo de volúmenes distinto de rootvg, usar savevg -i -f <device-or-file> <vgname>; la imagen no es arrancable y se restaura en un sistema en ejecución con restvg.

Verificar un mksysb sin restaurarlo

4. Ejecutar lsmksysb sobre la imagen para inspeccionarla sin destruirla (por ejemplo lsmksysb -lf <image-file>): puede mostrar la lista de filesets instalados en ese rootvg, equivalente a lslpp -L, y la información de grupos de volúmenes y tamaño equivalente a lsvg, incluido el tamaño que ocuparía la copia si se restaurara con el tamaño mínimo.

Actualización de bajo riesgo con alt_disk_copy

5. Identificar un disco de repuesto con lspv (columna de grupo de volúmenes None). None solo significa que no hay ningún grupo de volúmenes de AIX activo en él: confirmar que no se trata de un dispositivo raw usado por una base de datos, ni de un LUN de SAN compartido con otro LPAR, porque el siguiente paso lo sobrescribe.
6. Clonar el rootvg en ejecución sobre él: alt_disk_copy -BOd hdiskX; -B deja el bootlist actual apuntando al disco original, y -O restablece las entradas ODM específicas del dispositivo en la copia, de modo que no entren en conflicto si alguna vez se traslada a otro hardware.
7. Para combinar la clonación con una actualización en un solo paso, añadir las opciones de actualización a la clonación, por ejemplo alt_disk_copy -d hdiskX -b update_all -l <lpp_source-directory>; el rootvg en ejecución permanece intacto. (alt_disk_mksysb es el comando relacionado que instala una imagen mksysb existente en un disco de repuesto, con -O para restablecer el dispositivo.)
8. Arrancar desde el disco alternativo (mediante bootlist o un dispositivo de arranque seleccionado en la HMC) para probar la copia actualizada; si falla, volver a apuntar el bootlist al disco original intacto (o elegirlo desde el menú de arranque SMS si la copia no arranca), sin necesidad de restauración.

Resultado esperado

Existe una imagen mksysb/savevg verificada fuera del sistema; lsmksysb confirma su contenido de filesets y grupos de volúmenes; una clonación con alt_disk_copy arranca de forma independiente del disco original, lo que da una vía de respaldo el mismo día.

Límites y base de verificación

Esto describe únicamente la duplicación de rootvg; otros grupos de volúmenes de datos necesitan savevg/restvg o un plan propio. Duplicar rootvg mediante una copia de disco bit a bit o trasladando discos físicos entre sistemas no figura entre los métodos admitidos por IBM: con discos conectados directamente, la copia puede no arrancar (LED 554), porque los datos ODM específicos del hardware (códigos de ubicación, WWPN) no coincidirán con el nuevo hardware.