‘Format C:’ y otros comandos que arruinaron fines de semana

Por qué se arruinan los fines de semana: los comandos destructivos aún existen

“Format C:” se convirtió en chiste porque capturó una verdad: los ordenadores hacen exactamente lo que les dijiste que hicieran, no lo que querías decir. Los sistemas modernos simplemente te dan más maneras de equivocarte con precisión. En lugar de un disco tienes capas LVM, controladoras RAID que virtualizan la realidad, nombres de dispositivos multipath, sistemas de ficheros overlay en contenedores, volúmenes efímeros en la nube y orquestadores que pueden replicar tu error a escala.

Los comandos destructivos persisten porque la eliminación es una operación legítima. Necesitamos borrar discos, reinicializar nodos, reconfigurar sistemas de archivos, recortar dispositivos de bloque y hacer garbage-collection de datasets antiguos. La diferencia entre higiene y homicidio suele ser un carácter, una suposición o un modelo mental obsoleto.

Aquí está el patrón operativo que debes reconocer: una tarea rutinaria de mantenimiento se cruza con incertidumbre (¿qué dispositivo es cuál?) bajo presión de tiempo (están sonando alertas). El ingeniero intenta ser eficiente. La eficiencia se vuelve velocidad. La velocidad se vuelve conjetura. La conjetura se vuelve un ticket que dice “faltan datos” y un gerente preguntando por qué los backups no lo cubrieron mágicamente.

Una cita que deberías mantener pegada a tu monitor—porque es verdad aunque no te guste—es una idea parafraseada de John Allspaw: los incidentes rara vez son culpa de una sola mala persona; vienen de gente normal navegando sistemas desordenados.

También: los comandos destructivos no siempre parecen destructivos. A veces el peor comando es el que “arregla” un problema de rendimiento desactivando las barreras. O el que reequilibra un clúster “limpiando” volúmenes. O el que cambia opciones de montaje y corrompe supuestos, no datos.

Broma 1/2: Un comando destructivo es como una motosierra—herramienta estupenda, juguete terrible.

Hechos e historia para usar en postmortems de incidentes

• El comando FORMAT original de DOS no era solo “borrar”; escribía estructuras del sistema de archivos. Esa distinción importa hoy: “formatear” puede significar resetear metadatos, no rellenar con ceros.
• El orden de unidades en BIOS antiguas hacía inestable la identidad de los discos. Lo que parecía “Disco 0” podía cambiar tras modificaciones de hardware—el equivalente hoy es el renumerado de /dev/sdX tras reinicios o swaps de HBA.
• El “todo es un archivo” de Unix hizo que los dispositivos fueran escribibles como archivos. Eso es poder y peligro: dd no distingue si el objetivo es una imagen de prueba o tu disco de arranque.
• Muchos sistemas de archivos “borran” quitando referencias, no borrando contenido. Por eso la recuperación forense a veces funciona, y por qué el borrado seguro es un problema aparte.
• Device-mapper, LVM y multipath introdujeron nuevas capas de abstracción. Resolvían problemas (flexibilidad, rutas HA) pero hicieron más difícil responder “¿qué disco es ese?” bajo presión.
• Los sistemas de archivos copy-on-write cambiaron los modos de fallo. Los snapshots pueden salvarte de una eliminación, pero la fragmentación y la contabilidad de espacio también pueden sorprenderte durante la recuperación.
• El almacenamiento en la nube convirtió los discos en desechables—y la gente trató los datos igual. “Simplemente reconstruye la instancia” está bien hasta que te das cuenta de que el estado vivía en el store local de la instancia.
• Las controladoras RAID empresariales pueden mentir por omisión. Presentan volúmenes lógicos que ocultan la topología física, así que reemplazar “el disco equivocado” aún puede romper el array correcto.
• La automatización expandió el radio de explosión. La misma IaC que puede reconstruir una flota también puede borrarla si el scope de variables o el targeting están mal.

Modos de fallo: cómo la gente termina eliminando lo incorrecto

1) Identidad ambigua: el problema “¿qué disco es /dev/sdb?”

Los nombres de dispositivo en Linux no son identidad. Son orden. El orden es una sugerencia. En sistemas con múltiples HBAs, namespaces NVMe, LUNs iSCSI o eventos hotplug, el mapeo entre /dev/sdX y “el disco que crees que tocas” es una moneda al aire disfrazada de determinismo.

Los operadores serios usan identificadores estables: WWN, serial, rutas by-id y UUIDs de sistema de archivos. El error es pensar que puedes “simplemente mirar lsblk rápido.” Bajo presión de incidente, “rápido” se vuelve “suficiente” y “suficiente” se vuelve “ups”.

2) Contexto equivocado: prod vs staging, host vs contenedor, nodo vs clúster

Muchos “comandos destructivos” se ejecutaron en la máquina correcta—solo que no en el entorno correcto. O ejecutados dentro de un contenedor asumiendo que era el host. O lanzados en un nodo de Kubernetes cuando el volumen estaba realmente adjunto en otro lado. Los errores de contexto ocurren porque los prompts mienten, las sesiones SSH se multiplican y la gente confía más en la memoria muscular que en las comprobaciones.

3) Comandos que parecen seguros porque los usaste sin problemas antes

rm -rf es un clásico, pero los éxitos modernos incluyen mkfs en el dispositivo equivocado, parted en el disco erróneo, zpool labelclear antes de asegurarte de tener backups, y scripts de “limpieza” que asumen rutas de dispositivo consistentes. El comando en sí no es malvado; la falta de verificación sí lo es.

4) Optimización que se disfraza de corrección

Cuando los sistemas están lentos, la gente se vuelve creativa. Desactivan barreras, incrementan la profundidad de cola, afinan dirty ratios, montan con opciones arriesgadas o cambian el comportamiento de writeback. Algunas optimizaciones son legítimas, pero cualquier cosa que cambie el orden de escrituras o las garantías de durabilidad puede convertir un corte de energía en corrupción. Las soluciones de rendimiento están permitidas; los compromisos de durabilidad sin pruebas no.

5) Intentos de recuperación que dificultan la recuperación

El killer de recuperaciones más común es seguir escribiendo en un disco tras una eliminación accidental. El segundo más común es “recrear” el sistema de archivos pensando que restaurará el punto de montaje. Una vez que ejecutas mkfs, has sobrescrito metadatos clave. Alguna recuperación sigue siendo posible, pero pasas de “restaurar desde snapshot” a “llamar al proveedor de recuperación de datos y empezar a rezar”.

Broma 2/2: Los proveedores de recuperación de datos no cobran por hora; cobran por el número de veces que dijiste “será rápido”.

Tres micro-historias corporativas (todas lo bastante reales para doler)

Micro-historia #1: El incidente causado por una suposición equivocada

Una compañía tenía una pequeña flota de réplicas de base de datos usadas para analítica. Se pidió a un ingeniero senior “borrar y reconstruir la réplica más antigua” porque su latencia de almacenamiento era peor que las demás. El host tenía dos dispositivos NVMe: uno para el SO y otro para los datos. En el ticket, el dispositivo de datos se describía como “el segundo NVMe”. Esa redacción invoca el caos.

En ese host en particular, tras una actualización de firmware reciente, el orden de enumeración cambió. Los nombres de dispositivo seguían siendo /dev/nvme0n1 y /dev/nvme1n1, pero cuál era “datos” se invirtió respecto a la memoria del ingeniero. Ejecutó mkfs.xfs /dev/nvme1n1 creyendo que era el disco de datos. Era el disco del SO. El nodo salió del clúster a mitad del comando, como suele pasar.

Como era “solo una réplica”, la reacción inicial fue calma. Luego la calma murió. La réplica estaba sirviendo como fuente para una canalización downstream que se había vuelto silenciosamente crítica para el negocio. Nadie había documentado esa dependencia. La reconstrucción llevó horas y los consumidores de la canalización empezaron a hacer backfill agresivo, transformando un problema de frescura de datos en un problema de carga.

El postmortem no trató sobre el comando. Trató sobre la suposición: “el segundo disco equivale a disco de datos”. La corrección no fue “tener más cuidado”. La corrección fue estandarizar identificadores estables, etiquetar dispositivos en la automatización y tratar “réplica” como “producción hasta que se demuestre lo contrario”.

Micro-historia #2: La optimización que salió mal

Un servicio con mucha carga de almacenamiento tenía problemas de latencia de escritura. Los ingenieros vieron picos durante horas punta y el equipo de aplicación pidió una “victoria rápida”. Alguien sugirió afinar las opciones de montaje del sistema de archivos y parámetros de VM para reducir latencia permitiendo un writeback más agresivo. El cambio se aplicó durante una ventana de mantenimiento, validado por un benchmark sintético, y desplegado.

Durante una semana, los gráficos de latencia mejoraron. El equipo declaró victoria. Luego hubo un evento de corte de energía no planificado en un rack—breve, desordenado, del tipo que “no se supone que pase” hasta que pasa. Tras el reinicio, varios nodos informaron inconsistencias en el sistema de archivos. Algunos regresaron con corrupción que requirió restaurar desde backups. Una victoria rápida se convirtió en una recuperación lenta.

La causa raíz no fue “afinar es malo”. Fue afinar sin un modelo de amenaza de durabilidad. Los benchmarks no incluyen brownouts. Y una opción de montaje adecuada para una capa de caché puede ser desastrosa para estado primario. Si cambias las semantics de orden de escritura, debes documentar el radio de explosión y probar escenarios de fallo, no solo el camino feliz de rendimiento.

La mejora duradera fue aburrida: mejor medición de amplificación de escritura, separar datos calientes de fríos y elegir hardware de almacenamiento que encaje con la carga. La afinación riesgosa se revertió y el equipo añadió una política: cambios de rendimiento que afectan durabilidad necesitan aprobación explícita de storage/SRE y un plan de pruebas de inyección de fallos.

Micro-historia #3: La práctica aburrida pero correcta que salvó el día

Otra organización ejecutaba una plataforma multi-tenant donde los datos de clientes vivían en datasets ZFS replicados a un segundo sitio. Tenían una práctica estricta: antes de cualquier mantenimiento destructivo, crear un snapshot con un nombre definido por el runbook y verificar el estado de replicación. A los ingenieros les molestaba porque añadía cinco minutos a cada tarea. Cinco minutos son una eternidad cuando estás cafeinado y confiado.

Una noche, un ingeniero on-call estaba desmantelando un tenant. El ticket decía “eliminar dataset pool/customers/acme”. Tecleó por error zfs destroy -r pool/customers/acme-prod, porque claro, el naming era similar. El comando tuvo éxito de inmediato y el dataset desapareció. Ese es el momento en que el estómago intenta salir por los zapatos.

Pero la política de snapshots se había seguido. Existía un snapshot de hace dos minutos y la replicación al sitio secundario estaba al día. La recuperación fue un procedimiento controlado: detener servicios dependientes, revertir el dataset al snapshot y reanudar. No hubo llamadas a proveedores. No hubo arqueología. El incidente se convirtió en un pequeño bache en lugar de una catástrofe visible para el cliente.

El postmortem no elogió heroísmos. Elogió la checklist. La lección fue contundente: si tu proceso depende de “la gente nunca comete typos”, tu proceso es ficción.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas que puedes ejecutar durante trabajo normal y durante incidentes. Cada una incluye: un comando, qué significa la salida y qué decisión tomar a partir de ella. Los comandos están centrados en Linux porque ahí es donde ocurren la mayoría de los momentos “format C:” modernos, pero los principios se aplican ampliamente.

Task 1: Confirmar dónde estás (identidad del host y entorno)

cr0x@server:~$ hostnamectl
 Static hostname: prod-db-07
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 9a2c3b...
         Boot ID: 4b113c...
  Virtualization: kvm
Operating System: Ubuntu 22.04.4 LTS
          Kernel: Linux 5.15.0-97-generic
    Architecture: x86-64

Significado: Esto te indica el hostname, la virtualización y el SO. Si esperabas staging y ves prod-, para.

Decisión: Si la identidad no coincide exactamente con lo que dice tu ticket de cambio, desiste. Reconéctate usando el bastión/perfil correcto.

Task 2: Haz que tu prompt grite “PROD” (comprobación rápida de cordura)

cr0x@server:~$ echo "$PS1"
\u@\h:\w\$

Significado: Un prompt sosito fomenta errores de contexto.

Decisión: Si operas producción, usa un prompt que incluya el entorno y quizá color. Esto es ingeniería preventiva, no estética.

Task 3: Listar dispositivos de bloque con identificadores estables

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL,WWN,MOUNTPOINTS
NAME        TYPE  SIZE MODEL          SERIAL        WWN                MOUNTPOINTS
nvme0n1     disk  476G Samsung SSD    S4EVNX0R...   0x5002538d...       
├─nvme0n1p1 part  512M                             /boot
└─nvme0n1p2 part 475G                             /
nvme1n1     disk 1.75T Intel SSD     BTTV1234...   0x55cd2e41...       
└─nvme1n1p1 part 1.75T                             /var/lib/postgresql

Significado: Puedes ver qué disco sustenta qué puntos de montaje, además del serial/WWN para identidad.

Decisión: Si se planea una acción destructiva, registra el WWN/serial en el changelog. Opera sobre esa identidad, no sobre “nvme1n1”.

Task 4: Cruzar rutas de dispositivo vía /dev/disk/by-id

cr0x@server:~$ ls -l /dev/disk/by-id/ | sed -n '1,12p'
total 0
lrwxrwxrwx 1 root root 13 Jan 21 10:11 nvme-INTEL_SSDPE2KX020T8_BTT... -> ../../nvme1n1
lrwxrwxrwx 1 root root 13 Jan 21 10:11 nvme-SAMSUNG_MZVLW512HMJP_S4E... -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 Jan 21 10:11 nvme-eui.55cd2e4141414141 -> ../../nvme1n1
lrwxrwxrwx 1 root root 15 Jan 21 10:11 nvme-eui.5002538d22222222 -> ../../nvme0n1

Significado: Estos symlinks proporcionan nombres relativamente estables. Los IDs estilo EUI/WWN son lo que quieres en automatización.

Decisión: Usa la ruta by-id en scripts y runbooks. Ejemplo: /dev/disk/by-id/nvme-eui.55cd....

Task 5: Confirmar qué está montado y qué lo está usando

cr0x@server:~$ findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS / /var/lib/postgresql
/ /dev/nvme0n1p2 ext4 rw,relatime,errors=remount-ro
/var/lib/postgresql /dev/nvme1n1p1 xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k

Significado: Muestra el tipo de sistema de archivos y las opciones de montaje. Si estás a punto de borrar un disco que está montado, te espera un mal rato.

Decisión: Si el objetivo está montado, detén y desmonta limpiamente (o detén servicios primero). Si desmontar no es posible, probablemente elegiste el objetivo equivocado.

Task 6: Identificar qué procesos escriben en un punto de montaje

cr0x@server:~$ sudo lsof +f -- /var/lib/postgresql | sed -n '1,8p'
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
postgres 2312  pg   cwd    DIR  259,1     4096    2 /var/lib/postgresql
postgres 2312  pg    10u   REG  259,1 10485760  123 /var/lib/postgresql/base/16384/2600
postgres 2312  pg    11u   REG  259,1  8388608  124 /var/lib/postgresql/base/16384/2601

Significado: Si ves escrituras activas, no puedes tratar el sistema de archivos como “inactivo”.

Decisión: Detén el servicio o drena el nodo antes de cualquier mantenimiento de disco. Si no puedes detenerlo, replanifica o haz failover.

Task 7: Ver la presión inmediata de I/O del disco (chequeo “¿es el almacenamiento el cuello de botella?”)

cr0x@server:~$ iostat -xz 1 3
Linux 5.15.0-97-generic (prod-db-07)  01/21/2026  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    3.22    8.45    0.00   76.23

Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1          12.0   110.0   512.0  4096.0   2.10  18.0
nvme1n1         180.0   240.0  8192.0 16384.0  21.50  98.0

Significado: Un await alto y %util cercano al 100% sugiere que el dispositivo está saturado o experimentando latencia.

Decisión: Si nvme1n1 está al 98% de util con 21ms de await y tu SLO espera ms bajos, diagnostica la carga (coladeo, amplificación de escritura) antes de “optimizar” opciones de montaje.

Task 8: Comprobar espacio de sistema de archivos y presión de inodos

cr0x@server:~$ df -hT /var/lib/postgresql
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme1n1p1  xfs  1.8T  1.7T   90G  95% /var/lib/postgresql

Significado: 95% de uso puede provocar fragmentación, problemas de asignación y picos de latencia de escritura.

Decisión: Si un sistema de archivos está por encima de ~85–90% para cargas de escritura intensiva, planifica expansión o limpieza. No “arregles rendimiento” desactivando funciones de seguridad.

Task 9: Ver qué piensa tu capa RAID/LVM que está pasando

cr0x@server:~$ sudo pvs; sudo vgs; sudo lvs -a -o +devices
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sda2  vg0  lvm2 a--  931.00g 12.00g
  VG   #PV #LV #SN Attr   VSize   VFree
  vg0    1   2   0 wz--n- 931.00g 12.00g
  LV   VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  root vg0  -wi-ao---- 100.00g                                            /dev/sda2(0)
  data vg0  -wi-ao---- 819.00g                                            /dev/sda2(25600)

Significado: Si tu “disco” es en realidad un PV en un VG, borrarlo borra todo en ese VG.

Decisión: Si ves LVM, trata la pila como un sistema. Planifica cambios en la capa correcta y actualiza diagramas/runbooks según corresponda.

Task 10: Confirmar pools y datasets ZFS antes de destruir nada

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:12:03 with 0 errors on Tue Jan 20 03:10:22 2026
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80...      ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80...      ONLINE       0     0     0

errors: No known data errors

Significado: La topología del pool y la identidad del dispositivo son explícitas. Si ves /dev/sdX aquí, corrige eso antes de que se convierta en una pesadilla de migración.

Decisión: Si vas a eliminar/reemplazar un disco, asegúrate de operar sobre el dispositivo by-id exacto listado en zpool status.

Task 11: Snapshot antes de operaciones riesgosas (ejemplo ZFS)

cr0x@server:~$ sudo zfs snapshot -r tank/customers/acme@pre-decom-2026-01-21
cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer -r tank/customers/acme | tail -n 3
tank/customers/acme@pre-decom-2026-01-21     0B  1.2T

Significado: El snapshot existe y es barato (0B usado inicialmente) porque referencia bloques existentes.

Decisión: Si la creación del snapshot falla o la replicación está retrasada, detente. No procedas con un cambio destructivo sin un mecanismo de rollback.

Task 12: Dry-run de eliminaciones (donde sea posible) y restringir el alcance

cr0x@server:~$ rsync -aHAXn --delete /srv/app/ /srv/app.new/ | sed -n '1,8p'
deleting old-cache/tmp123
deleting old-cache/tmp124
./
config/
config/app.yaml

Significado: -n muestra lo que cambiaría. La palabra “deleting” debería activar una revisión cuidadosa.

Decisión: Si el dry run muestra eliminaciones inesperadas, corrige tus reglas include/exclude antes de ejecutar sin -n.

Task 13: Detectar “ups, directorio equivocado” antes de rm -rf

cr0x@server:~$ pwd; ls -la
/var/lib/postgresql
total 24
drwx------  19 pg   pg  4096 Jan 21 10:02 .
drwxr-xr-x   3 root root 4096 Jan 10 09:11 ..
drwx------   5 pg   pg  4096 Jan 21 10:02 base
drwx------   2 pg   pg  4096 Jan 21 10:02 global

Significado: Si estás en un directorio de datos y tu próximo comando es “cleanup”, estás apostando.

Decisión: Usa rutas absolutas en comandos destructivos. Si debes usar rutas relativas, imprime explícitamente pwd primero y léelo como si revisaras un contrato.

Task 14: Probar que un dispositivo de bloque es el que pretendes (chequeo de solo lectura)

cr0x@server:~$ sudo blkid /dev/nvme1n1p1
/dev/nvme1n1p1: UUID="2a1d7c8f-3f2d-4b9d-9a7d-2ddfdd5d8b9a" TYPE="xfs" PARTUUID="b3d1..."

Significado: Esto te dice qué sistema de archivos existe y su UUID.

Decisión: Si esperabas “sin sistema de archivos” y ves una firma XFS/ext4 válida, detente. Estás a punto de borrar algo real.

Task 15: Inspeccionar logs recientes del kernel por resets y errores de disco

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvme|reset|I/O error|blk_update_request' | tail -n 8
[Tue Jan 21 10:05:11 2026] nvme nvme1: I/O 123 QID 4 timeout, aborting
[Tue Jan 21 10:05:11 2026] nvme nvme1: Abort status: 0x371
[Tue Jan 21 10:05:12 2026] nvme nvme1: resetting controller
[Tue Jan 21 10:05:14 2026] blk_update_request: I/O error, dev nvme1n1, sector 983040 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0

Significado: Timeouts y resets apuntan a problemas de hardware, firmware o driver—a menudo mal diagnosticados como “la base de datos está lenta”.

Decisión: Si ves resets/timeouts, deja de tunear software y empieza a aislar hardware, firmware, colas o problemas de path.

Task 16: Confirmar comportamiento TRIM/discard (porque “limpiar” puede hacer daño)

cr0x@server:~$ lsblk -D -o NAME,DISC-ALN,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME     DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1         0      512B       2G         0
nvme1n1         0      512B       2G         0

Significado: El dispositivo soporta discard. Dependiendo del sistema de archivos y las opciones de montaje, las eliminaciones pueden emitir discard/TRIM y dificultar la recuperación forense.

Decisión: Si confías en recuperación tipo undelete, asume que discard reduce las probabilidades. Prefiere snapshots/backups a la esperanza.

Guía de diagnóstico rápido: qué comprobar primero/segundo/tercero

Esta es la secuencia “deja de adivinar”. No necesitas una war room para seguirla. Necesitas disciplina y disposición a equivocarte rápido.

Primero: prueba qué está fallando (síntoma vs origen)

1. ¿El síntoma visible es latencia, errores o datos faltantes? Datos faltantes sugiere acción destructiva o corrupción. Latencia sugiere contención, saturación o degradación.
2. Revisa el patrón de errores de la aplicación. Timeouts suelen mapear a esperas de I/O; “no such file” a eliminaciones/problemas de montaje; errores de checksum a corrupción.
3. Confirma que estás en el host y la capa correctos. Contenedor vs host importa. Una ruta dentro de un contenedor puede mapear a un volumen que no esperabas.

Segundo: clasifica el cuello de botella (CPU, memoria, disco, red, contención de locks)

1. CPU y cola de ejecución: si la carga es alta pero iowait es bajo, no es principalmente almacenamiento.
2. Presión de memoria: si hay swapping activo, todo parece latencia de almacenamiento pero en realidad es falta de memoria.
3. Saturación de disco: %util alto y await creciente indica colas; correlaciona con picos de carga.
4. Red: si el almacenamiento es remoto (iSCSI, NFS, cloud block), mide latencia/pérdida de red.
5. Locks y tormentas de fsync: las bases de datos pueden autoinfligirse dolor de I/O vía checkpoints o patrones intensivos en sync.

Tercero: elige la acción más segura siguiente

1. Si los datos podrían estar borrados o corruptos: detén las escrituras. Congela al paciente. Toma snapshots (o snapshots LVM) si aún es posible.
2. Si es rendimiento: captura evidencia primero (iostat, vmstat, dmesg). Luego aplica mitigaciones reversibles (limitar tasa, mover carga, añadir capacidad).
3. Si el hardware es sospechoso: no “reparar” formateando. Aísla, haz failover, reemplaza.

Errores comunes: síntomas → causa raíz → corrección

1) “Formateé el disco equivocado”

Síntomas: el sistema no arranca; fallan montajes; la firma del sistema de archivos cambió; caída inmediata del servicio.

Causa raíz: identidad del disco basada en /dev/sdX o “segundo disco”, no en IDs estables; sin chequeos preoperatorios; sin snapshots.

Corrección: usar /dev/disk/by-id en runbooks; exigir lsblk con serial/WWN; imponer snapshot pre-op donde sea posible; ejecutar acciones destructivas en modo mantenimiento.

2) “rm -rf borró más de lo esperado”

Síntomas: archivos faltantes de repente; servicios que no arrancan; directorios de config desaparecidos; logs muestran eliminaciones.

Causa raíz: ruta relativa usada desde el directorio de trabajo equivocado; expansión del shell; una variable vacía (rm -rf "$DIR" con DIR sin setear) o que contenía “/”.

Corrección: usar rutas absolutas; establecer set -u en scripts para fallar con variables sin setear; añadir checks guardia como “el directorio debe coincidir con regex”; usar dry runs (rsync -n) para borrados masivos.

3) “dd escribió ceros en el dispositivo equivocado”

Síntomas: tabla de particiones desaparecida; sistema de archivos no monta; blkid no devuelve nada; los datos parecen vacíos.

Causa raíz: confusión de rutas de dispositivo; error de copy/paste; confundir if= y of=.

Corrección: nunca ejecutar dd sin un paso de verificación de solo lectura; preferir herramientas más seguras para operaciones de wipe; cuando uses dd, imprime el comando, confirma el objetivo by-id y exige revisión por pares en producción.

4) “Optimizamos disco y apareció corrupción después”

Síntomas: tras reinicio o crash, falla el replay del journal; errores de checksum en la base de datos; se requieren reparaciones del sistema de archivos.

Causa raíz: cambios en opciones de montaje o parámetros del kernel que afectan durabilidad; desactivar barreras; cache de escritura RAID mal configurada sin protección de batería/flash.

Corrección: tratar las semantics de durabilidad como una restricción de diseño; ejecutar tests de inyección de fallos; documentar qué capas pueden sacrificar durabilidad por velocidad (cache) y cuáles no (fuente de la verdad).

5) “Todo está lento, pero solo a veces”

Síntomas: picos periódicos de latencia; picos de iowait; timeouts de app que se agrupan en momentos previsibles.

Causa raíz: jobs en background (scrub, backup, compactación); expiración de snapshots; rebuild de RAID; créditos de burst de volúmenes en nube agotados.

Corrección: correlaciona con calendarios; limitar tasks en background; aislar vecinos ruidosos; añadir capacidad steady-state en lugar de depender de burst.

6) “No podemos recuperar porque seguimos escribiendo”

Síntomas: la recuperación falla; archivos eliminados sobrescritos; herramientas de undelete no encuentran nada útil.

Causa raíz: continuar escrituras después de percibir la eliminación; recrear el sistema de archivos; servicios automáticos de limpieza en ejecución.

Corrección: procedimiento inmediato de parada de escrituras: detener servicios, remontar read-only si es posible, desacoplar volumen, snapshot a nivel de almacenamiento y luego intentar recuperación.

Listas de verificación / plan paso a paso

A. Antes de cualquier comando destructivo de almacenamiento (wipe, mkfs, destroy, labelclear)

1. Confirma el entorno: identidad del host, cuenta/perfil, contexto del clúster.
2. Identifica el objetivo por ID estable: WWN/serial, no sdX/nvmeX.
3. Prueba qué está montado: findmnt sobre el objetivo.
4. Prueba qué está escribiendo: lsof o estado del servicio.
5. Crea un manejador de rollback: snapshot/dataset snapshot/LVM snapshot o snapshot a nivel de almacenamiento. Si no puedes, consigue aprobación explícita para un cambio irreversible.
6. Declara el radio de explosión en una frase: “Esto borrará el disco que sustenta /var/lib/postgresql en prod-db-07.” Si no puedes escribir esa frase, no entiendes el cambio.
7. Revisión por pares: otra persona lee la ruta de dispositivo exacta y el comando. No un “parece bien”. Deben re-derivar el objetivo.
8. Ejecuta con guardrails: usa rutas by-id, confirmación interactiva donde exista y registra la salida del comando.

B. Si sospechas que ejecutaste el comando equivocado (control de daños en los primeros 5 minutos)

1. Detén las escrituras inmediatamente. Para servicios, desacopla volúmenes, cordonea nodos—lo que sea para detener más daño.
2. No ejecutes comandos “arreglar” impulsivamente. Especialmente mkfs, herramientas de “repair” o reparticionado.
3. Captura estado: dmesg, lsblk, blkid, mount, estado de la capa de almacenamiento.
4. Snapshot si es posible. Incluso un snapshot de un volumen roto puede preservar evidencia y prevenir más pérdida.
5. Escala temprano. Storage y SRE deben entrar en el bucle antes de que alguien intente una “recuperación rápida”.

C. Si el problema es “el almacenamiento está lento” (respuesta segura de rendimiento)

1. Mide primero: iostat, vmstat, I/O por proceso y logs del kernel.
2. Identifica a los principales consumidores: qué proceso o job está generando I/O.
3. Mitiga de forma reversible: limitar jobs batch, mover carga, añadir réplicas, aumentar cache, reducir concurrencia.
4. Solo entonces afina: y siempre con un plan de rollback y evaluación de durabilidad.

Preguntas frecuentes

1) ¿Formatear es lo mismo que borrar?

No. Formatear típicamente escribe metadatos del sistema de archivos (superbloques, estructuras de asignación). Borrar implica sobrescribir más ampliamente. Cualquiera de los dos puede destruir la posibilidad de recuperación.

2) ¿Por qué /dev/sdX es poco fiable?

Porque se asigna según el orden de descubrimiento. El orden de descubrimiento puede cambiar con reinicios, actualizaciones de firmware, cambios de path o dispositivos añadidos. Usa rutas by-id, serials, WWNs o UUIDs.

3) Si borré el directorio equivocado, ¿debo remontar en solo lectura?

Si sospechas que necesitas recuperación de datos y puedes tolerar downtime, sí—detén las escrituras. Las escrituras sobrescriben bloques liberados y reducen las opciones de recuperación.

4) ¿TRIM/discard hace imposible la recuperación?

No siempre, pero puede hacerla mucho más difícil. Si los bloques son descartados, el dispositivo puede tratarlos como no asignados y devolver ceros. Asume que discard reduce tus opciones.

5) ¿Los snapshots sustituyen a los backups?

No. Los snapshots son excelentes para rollback rápido y recuperación de “ups”, pero suelen compartir el mismo dominio de fallo. Aún necesitas backups separados (y restauraciones probadas).

6) ¿Cuál es la forma más segura de ejecutar comandos riesgosos en producción?

Haz la identidad inequívoca (by-id), restringe el alcance (ruta/dispositivo exacto), añade un manejador de rollback (snapshot) y exige que un segundo humano valide el objetivo.

7) ¿Por qué las optimizaciones a veces llevan a corrupción después?

Porque algunos cambios de tuning alteran las semantics de durabilidad: orden de escrituras, comportamiento de flush, seguridad de caché o asunciones sobre protección ante pérdida de energía. Puede parecer correcto hasta que un crash lo pruebe.

8) Ejecuté mkfs en la partición equivocada. ¿Hay esperanza?

A veces. Detén las escrituras inmediatamente. No vuelvas a ejecutar mkfs. Captura metadatos y contacta ayuda de recuperación experimentada. Tu éxito depende de qué y cuánto se sobrescribió desde entonces.

9) ¿Cómo evito que los scripts hagan daño estilo “rm -rf /”?

Usa set -euo pipefail, valida variables, exige allowlists explícitas e implementa prompts de confirmación para uso interactivo. Para automatización, usa despliegues por etapas y modos dry-run.

10) ¿Cuál es el hábito más efectivo para evitar arruinadores de fines de semana?

Oblígate a identificar objetivos por identidad estable y a decir el radio de explosión en voz alta (o en el ticket) antes de pulsar Enter.

Conclusión: próximos pasos que realmente reducen el riesgo

Si tomas una cosa de la era “format C:” al ops moderno, que sea esta: los ordenadores son literales y la producción no perdona. Los comandos destructivos no van a desaparecer. La meta es hacerlos deliberados, verificables y recuperables.

Haz esto a continuación:

1. Actualiza los runbooks para usar identificadores estables (/dev/disk/by-id, WWN/serial, UUIDs). Deja de documentar “/dev/sdb” como si fuera un hecho de la naturaleza.
2. Adopta una política obligatoria de snapshot pre-destructivo donde sea técnicamente posible y registra explícitamente las excepciones.
3. Construye un hábito de “detener escrituras” para incidentes de pérdida de datos sospechada. Los primeros cinco minutos deciden si la recuperación será fácil o arqueológica.
4. Separa el tuning de rendimiento de los cambios de durabilidad con una puerta de revisión y un plan de rollback.
5. Practica la recuperación en no-producción: restaurar desde backup, revertir snapshots, importar pools, montar volúmenes. El mejor momento para aprender no es durante una caída de clientes.

Los fines de semana son para dormir, no para mirar una barra de progreso de una restauración mientras reconsideras cada decisión que te llevó a “solo un comando rápido”.