InforSupports

Etiqueta: linux

  • Recuperar datos de un backup .vma dividido en partes (Proxmox 8/9)

    Se tiene un respaldo de una máquina virtual de Proxmox dividido en 14 partes de exactamente 20 GB cada una (a excepción de la última, que pesa poco más de 11 GB). El peso total combinado es de aproximadamente 291.8 GB.

    Limitaciones identificadas

    • No se puede montar como un ISO: los respaldos de Proxmox usan un formato empaquetado propietario llamado .vma que Linux no entiende nativamente con el comando mount. Además, la imagen contiene una tabla de particiones interna completa, no un sistema de archivos plano.
    • Espacio en disco: para procesarlo de forma manual en una PC externa, se requiere al menos el doble de espacio (~292 GB extra para la unión, y otros ~292 GB si se extrae el disco virtual completo).

    ¿Qué es realmente un archivo .vma?

    .vma (Virtual Machine Archive) es el formato de contenedor que usa vzdump, la herramienta de respaldo nativa de Proxmox, para empaquetar en un solo archivo: la configuración de la VM (qemu-server.conf), y el contenido crudo de cada disco virtual asociado. No es un sistema de archivos por sí mismo — es un contenedor que hay que extraer primero con la herramienta vma para llegar al disco virtual real (típicamente un .raw), que ya sí contiene una tabla de particiones montable.

    Paso 1: unir las partes secuenciales

    Como los archivos terminan en sufijos alfabéticos ordenados (.part-aa hasta .part-an), se utiliza el comodín de Bash para unirlos en el orden correcto dentro de un solo contenedor comprimido:

    cat vzdump109.part-* > vzdump109.vma.zst

    Paso 2: extraer y montar el contenido

    Escenario A — Si estás en un Linux externo (sin Proxmox)

    Para este método necesitas instalar herramientas de descompresión y utilidades para interactuar con sistemas de archivos virtuales (guestfs-tools):

    # 1. Descomprimir el contenedor VMA de Proxmox
unzstd vzdump109.vma.zst

# 2. Extraer el disco virtual interno a una carpeta de destino
vma extract vzdump109.vma ./carpeta_destino

# 3. Montar de forma segura (solo lectura) la partición interna del disco virtual
mkdir /mnt/disco_vm
guestmount -a ./carpeta_destino/disk-drive-scsi0.raw -m /dev/sda1 --ro /mnt/disco_vm

    Una vez hecho esto, los archivos de la VM quedan accesibles directamente en la ruta /mnt/disco_vm.

    Escenario B — Si tienes acceso a un servidor Proxmox funcional (método rápido)

    Si dispones de un nodo Proxmox funcional, la vía óptima evita el duplicado de almacenamiento en comandos manuales:

    1. Mueve el archivo final vzdump109.vma.zst al directorio de dumps del servidor (usualmente /var/lib/vz/dump/).
    2. Desde la interfaz web de Proxmox, restaura la VM asignándole un ID genérico que no esté en uso (ej. 999). No enciendas la máquina virtual.
    3. Accede por la terminal SSH de Proxmox y monta directamente el volumen lógico o archivo de disco asignado a esa VM para extraer la información de manera local, sin necesidad de ocupar espacio extra extrayendo archivos .raw.

    También se puede hacer el mismo proceso por línea de comandos, sin pasar por la interfaz web, usando qmrestore directamente:

    qmrestore /var/lib/vz/dump/vzdump109.vma.zst 999

    ¿Esto aplica igual en Proxmox 9?

    Sí — Proxmox VE 9 mantiene el mismo formato .vma y las mismas herramientas (vma, qmrestore, guestmount) sin cambios en el procedimiento descrito arriba. La documentación oficial de vzdump y qmrestore para la versión actual sigue usando exactamente esta sintaxis.

    Hay un caso puntual a tener en cuenta si el respaldo fue creado en un host Proxmox 8.x y se intenta restaurar directamente en un host 9.x: hay reportes en el foro oficial de un error wrong vma extent header checksum durante la restauración cruzada entre versiones. El workaround confirmado es hacer el proceso en dos etapas:

    1. Descomprimir el archivo .vma.gz o .vma.zst a un .vma plano en el host 8.x (donde la restauración funciona sin problema):
    gunzip -c /path/to/backup/vzdump-qemu-VMID-DATE.vma.gz > /mnt/pve/NFS/temp_restore/vzdump-qemu-VMID-DATE.vma
    1. Mover ese .vma ya descomprimido al host 9.x y restaurarlo desde ahí con qmrestore, evitando que el 9.x tenga que descomprimir el archivo original.

    Si el respaldo y la restauración se hacen ambos dentro de la misma versión (8.x con 8.x, o 9.x con 9.x), no hay ningún problema de compatibilidad — el procedimiento de este artículo aplica sin modificaciones.

    Notas finales

    • El Escenario B (con un Proxmox funcional disponible) siempre es preferible: evita duplicar 292+ GB de espacio en disco de forma innecesaria.
    • Nunca enciendas la VM restaurada con un ID temporal si el único objetivo es extraer archivos — así evitas conflictos de red (IP/MAC duplicada) con la VM original si esta sigue existiendo en otro lugar.
    • guestmount siempre debe usarse con --ro (solo lectura) al inspeccionar un disco extraído manualmente, para no arriesgar corromper el sistema de archivos interno por error.

  • Dominando systemd: servicios, logs y herramientas ctl

    Systemd es el sistema de inicialización y gestor de servicios usado por la mayoría de distribuciones Linux modernas (Debian, Ubuntu, Fedora, RHEL, Arch). Además de arrancar el sistema, systemd centraliza el control de casi todos los aspectos de administración a través de un conjunto de herramientas con el sufijo ctl («control»):

    • Servicios (.service) — procesos que corren en segundo plano.
    • Timers (.timer) — el reemplazo moderno de cron.
    • Sockets (.socket) — activación de servicios bajo demanda al recibir conexiones.
    • Targets — agrupaciones de unidades, equivalentes a los «runlevels» de SysV.
    • Logs (journal) — el sistema centralizado de registro de eventos.
    • Sesiones (loginctl) — gestión de sesiones de usuario.
    • Fecha/hora (timedatectl), hostname (hostnamectl), locales (localectl), red (networkctl) y DNS (resolvectl).
    • Bootloader (bootctl) y contenedores (machinectl, systemd-nspawn).

    Crear servicios systemd

    Estructura de un servicio

    Un servicio personalizado se define en un archivo .service, típicamente dentro de /etc/systemd/system/:

    [Unit]
Description=Mi servicio de ejemplo
Documentation=https://example.com/docs
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=usuario
Group=usuario
WorkingDirectory=/opt/app
ExecStart=/usr/bin/python3 /opt/app/app.py
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5
Environment="ENV=produccion"
EnvironmentFile=/etc/default/app

[Install]
WantedBy=multi-user.target

    Cada sección cumple un propósito distinto:

    • [Unit] — metadatos y dependencias. After controla el orden de arranque (espera a que ocurra el evento indicado), mientras Wants expresa una dependencia flexible: si la red no está disponible, el servicio arranca igual, solo que después.
    • [Service] — cómo se ejecuta el proceso. Type=simple asume que el proceso principal no hace fork; ExecStart es el comando real; Restart=on-failure hace que systemd reinicie el servicio automáticamente si termina con un código de error (no en un cierre limpio); RestartSec es la pausa antes de reintentar.
    • [Install] — define en qué target se activa el servicio al hacer enable. multi-user.target es el equivalente al runlevel 3 clásico (sistema multiusuario, sin entorno gráfico).

    Procedimiento universal

    Flujo estándar para crear, activar y verificar cualquier servicio nuevo:

    sudo nano /etc/systemd/system/mi-servicio.service
sudo systemctl daemon-reload
sudo systemctl start mi-servicio
systemctl status mi-servicio
sudo systemctl enable mi-servicio

    daemon-reload es el paso que más se olvida: systemd cachea las definiciones de las unidades en memoria, así que cualquier cambio al archivo .service no se aplica hasta ejecutar este comando. enable crea el enlace simbólico que hace que el servicio arranque automáticamente en el próximo boot — start solo lo arranca ahora, una vez.

    Logs con journalctl

    El journal es el sistema de logs binario centralizado de systemd — reemplaza (o complementa) a los archivos de texto tradicionales en /var/log/.

    journalctl -u mi-servicio       # logs de un servicio específico
journalctl -u mi-servicio -f    # seguimiento en vivo (equivalente a tail -f)
journalctl -u mi-servicio -p err # solo mensajes de nivel error o más grave
journalctl -u mi-servicio -b    # logs desde el arranque actual del sistema
journalctl -xe                  # últimas líneas con contexto extendido, útil tras un fallo

    Comandos *ctl del ecosistema systemd

    systemctl — control de unidades

    La herramienta principal para gestionar el estado de servicios y otras unidades:

    systemctl start nombre       # arrancar ahora
systemctl stop nombre        # detener ahora
systemctl restart nombre     # detener y volver a arrancar
systemctl reload nombre      # recargar configuración sin reiniciar el proceso
systemctl enable nombre      # activar en el próximo boot
systemctl disable nombre     # desactivar en el próximo boot
systemctl status nombre      # ver estado actual y últimos logs
systemctl list-units         # listar unidades cargadas actualmente
systemctl list-unit-files    # listar todas las unidades instaladas (activas o no)
systemctl daemon-reload      # releer definiciones de unidades tras editarlas
systemctl isolate multi-user.target  # cambiar de target activo (similar a cambiar runlevel)
systemctl --failed           # listar únicamente las unidades que fallaron

    journalctl — consultas adicionales al journal

    journalctl                    # todo el log disponible
journalctl -f                 # seguimiento en vivo de todo el sistema
journalctl -xe                # contexto extendido de los eventos más recientes
journalctl -p err             # filtrar por severidad (err, warning, crit, etc.)
journalctl -u nombre          # logs de una unidad específica
journalctl -b                 # logs solo del arranque actual
journalctl -k                 # solo mensajes del kernel (equivalente a dmesg)
journalctl --since "2026-01-01"  # filtrar por fecha

    loginctl — sesiones de usuario

    Gestiona sesiones activas, útil en servidores multiusuario o para depurar sesiones colgadas:

    loginctl list-sessions           # ver todas las sesiones activas
loginctl session-status 3        # detalle de una sesión específica
loginctl terminate-session 3     # cerrar una sesión a la fuerza
loginctl list-users              # usuarios con sesión activa
loginctl user-status usuario     # detalle de sesiones de un usuario
loginctl enable-linger usuario   # permite que los servicios de usuario (systemd --user) sigan corriendo aunque cierre sesión

    timedatectl — fecha, hora y NTP

    timedatectl                                  # ver configuración actual
timedatectl set-time "2026-06-30 10:00:00"   # fijar hora manualmente
timedatectl set-timezone America/Guayaquil   # cambiar zona horaria
timedatectl set-ntp true                     # activar sincronización automática por NTP

    hostnamectl — nombre del equipo

    hostnamectl                      # ver hostname y datos del sistema (kernel, arquitectura, etc.)
hostnamectl set-hostname servidor  # cambiar el hostname de forma persistente

    localectl — idioma y teclado

    localectl                          # ver configuración de locale actual
localectl set-locale LANG=es_EC.UTF-8  # cambiar idioma del sistema
localectl set-keymap us            # cambiar distribución de teclado

    networkctl — estado de interfaces de red

    Solo aplica en sistemas que usan systemd-networkd como gestor de red (no todos — muchas distros usan NetworkManager o ifupdown en su lugar):

    networkctl              # listar interfaces y su estado
networkctl status eth0  # detalle de una interfaz específica
networkctl list         # listado resumido
networkctl reload       # releer configuración de red

    resolvectl — resolución DNS

    resolvectl status              # ver servidores DNS configurados por interfaz
resolvectl query google.com    # hacer una consulta DNS de prueba
resolvectl flush-caches        # limpiar la caché de resolución DNS
resolvectl dns eth0 8.8.8.8    # fijar un DNS específico para una interfaz

    machinectl — contenedores y máquinas virtuales ligeras

    Gestiona contenedores creados con systemd-nspawn:

    machinectl list          # ver contenedores registrados
machinectl start debian  # arrancar un contenedor
machinectl stop debian   # detenerlo
machinectl shell debian  # abrir una shell dentro del contenedor

    bootctl — gestor de arranque (systemd-boot)

    bootctl status   # ver estado del bootloader
bootctl install  # instalar systemd-boot en la partición EFI
bootctl update   # actualizar los binarios del bootloader

    systemd-analyze — rendimiento de arranque

    Herramienta de diagnóstico para entender qué tarda en el proceso de boot:

    systemd-analyze                  # tiempo total de arranque, desglosado por fase
systemd-analyze blame            # qué servicios tardaron más en iniciar
systemd-analyze critical-chain   # cadena de dependencias que determinó el tiempo total
systemd-analyze plot > boot.svg  # generar un gráfico visual del arranque

    systemd-run — ejecutar comandos como unidades temporales

    Permite lanzar cualquier comando como si fuera un servicio administrado por systemd, sin crear un archivo .service permanente — útil para pruebas o tareas puntuales que necesitan aislamiento de recursos:

    systemd-run --unit=mi-tarea echo "hola"
systemd-run --scope sleep 10

    systemd-cgls y systemd-cgtop — jerarquía de cgroups

    systemd-cgls    # árbol de cgroups activos (qué proceso pertenece a qué unidad)
systemd-cgtop   # uso de recursos en tiempo real, agrupado por cgroup

    systemd-escape — codificar nombres para unidades

    Convierte rutas o cadenas con caracteres especiales al formato seguro que systemd usa internamente para nombrar unidades:

    systemd-escape "ruta rara"
systemd-escape --path "/home/usuario/archivo"

    systemd-inhibit — evitar suspensión/apagado durante una tarea

    systemd-inhibit sleep 30
systemd-inhibit --why="Proceso crítico" comando

    systemd-notify — comunicación entre el proceso y systemd

    Usado dentro de scripts o servicios Type=notify para avisarle a systemd que el proceso ya está listo, o para reportar su estado actual:

    systemd-notify --ready
systemd-notify --status="Inicializando..."

    systemd-sysusers — creación declarativa de usuarios del sistema

    systemd-sysusers
systemd-sysusers /etc/sysusers.d/archivo.conf

    systemd-tmpfiles — gestión de archivos y directorios temporales

    systemd-tmpfiles --create   # crear archivos/directorios definidos en configuración
systemd-tmpfiles --clean    # limpiar archivos temporales expirados
systemd-tmpfiles --remove   # eliminar los definidos en configuración

    systemd-nspawn — contenedores ligeros

    systemd-nspawn -D /var/lib/machines/debian
systemd-nspawn -M mi-maquina

    Timers systemd

    Los timers son la alternativa moderna a cron, con la ventaja de integrarse con el journal (logs unificados) y con dependencias de otras unidades. Un timer siempre va acompañado de un servicio con el mismo nombre base.

    Timer (backup.timer):

    [Unit]
Description=Backup diario

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

    Persistent=true es clave: si el equipo estuvo apagado cuando debía ejecutarse el timer, lo corre en cuanto vuelve a encender, en vez de esperar al siguiente ciclo — evita perder ejecuciones por reinicios o cortes de energía.

    Servicio asociado (backup.service):

    [Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

    Type=oneshot le indica a systemd que el proceso termina por sí solo tras completar su tarea (no es un servicio de larga duración) — es el tipo correcto para scripts que corren, hacen su trabajo, y salen.

    Activación:

    systemctl enable --now backup.timer
systemctl list-timers

    Depuración avanzada

    Secuencia típica para diagnosticar un servicio que no arranca o falla:

    systemctl status mi-servicio                          # estado y últimas líneas de log
journalctl -u mi-servicio -p err -b                    # solo errores, desde el último boot
journalctl -u mi-servicio -n 20                        # últimas 20 líneas de log
journalctl _PID=$(pidof mi-servicio)                   # logs filtrados por PID específico
systemctl list-dependencies mi-servicio                # árbol de dependencias
systemd-analyze verify /etc/systemd/system/mi-servicio.service  # validar sintaxis del archivo
sudo -u usuario /usr/bin/python3 /opt/app/app.py        # ejecutar manualmente como el mismo usuario, para ver el error real
ls -l /opt/app/app.py                                   # confirmar que el archivo existe y tiene permisos correctos
ls -l /usr/bin/python3                                  # confirmar que el binario existe en la ruta esperada
cat /etc/default/app                                    # revisar variables de entorno cargadas
systemctl daemon-reload                                 # por si el problema es una definición desactualizada

    Interpretación completa de systemctl status

    Ejemplo de salida real:

    ○ rory-indexer.service - Rory Indexer RAG
     Loaded: loaded (/etc/systemd/system/rory-indexer.service; static)
     Active: inactive (dead) since Tue 2026-06-30 03:24:53 -05; 5h 29min ago
TriggeredBy: ● rory-indexer.timer
    Process: 2967487 ExecStart=/opt/rory-indexer/bin/python3 /opt/rory-indexer/scripts/indexer_v2.py (code=exited, status=0/SUCCESS)
   Main PID: 2967487 (code=exited, status=0/SUCCESS)
        CPU: 1min 18.622s

    Primera línea

    Muestra el símbolo de estado visual (● activo, ○ inactivo, ✗ falló, ▲ iniciando), el nombre técnico del servicio y su descripción legible.

    Loaded

    Indica si el archivo .service está cargado, su ruta completa, y el estado de instalación: enabled (arranca en boot), disabled (no arranca en boot pero se puede iniciar manualmente), static (no tiene sección [Install], solo se activa como dependencia de otra unidad), o masked (bloqueado explícitamente, no se puede iniciar ni siquiera manualmente).

    Active

    El estado real de ejecución: active (running), inactive (dead), failed, activating o deactivating (transiciones en curso), y reloading.

    TriggeredBy

    Indica qué otra unidad activó este servicio — típicamente un Timer, un Socket, o un Path (activación al detectar cambios en un archivo/directorio).

    Process

    Detalle del último proceso ejecutado: PID, comando exacto que se corrió, y el código de salida (exit code) — clave para saber si terminó bien (status=0/SUCCESS) o con error.

    Main PID

    El proceso principal identificado por el servicio, el que systemd supervisa para determinar si sigue vivo.

    CPU

    Tiempo total de CPU consumido por el servicio desde que arrancó.

    Logs

    Las últimas líneas del journal relacionadas con esta unidad, mostradas automáticamente al final del status.

    Buenas prácticas

    • Usar siempre rutas absolutas en ExecStart — systemd no hereda el $PATH de una shell de usuario.
    • Restart=on-failure como valor por defecto razonable, para que el servicio se recupere solo ante caídas inesperadas.
    • After=network-online.target si el servicio depende de conectividad de red al arrancar (evita condiciones de carrera con la red, como las que resuelven un resolv.conf vacío en contenedores Docker al bootear antes que la red).
    • EnvironmentFile= para mantener configuraciones y secretos fuera del archivo .service en sí, en un archivo separado con permisos restringidos.
    • Monitorear en vivo con journalctl -u servicio -f al depurar o al desplegar cambios.
    • Nunca olvidar systemctl daemon-reload después de editar cualquier archivo .service o .timer.