FreeBSD14.5
1. Identificar discos
geom disk list camcontrol devlist gpart show
En solaris, el disco USB suele aparecer como da0 o da1.
Verificar con geom disk list cuál es el correcto (etiqueta ZFSBACKUP).
2. Comprobaciones previas (antes de destruir nada)
¿Tiene particiones?
gpart show da0
¿Tiene restos de ZFS?
zpool import | grep -B2 -A5 da0
¿Está montado en algún sitio?
mount | grep da0
3. Plan resumido
| Comando | Qué hace |
|---|---|
gpart destroy -F da0 | Borra particiones |
zpool labelclear -f /dev/da0 | Borra restos ZFS |
gpart create -s gpt da0 | Tabla GPT nueva |
gpart add -t freebsd-zfs -l ZFSBACKUP da0 | Partición ZFS |
zpool create -o ashift=12 ... zbackup /dev/gpt/ZFSBACKUP | Pool zbackup |
zfs create -o mountpoint=none zbackup/recovery/solaris | Dataset destino |
zfs snapshot -r zroot@snap-$(date +%Y%m%d) | Snapshot del sistema |
zfs send -Rwcv ... | zfs receive -Fsuv ... | Envío local (en tmux) |
zpool export zbackup | Cerrar limpiamente |
4. Preparar el disco
gpart destroy -F da0 # → da0 destroyed
Borrar cualquier resto de ZFS (aunque no haya, por asegurar)
zpool labelclear -f /dev/da0 2>/dev/null
Crear tabla GPT nueva
gpart create -s gpt da0 # → da0 created
Crear partición ZFS ocupando todo el disco
gpart add -t freebsd-zfs -l ZFSBACKUP da0 # → da0p1 added
Verificar
gpart show da0 # → 40 3907029088 da0 GPT (2T) # → 40 3907029088 1 freebsd-zfs (2T)
5. Crear el pool zbackup
Los discos modernos suelen tener sectores de 4K, pero muchos discos USB reportan 512B. Es crítico crear el pool con ashift=12 (4096 bytes) para evitar problemas de rendimiento.
Ver ashift que ZFS detectaría por defecto
diskinfo -v da0 | grep -i "sector size"
Si dice 512, hay que forzar ashift=12 al crear el pool.
zpool create -o ashift=12 \
-O compression=lz4 \
-O atime=off \
-O xattr=sa \
-O relatime=on \
-O mountpoint=none \
zbackup /dev/gpt/ZFSBACKUP
Banderas
- ashift=12 → sectores 4K (crítico para rendimiento en discos modernos).
- compression=lz4 → compresión ligera y rápida.
- atime=off → no actualizar tiempo de acceso (más rápido).
- xattr=sa → atributos extendidos en el inodo.
- relatime=on → atime solo cuando sea útil.
- mountpoint=none → no montar automáticamente.
Verificar
zpool status zbackup zpool list zbackup zfs list
Crear dataset destino
zfs create -o mountpoint=none zbackup/recovery zfs create -o mountpoint=none zbackup/recovery/solaris zfs list -r zbackup
Salida esperada:
zbackup XXXG XXXG 96K none zbackup/recovery XXXG XXXG 96K none zbackup/recovery/solaris XXXG XXXG 96K none
Pool zbackup creado correctamente:
| Dato | Valor |
|---|---|
| Pool | zbackup |
| Tamaño | ~2 TB |
| Dataset destino | zbackup/recovery/solaris (listo) |
| zroot a respaldar | ~220 G |
6. Crear snapshot del sistema
zfs snapshot -r zroot@snap-$(date +%Y%m%d)
Verificar
zfs list -t snapshot -r zroot | grep snap-$(date +%Y%m%d) | wc -l
El resultado depende del número de datasets del sistema. En solaris actual: ~30.
Nota para el futuro: si un script creó el snapshot en un solo dataset sin usar
-r,
o si otro proceso lo creó antes para otro propósito, puede haber conflictos. Cuando se monte el cron
para backups automáticos, usar date +%Y%m%d-%H%M%S para evitar colisiones si se ejecuta
dos veces el mismo día.
zfs snapshot -r zroot@snap-$(date +%Y%m%d-%H%M%S)
7. Lanzar el envío en tmux
Entrar en tmux
tmux new -s backup_usb
Comando de envío (dentro de tmux)
zfs send -Rwcv zroot@snap-$(date +%Y%m%d) \ | zfs receive -Fsuv -x mountpoint zbackup/recovery/solaris
Banderas explicadas
| Flag | Significado |
|---|---|
-R | Recursivo: envía zroot y todos sus hijos |
-w | Raw: envía los bloques cifrados tal cual (necesario si hay datasets cifrados) |
-c | Compresión nativa ZFS (lz4) |
-v | Verbose: muestra progreso por dataset |
-F | Fuerza rollback en destino si hay divergencias |
-s | Guarda token de resume en /var/tmp/ (permite reanudar si se corta) |
-u | No monta los datasets recibidos |
-x mountpoint | No replica los mountpoints del origen |
Importante sobre -w: aunque solaris no tiene datasets cifrados actualmente,
el
-w es inofensivo si no hay cifrado. Mantener el mismo script/comando que en tormenta
para consistencia y por si en el futuro se añade cifrado.
8. Salir de tmux sin matar el proceso
Ctrl+b d
9. Monitorizar (en otra terminal)
Ver datasets llegando en tiempo real
watch -n 10 'zfs list -r zbackup/recovery/solaris | head -30'
Ver velocidad de escritura al USB
zpool iostat zbackup 5
Ver espacio consumido
watch -n 30 'zfs list zbackup'
10. Verificar tras el envío
Volver a la sesión tmux
tmux attach -t backup_usb
Si ya terminó, se verá el real Xm Ys del comando. Entonces:
Contar snapshots origen vs destino
zfs list -t snapshot -r zroot | wc -l zfs list -t snapshot -r zbackup/recovery/solaris | wc -l
Deben coincidir.
Verificar datasets replicados
zfs list -r zbackup/recovery/solaris | head -30
Espacio usado
zfs list zbackup zpool list zbackup
11. Si algo falla durante el envío
¿Sigue algún proceso zfs vivo?
ps aux | grep -E "zfs (send|receive)" | grep -v grep
Si aparece algo, sigue corriendo. Esperar y dejarlo terminar.
¿En qué estado está el destino?
zfs list zbackup zfs list -r zbackup/recovery/solaris | head -20
Se verá si quedó un dataset a medias (zbackup/recovery/solaris con datos parciales).
¿Hay un token de resume guardado?
ls -la /var/tmp/ | grep -i zfs ls -la / | grep -i zfs
El token de resume solo existe si se usó
-s en el zfs receive.
Si no se usó, no hay reanudación posible: hay que empezar de cero.
¿El proceso murió? Limpiar el destino parcial
zfs destroy -r zbackup/recovery/solaris zfs create -o mountpoint=none zbackup/recovery/solaris zfs list -r zbackup/recovery
Relanzar con -s para permitir resume
tmux new -s backup_usb
Dentro de tmux:
zfs send -Rwcv zroot@snap-20261002 \ | zfs receive -Fsuv -x mountpoint zbackup/recovery/solaris
El flag
-s en zfs receive guarda un token de reanudación en /var/tmp/.
Si se vuelve a cortar, se podrá reanudar con:
zfs send -t $(ls /var/tmp/zfs_*.resume 2>/dev/null | head -1)
Salir de tmux con Ctrl+b d antes de cerrar SSH.
No cerrar la sesión SSH hasta que tmux esté desconectado.
12. Exportar el pool y desconectar el USB
Verificar que no hay nada escribiendo
zpool status zbackup lsof | grep zbackup 2>/dev/null
Exportar limpiamente
zpool export zbackup
Y por último
sync
Ya se puede retirar el cable USB.
13. Tiempo estimado
| Velocidad USB | ~220 GB |
|---|---|
| 80 MB/s | ~45 min |
| 120 MB/s | ~30 min |
| 200 MB/s | ~18 min |
| 400 MB/s | ~9 min |
Con el chip ASMT USB 3.0 + disco SATA: ~15-30 min si es SSD, ~40-60 min si es HDD.
Recordatorio: para poder cerrar la sesión SSH sin que se corte el envío,
primero entrar en tmux con
tmux new -s backup_usb, lanzar el envío, y salir con
Ctrl+b d.
Recomendación adicional: poner una etiqueta al disco físico con rotulador o adhesivo:
- Backup Solaris
- snap-20261002
- zbackup pool
14. Restaurar archivos de configuración
No requiere reiniciar. Solo copia los archivos desde el snapshot.
Paso 1: Montar el snapshot
mkdir -p /mnt/snap mount -t zfs zroot/ROOT/default@snap-14.4-RELEASE-p8-casa.lan-2026-28-sept-2026 /mnt/snap
Paso 2: Comparar qué cambió
diff /etc/pf.conf /mnt/snap/etc/pf.conf diff /etc/rc.conf /mnt/snap/etc/rc.conf diff /etc/sysctl.conf /mnt/snap/etc/sysctl.conf diff /boot/loader.conf /mnt/snap/boot/loader.conf
Paso 3: Backup de los actuales
cp /etc/pf.conf /etc/pf.conf.broken-$(date +%Y%m%d) cp /etc/rc.conf /etc/rc.conf.broken-$(date +%Y%m%d) cp /etc/sysctl.conf /etc/sysctl.conf.broken-$(date +%Y%m%d) cp /boot/loader.conf /boot/loader.conf.broken-$(date +%Y%m%d)
Paso 4: Restaurar desde el snapshot
cp /mnt/snap/etc/pf.conf /etc/pf.conf cp /mnt/snap/etc/rc.conf /etc/rc.conf cp /mnt/snap/etc/sysctl.conf /etc/sysctl.conf cp /mnt/snap/boot/loader.conf /boot/loader.conf
Paso 5: Desmontar y probar
umount /mnt/snap rmdir /mnt/snap # Recargar pf (sin reiniciar) pfctl -f /etc/pf.conf # Ver rutas netstat -rn # Probar red ping -c 3 192.168.88.1 ping -c 3 8.8.8.8 ping -c 3 google.com
Paso 6: Si funciona, reiniciar para aplicar loader.conf y sysctl.conf
shutdown -r now
15. Rollback completo
Requiere arrancar en modo monousuario. No se puede hacer con el dataset montado.
Paso 1: Crear snapshot de seguridad del estado actual
Antes de tocar nada, para poder volver si algo falla:
zfs snapshot -r zroot@before-rollback-$(date +%Y%m%d-%H%M)
Paso 2: Reiniciar en modo monousuario
shutdown -r now
En el menú de arranque de FreeBSD, pulsar 2 (Boot Single User).
Paso 3: Preparar el sistema
zfs set readonly=off zroot zfs mount -a
Paso 4: Rollback
Esto destruye los snapshots posteriores a este (incluido el de before-rollback).
zfs rollback -R zroot/ROOT/default@snap-14.4-RELEASE-p8-casa.lan-2026-28-sept-2026
Paso 5: Salir del modo monousuario y reiniciar
exit
O directamente:
reboot
Qué se pierde con el rollback
| Elemento | Estado |
|---|---|
| pf.conf | Vuelve al estado del snapshot |
| loader.conf | Vuelve al estado del snapshot |
| sysctl.conf | Vuelve al estado del snapshot |
| /etc/rc.conf | Estado del snapshot |
| Archivos en /home/carlos | NO se pierden (dataset separado) |
| Archivos en /var | NO se pierden (dataset separado, si no se hace rollback ahí) |
Solo afecta a
zroot/ROOT/default (el sistema base).
Los datos personales en zroot/home/carlos no se tocan.
16. Uso del script automatizado
Solaris tiene instalado el script /root/bin/zfs-backup.sh que automatiza todo el proceso.
Ejecución manual (modelo B: USB guardado fuera)
# 1. Conectar el USB ZFSBACKUP a solaris # 2. Ejecutar: sh /root/bin/zfs-backup.sh # 3. Ver el resultado tail -20 /var/log/zfs-backup.log # 4. Cuando termine, el script exporta el pool automáticamente # 5. Desconectar el USB y guardarlo en lugar seguro
Qué hace el script automáticamente
- Detecta que está en solaris y usa
zbackup/zbackup/recovery/solaris/ZFSBACKUP. - Importa el pool
zbackupsi no está importado. - Crea el snapshot
zroot@snap-YYYYMMDD(dataset por dataset, sin fallos atómicos). - Detecta la última snapshot en destino y envía solo el incremental.
- Aplica retención: 7 snapshots en origen, 30 en destino.
- Exporta el pool al terminar (para poder desconectar el USB).
- Registra todo en
/var/log/zfs-backup.log.
Frecuencia recomendada
Semanal (domingo por la tarde). Total: 5-15 minutos por backup.
17. Errores comunes a evitar
- Usar
zfs send -Rcvsin-w→ falla si hay datasets cifrados. - Olvidar
-senzfs receive→ no hay reanudación posible si se corta. - Cerrar la sesión SSH sin tmux → el envío muere al desconectar.
- No guardar la clave de cifrado fuera del backup → backup inútil si se pierde.
- Usar
zfs destroysin-nprimero → riesgo de borrar snapshots con dependencias. - Ejecutar el script de retención sin verificar → puede borrar snapshots indiscriminadamente.
- Importar el mismo pool en dos máquinas simultáneamente → corrompe metadatos.
- Desconectar el USB sin
zpool export→ riesgo de corrupción.
18. Checklist final
- [ ] Disco USB identificado y preparado
- [ ] Pool
zbackupcreado conashift=12 - [ ] Dataset
zbackup/recovery/solariscreado - [ ] Snapshot del sistema creado (
zfs snapshot -r) - [ ] Envío lanzado dentro de tmux
- [ ] Proceso monitorizado hasta el final
- [ ] Verificado: snapshots origen vs destino coinciden
- [ ] Pool exportado limpiamente (
zpool export zbackup) - [ ] USB desconectado y guardado en lugar seguro
- [ ] Clave de cifrado guardada en al menos 2 sitios distintos (si aplica)
19. Dónde guardar el USB
| Ubicación | Protección |
|---|---|
| ❌ Junto a la máquina | Ninguna (robo/incendio afecta a ambos) |
| ⚠️ Otra habitación de la casa | Protección baja |
| ✅ Otra planta / garaje / trastero | Protección media |
| ✅✅ Casa de un familiar / amigo | Protección alta |
| ✅✅✅ Caja de seguridad del banco | Protección máxima |
Recomendación: caja fuerte pequeña en casa + copia secundaria en casa de un familiar.
20. Verificaciones periódicas (cada 3-6 meses)
# 1. Conectar el USB ZFSBACKUP a solaris # 2. Importar el pool zpool import zbackup # 3. Verificar el pool zpool status zbackup # 4. Contar snapshots en destino zfs list -t snapshot -r zbackup/recovery/solaris | grep 'snap-2026' | wc -l # 5. Ver las más recientes zfs list -t snapshot -r zbackup/recovery/solaris | grep 'snap-2026' | sort | tail -5 # 6. Exportar zpool export zbackup
Si todo está en orden, los datos son recuperables.
FreeBSD es genial!.
No hay comentarios:
Publicar un comentario