Instalación de Raspberry Pi OS en SD: correcto y cómo evitar la corrupción

febrero 26, 2026 • febrero 26, 2026 • Lectura: 26 min • Views: 0

¿Te fue útil?

Nada humilla más a un ingeniero confiado que un Raspberry Pi que “funcionaba ayer” y ahora arranca con el sistema de archivos en solo lectura con la gama emocional de un ladrillo.
El culpable a menudo no es Linux, ni tu aplicación, ni la fase de la luna. Es tu flujo de trabajo con la tarjeta SD: elección del medio, grabación, verificación y la rutina diaria de cortes de energía y pequeñas capas de traducción de flash.

Esta es la forma rigurosa, orientada a producción, de instalar Raspberry Pi OS en una tarjeta SD para que permanezca instalada. Haremos las comprobaciones aburridas que previenen incidencias,
hablaremos de por qué las tarjetas “rápidas” fallan en cámara lenta y construiremos un manual de diagnóstico para cuando el Pi se quede en la pantalla del arcoíris cinco minutos antes de una demostración.

Qué causa realmente la corrupción de la tarjeta SD en un Pi

Las tarjetas SD no son “pequeños SSD”. Son dispositivos flash diminutos con controladores muy variables, firmware inconsistente, bloques de repuesto limitados y una capa de traducción que no puedes ajustar.
Cuando se corrompe un sistema de archivos en un Pi, el sistema de archivos normalmente no es el villano. Es el mensajero. El mensaje es: “una escritura se interrumpió, o el medio mintió”.

Los tres mecanismos de corrupción más comunes

Pérdida repentina de energía durante escrituras de metadatos. ext4 es resistente, pero no puede registrar lo que nunca salió de la caché del controlador.
Un Pi con una alimentación marginal o un pico de carga está practicando ingeniería del caos sin ticket.
Desgaste del medio + controladores débiles. Las tarjetas baratas solo fallan “graciosamente” en la publicidad. En la realidad pueden empezar a devolver errores de E/S,
o remapear bloques en silencio hasta que el rendimiento colapsa y luego la tarjeta pasa a solo lectura o desaparece.
Amplificación de escrituras alta debido al “comportamiento normal de Linux”. Registros, actualizaciones de paquetes, cachés de navegador, swap, telemetría y bases de datos.
El Pi no es amable por defecto; es solo pequeño.

Aquí está la verdad operativa: una configuración de tarjeta SD es fiable cuando diseñas para los modos de fallo, no cuando esperas que tu tarjeta en particular sea “de las buenas”.
La fiabilidad es un flujo de trabajo: elige un medio sensato, graba correctamente, verifica, luego reduce escrituras innecesarias y deja de maltratar la alimentación.

Broma #1: Una tarjeta SD es como un contratista: puede ser rápida, barata o fiable—elige dos, y a veces aún así solo obtienes una.

Datos interesantes y un poco de historia (que afectan tus elecciones)

No necesitas nostalgia para usar un Pi, pero algunos detalles históricos explican por qué las instalaciones modernas de Raspberry Pi OS se comportan como lo hacen.

La SD Association lanzó SD en 1999. Eso es más antiguo que muchas arquitecturas “cloud-native”, y el ecosistema aún arrastra restricciones heredadas.
El wear leveling depende del controlador. Dos tarjetas de 32 GB “idénticas” pueden comportarse distinto porque el firmware del controlador decide cómo remapear y cachear las escrituras.
La “Speed Class” de microSD se diseñó para escrituras secuenciales de vídeo. Ese no es tu tipo de carga. Arrancar Linux son muchas lecturas aleatorias pequeñas más ráfagas de escrituras de metadatos.
Las Application Performance Classes (A1/A2) se introdujeron para I/O aleatorio. A1/A2 están más cerca de lo que necesita un Pi, pero no son una garantía.
Raspberry Pi inicialmente se apoyó en SD porque era barato y accesible. La plataforma creció con flash extraíble como almacenamiento primario, por eso muchos proyectos aún lo asumen.
El journaling de sistemas de archivos se volvió común en Linux por una razón. El journaling de ext4 reduce el dolor de recuperación tras fallos, pero no anula una mala alimentación o un mal medio.
Los modelos modernos de Pi soportan arranque por USB. Eso no es trivia: es tu vía de escape de la fragilidad de la SD cuando pasas a “esto debe funcionar durante un año”.
El flash barato a menudo falla volviéndose de solo lectura. Es un comportamiento protector del controlador cuando ya no puede garantizar escrituras.

Elegir la tarjeta microSD adecuada (endurance, calificaciones A y mentiras)

Comprar una tarjeta SD es como contratar para un rol de fiabilidad usando solo un currículum. Los vendedores te dirán que es “rápida”, “premium” y “gaming”.
Ninguna de esas palabras significa “sobrevive a una base de datos y journald durante 18 meses”.

Qué priorizar

Clase de endurance (High/Max Endurance). Esto importa cuando tienes escrituras pequeñas constantes: logs, métricas, SQLite, actualizaciones de paquetes.
Las tarjetas endurance están diseñadas para dashcams y CCTV: cargas aburridas, escrituras relentizas y mucho tiempo en marcha. Eso eres tú.
Margen de capacidad. Las tarjetas más grandes suelen comportarse mejor porque hay más bloques de repuesto para wear leveling.
Además, ext4 con el filesystem raíz casi lleno rinde y se recupera peor.
Cadena de suministro reputada. Las falsificaciones son comunes. Si el precio es sospechoso, asume que la tarjeta miente hasta comprobarla.
Calificación A1/A2 (con realismo). A1 es una buena línea base. A2 puede ser más rápida, pero algunos hosts no aprovechan completamente y algunas tarjetas hacen cosas raras bajo I/O mixto sostenido.

Qué no optimizar (a menos que te guste depurar)

MB/s secuenciales máximos. Tu Pi arranca leyendo muchos bloques pequeños y escribe muchos bloques pequeños. “170 MB/s” en la etiqueta es más teatro que realidad.
Lo más barato por GB. No estás construyendo un archivo de archivo frío. Estás construyendo un pequeño servidor.
Capacidad ultra pequeña. Aún existen tarjetas de 8 GB. También existen buscapersonas. Ninguno es buen signo.

Regla práctica — recomendaciones

Para proyectos “de juguete”: una tarjeta A1 de marca decente de 32–64 GB, comprada a un vendedor reputado, está bien.
Para “esto ejecuta un servicio”: compra endurance, 64–128 GB, y presupuesta reemplazo como si fuera consumible (porque lo es).
Para “esto importa”: usa arranque por SSD USB si tu Pi lo soporta. Las SD son para conveniencia, no para tu presupuesto de incidentes.

Realidad de alimentación e E/S: tu Pi es un sistema de almacenamiento

La corrupción de SD es con frecuencia un problema de alimentación con una máscara de almacenamiento. El Pi no tiene una caché respaldada por batería. El controlador de la tarjeta SD puede tener caché interno,
pero no controlas su comportamiento de vaciado. Cuando cae el voltaje, las escrituras se interrumpen. A veces lo notas de inmediato. A veces la corrupción aparece después, como moho.

Puntos débiles de alimentación que parecen “cosas raras de Linux”

Subtensión bajo carga. Periféricos USB, ráfagas de Wi‑Fi, picos de CPU, módulos de cámara. El Pi puede experimentar brownout breves sin un bloqueo dramático.
Cables débiles. Una buena fuente con un cable malo es una mala fuente.
Retroalimentación y hubs dudosos. Si tu hub USB hace cosas cuestionables, tu almacenamiento también hará cosas cuestionables.

Si tu Pi está en remoto, o alguien puede desenchufarlo con facilidad, diseña como si el enchufe se fuera a quitar en el peor momento posible. Porque así será.

Grabar Raspberry Pi OS en serio (y verificar)

El fallo de instalación más común que veo no es “imagen mala”. Es “grabamos la imagen en el dispositivo equivocado”, “no verificamos” o “la tarjeta es falsa”.
El paso de grabado es donde estableces confianza en el medio y en el proceso.

Enfoque con opinión

Usa Raspberry Pi Imager cuando quieras la vía más fácil con valores sensatos y verificación integrada.
Usa imagen cruda (dd) solo si también verificas y puedes identificar dispositivos correctamente cada vez, incluso en una estación de trabajo ocupada.
Siempre verifica lo que escribiste usando sumas de comprobación o una comparación de lectura. “Se flasheó correctamente” no es verificación; son impresiones.

También: si flasheas desde Linux y no sabes a qué apunta /dev/sdX, para. Así es como conviertes “instalar Raspberry Pi OS” en “¿por qué mi portátil no arranca?”.

Endurecimiento en el primer arranque: reducir escrituras, mejorar supervivencia

Raspberry Pi OS recién instalado arranca bien en casi cualquier cosa. El problema aparece semanas después: apt updates, logs, swap, cachés de navegador y el entusiasmo registrador de tu aplicación.
El endurecimiento es donde decides si este Pi es un juguete o un aparato.

Movidas de alto impacto para reducir escrituras

Mueve logs volátiles a RAM (o reduce la persistencia de journald).
Desactiva swap en SD si tienes suficiente RAM, o mueve el swap a SSD.
Sé intencional con las bases de datos. SQLite está bien, pero ajústalo y evita tormentas de fsync constantes si no las necesitas.
Mantén espacio libre. Apunta a al menos 20–30% libre en el filesystem raíz para rendimiento y comportamiento de wear leveling.

Cita requerida (idea parafraseada): “Todo falla; el trabajo es diseñar para que las fallas sean sobrevivibles y la recuperación sea aburrida.” — John Allspaw (idea parafraseada)

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

Estas son tareas reales que puedes ejecutar desde una estación de trabajo Linux (para grabar) y desde el Pi (para validación y diagnóstico).
Cada una incluye qué significa la salida y qué decisión tomas a partir de ella. Esa última parte es la diferencia entre “comandos” y “operaciones”.

Task 1: Identify the SD card device correctly (workstation)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TRAN,HOTPLUG,MOUNTPOINTS
NAME      SIZE MODEL            SERIAL        TRAN HOTPLUG MOUNTPOINTS
nvme0n1  953G Samsung SSD 980   S64...        nvme       0 /
sda      931G WDC WD10...       WD-...        usb        0 /media/cr0x/backup
sdb     59.5G USB SD Reader     000000000000 usb        1 /media/cr0x/boot
                                                /media/cr0x/rootfs

Significado: sdb es el lector SD extraíble (HOTPLUG=1) y tiene particiones montadas.
Decisión: Desmontarás y escribirás en /dev/sdb, no en una partición como /dev/sdb1, y definitivamente no en tu disco del sistema.

Task 2: Unmount all SD partitions before imaging (workstation)

cr0x@server:~$ sudo umount /dev/sdb1 /dev/sdb2
umount: /dev/sdb1: not mounted.
umount: /dev/sdb2: not mounted.

Significado: Ya estaban desmontadas o no estaban montadas con esos nombres.
Decisión: Confirma con lsblk que no quedan puntos de montaje; escribir en un dispositivo montado arriesga corrupción y errores de “busy”.

Task 3: Wipe old partition table signatures (workstation)

cr0x@server:~$ sudo wipefs -a /dev/sdb
/dev/sdb: 2 bytes were erased at offset 0x000001fe (dos): 55 aa
/dev/sdb: 8 bytes were erased at offset 0x00000438 (ext4): 53 ef

Significado: Firmas antiguas eliminadas.
Decisión: Haz esto cuando hayas tenido comportamiento extraño de montaje o particiones “fantasma”. Evita que tu OS haga suposiciones incorrectas.

Task 4: Flash Raspberry Pi OS image with dd and show progress (workstation)

cr0x@server:~$ sudo dd if=2025-01-15-raspios-bookworm-arm64.img of=/dev/sdb bs=4M conv=fsync status=progress
1610612736 bytes (1.6 GB, 1.5 GiB) copied, 19 s, 84.8 MB/s
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 53 s, 81.1 MB/s
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 66 s, 81.3 MB/s
1280+0 records in
1280+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 66.1386 s, 81.2 MB/s

Significado: Imagen escrita; conv=fsync fuerza un vaciado al final, reduciendo errores por extracción temprana.
Decisión: No retires la tarjeta todavía; aún necesitas verificar y asegurarte de que el kernel haya asentado.

Task 5: Force the OS to flush disk caches (workstation)

cr0x@server:~$ sync

Significado: Se solicitó vaciado.
Decisión: Después de grabar, siempre sync. Es barato y evita el clásico “lo quité justo después de que dd retornó”.

Task 6: Re-read partition table and confirm partitions appear (workstation)

cr0x@server:~$ sudo partprobe /dev/sdb
cr0x@server:~$ lsblk /dev/sdb
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sdb      8:16   1 59.5G  0 disk
├─sdb1   8:17   1  512M  0 part
└─sdb2   8:18   1  5.0G  0 part

Significado: Existen las particiones de arranque y root esperadas.
Decisión: Si no aparecen particiones, puede que el lector o la tarjeta fallen o que grabaste en el dispositivo equivocado. Para e investiga.

Task 7: Verify the image by comparing bytes (workstation)

cr0x@server:~$ sudo cmp -n 5368709120 2025-01-15-raspios-bookworm-arm64.img /dev/sdb

Significado: Nada de salida significa que los primeros 5,368,709,120 bytes coinciden exactamente (tamaño de la imagen).
Decisión: Si cmp informa una diferencia, no arranques el Pi y “ve qué pasa”. Regraba, prueba otro lector y sospecha de la tarjeta SD.

Task 8: On first boot, confirm undervoltage events (Pi)

cr0x@server:~$ vcgencmd get_throttled
throttled=0x0

Significado: 0x0 indica que no hay flags de estrangulamiento/subtensión desde el arranque.
Decisión: Si ves un valor distinto de cero (común: variantes 0x50000), arregla la alimentación antes de culpar al sistema de archivos. Reemplaza PSU/cable, reduce periféricos o usa un hub con alimentación.

Task 9: Check kernel logs for SD I/O errors (Pi)

cr0x@server:~$ sudo dmesg -T | egrep -i 'mmc|I/O error|ext4|buffer I/O|blk_update_request' | tail -n 30
[Mon Feb  5 10:14:28 2026] mmc0: new high speed SDHC card at address aaaa
[Mon Feb  5 10:14:29 2026] mmcblk0: mmc0:aaaa SU64G 59.5 GiB
[Mon Feb  5 10:14:30 2026] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Quota mode: none.

Significado: Detección y montaje normales.
Decisión: Si ves repetidos I/O error o mmc0: Timeout waiting for hardware interrupt, trata la tarjeta como sospechosa y planea migración.

Task 10: Confirm root filesystem and mount options (Pi)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/mmcblk0p2 / ext4 rw,relatime

Significado: El root está en mmcblk0p2, ext4, montado en lectura-escritura.
Decisión: Si está ro, estás en modo control de daños: revisa errores de fs, la alimentación y la salud de la SD antes de reiniciar servicios que escriban.

Task 11: Check filesystem health and last errors (Pi)

cr0x@server:~$ sudo tune2fs -l /dev/mmcblk0p2 | egrep -i 'Filesystem state|Errors behavior|Last error|Last mount time|Last checked'
Filesystem state:         clean
Errors behavior:          Continue
Last mount time:          Mon Feb  5 10:14:30 2026
Last checked:             Mon Feb  5 10:10:02 2026

Significado: ext4 cree que está limpio.
Decisión: Si el estado no es limpio, programa un fsck controlado desde un arranque de mantenimiento (o desde otro sistema) en lugar de “esperar que el journaling lo arregle”.

Task 12: Measure SD performance with a quick random read test (Pi)

cr0x@server:~$ sudo apt-get update -y
Hit:1 http://deb.debian.org/debian bookworm InRelease
Reading package lists... Done
cr0x@server:~$ sudo apt-get install -y fio
Reading package lists... Done
The following NEW packages will be installed:
  fio
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
cr0x@server:~$ fio --name=randread --filename=/tmp/fio.test --size=256M --rw=randread --bs=4k --iodepth=16 --numjobs=1 --direct=1 --runtime=30 --time_based
randread: (groupid=0, jobs=1): err= 0: pid=2123: Mon Feb  5 10:23:01 2026
  read: IOPS=1450, BW=5664KiB/s (5800kB/s)(166MiB/30001msec)

Significado: ~1450 IOPS en lecturas aleatorias 4k es decente para muchas tarjetas; algunas serán mucho peores.
Decisión: Si ves IOPS de dos dígitos o ancho de banda diminuto, espera arranques lentos y timeouts bajo carga. Reemplaza la tarjeta o pasa a SSD.

Task 13: Check for aggressive logging and persistent journald writes (Pi)

cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.

Significado: Journald ha consumido medio gigabyte.
Decisión: En SD, limítalo. Si este Pi es un quiosco o sensor, probablemente no necesitas logs persistentes ilimitados.

Task 14: Cap journald persistence to reduce SD wear (Pi)

cr0x@server:~$ sudo sed -i 's/^#SystemMaxUse=.*/SystemMaxUse=64M/' /etc/systemd/journald.conf
cr0x@server:~$ sudo systemctl restart systemd-journald
cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 64.0M in the file system.

Significado: Los logs ahora están limitados a 64 MB.
Decisión: Si necesitas retención más larga, envía logs fuera del equipo. SD no es tu SIEM.

Task 15: Confirm swap usage and disable swap on SD if appropriate (Pi)

cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/var/swap file  512M   0B   -2
cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.2Gi       5.8Gi        92Mi       0.9Gi       6.3Gi
Swap:          512Mi          0B       512Mi

Significado: Existe swap pero no se usa; tienes suficiente RAM.
Decisión: Desactívalo para evitar desgaste y picos de latencia. Si estás limitado de memoria, mueve swap a SSD o acepta la compensación conscientemente.

Task 16: Disable swap (Pi)

cr0x@server:~$ sudo dphys-swapfile swapoff
swapon: /var/swap: swapoff failed: Invalid argument
cr0x@server:~$ sudo swapoff -a
cr0x@server:~$ sudo systemctl disable --now dphys-swapfile
Removed "/etc/systemd/system/multi-user.target.wants/dphys-swapfile.service".

Significado: El swap está desactivado y el servicio está deshabilitado.
Decisión: Monitorea la memoria. Si aparecen kills OOM, tomaste la decisión equivocada para esa carga; vuelve a habilitar swap en almacenamiento mejor.

Task 17: Spot a filesystem that remounted read-only (Pi)

cr0x@server:~$ dmesg -T | tail -n 20
[Mon Feb  5 11:02:41 2026] EXT4-fs error (device mmcblk0p2): ext4_journal_check_start:83: Detected aborted journal
[Mon Feb  5 11:02:41 2026] EXT4-fs (mmcblk0p2): Remounting filesystem read-only

Significado: ext4 detectó problemas con el journal y se protegió remontando en solo lectura.
Decisión: Detén los servicios que escriben, captura logs y planea un fsck controlado o una reconstrucción. Continuar en caliente convertirá lo “recuperable” en un misterio.

Broma #2: La tarjeta SD no “murió aleatoriamente”. Leyó tu objetivo de uptime y eligió violencia.

Guion rápido de diagnóstico

Cuando el Pi es lento, inestable o está corrompiendo datos, no tienes tiempo para depuración filosófica.
Necesitas una secuencia corta que encuentre el cuello de botella con alta probabilidad. Aquí está el guion que uso.

Primero: alimentación y subtensión (más rápido de probar, más común)

Ejecuta vcgencmd get_throttled. Si es distinto de cero, arregla la alimentación primero.
Revisa dmesg -T | grep -i voltage por advertencias de subtensión (no siempre presentes en todas las configuraciones).
Decisión: cambia PSU y cable antes de cambiar tarjetas SD. Problemas de alimentación pueden corromper una tarjeta nueva en horas.

Segundo: errores de almacenamiento (timeouts de E/S, remounts, solo lectura)

Ejecuta dmesg -T | egrep -i 'mmc|I/O error|timeout|ext4'.
Ejecuta findmnt -no OPTIONS / para ver si estás en ro.
Decisión: si ves timeouts mmc o abortos ext4, deja de tratarlo como “software”. Planea reimagen o migración.

Tercero: cuello de botella de rendimiento (arranques lentos, timeouts de servicios)

Mide con fio (lectura/escritura aleatoria, dataset pequeño).
Revisa los mayores generadores de escrituras: sudo iotop (si está instalado), o usa sudo journalctl --disk-usage y logs de aplicaciones.
Decisión: si el I/O aleatorio es terrible, reemplaza la tarjeta o pasa a SSD; no puedes afinar un controlador lento.

Cuarto: integridad del sistema de archivos (solo tras comprobar alimentación y hardware)

Comprueba el estado de ext4 con tune2fs -l.
Si debes reparar: hazlo offline o desde modo recovery cuando sea posible, no mientras el sistema está a medias funcionando.
Decisión: si la corrupción es recurrente, reconstruye el sistema y arregla la causa upstream (alimentación, medio, carga de escritura). Repetir fsck no es una estrategia.

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

1) Síntoma: “Sistema de archivos en solo lectura” después de un reinicio

Causa raíz: journal de ext4 abortado por errores de E/S o pérdida súbita de energía; el kernel remontó el root en solo lectura para evitar más daños.
Solución: Revisa dmesg por errores ext4/mmc; arregla la alimentación; ejecuta fsck offline; reemplaza la tarjeta SD si existen errores de E/S.

2) Síntoma: El Pi arranca a veces, en otros se queda colgado

Causa raíz: contactos marginales en la SD/lector, tarjeta falsa o alimentación límite que causa fallos de temporización durante la inicialización de la SD.
Solución: Prueba con otra tarjeta y un lector conocido bueno; reduce periféricos; usa PSU/cable oficiales; confirma flags de subtensión.

3) Síntoma: “Kernel panic” o “VFS: unable to mount root fs”

Causa raíz: sistema de archivos raíz corrupto, imagen equivocada (desajuste 32-bit vs 64-bit es ahora más raro), o errores de lectura de SD.
Solución: Regraba y verifica con cmp; comprueba sha256sum si tienes un hash conocido; reemplaza la tarjeta si la verificación falla.

4) Síntoma: las actualizaciones apt son extremadamente lentas y a veces fallan

Causa raíz: pobre rendimiento de escritura aleatoria; la SD se convierte en cuello de botella al desempaquetar dpkg y en operaciones fsync-intensivas.
Solución: Usa una mejor tarjeta A1/A2 o endurance; mueve root a SSD si es un dispositivo de servicio; reduce escrituras en segundo plano.

5) Síntoma: la tarjeta SD de repente muestra menor capacidad o particiones raras

Causa raíz: tarjeta falsificada con capacidad falseada, o tabla de particiones dañada por extracción insegura.
Solución: Regraba desde cero; valida la capacidad con una herramienta de escritura completa en una estación de trabajo; compra en fuentes reputadas.

6) Síntoma: el rendimiento empeora en semanas y luego aparecen errores

Causa raíz: el wear leveling se queda sin bloques de repuesto; el controlador lucha, causando picos de latencia y fallos eventuals.
Solución: Reemplaza la tarjeta proactivamente; mantén más espacio libre; cambia a media endurance; mueve cargas intensivas de escritura a SSD.

7) Síntoma: corrupción de base de datos (SQLite, etc.) después de cortes

Causa raíz: pérdida de energía durante transacciones de escritura; a veces se agrava por ajustes de fsync inapropiados o caché agresiva en el controlador.
Solución: Arregla la alimentación; usa un UPS o un HAT con supercondensador si es necesario; ajusta la durabilidad de la DB con conocimiento; considera mover la BD a SSD.

8) Síntoma: “No space left on device” aunque crees tener espacio

Causa raíz: crecimiento de logs, crecimiento del journal, o bloques reservados; las tarjetas pequeñas se llenan silenciosamente y luego fallan ruidosamente.
Solución: Inspecciona uso de disco; limita journald; rota logs; redimensiona el filesystem; usa tarjetas más grandes y mantiene margen.

Listas de comprobación / plan paso a paso

Checklist A: Flujo de instalación fiable en tarjeta SD (estación de trabajo)

Inserta el lector SD; ejecuta lsblk; identifica el dispositivo extraíble por tamaño y HOTPLUG.
Desmonta particiones: sudo umount /dev/sdX*.
Opcional si has tenido rarezas: sudo wipefs -a /dev/sdX.
Graba:
- Preferido: Raspberry Pi Imager con verificación habilitada.
- Manual: sudo dd if=image.img of=/dev/sdX bs=4M conv=fsync status=progress.
Vaciar: sync.
Verificar: sudo cmp -n $(stat -c%s image.img) image.img /dev/sdX (o calcula hashes si tienes una referencia conocida).
Expulsar limpiamente; luego retirar.

Checklist B: Endurecimiento en el primer arranque (Pi)

Confirma salud de la alimentación: vcgencmd get_throttled.
Revisa errores de almacenamiento: dmesg -T | egrep -i 'mmc|I/O error|ext4'.
Actualiza paquetes (sí, házlo): sudo apt-get update y sudo apt-get upgrade. Luego reinicia.
Limita journald: establece SystemMaxUse=64M (o similar) si los logs persistentes no son esenciales.
Decide sobre swap: si tienes RAM, desactiva swap en SD; si no, mantenlo y acepta desgaste, o muévelo a SSD.
Mantén margen: no ejecutes el filesystem raíz al 95% y te sorprendas de su mal comportamiento.

Checklist C: Postura operacional para Pis “que no deben fallar”

Elige media endurance o pasa a arranque por SSD.
Compra dos tarjetas idénticas; guarda una como repuesto probado con imagen lista para intercambiar.
Implementa backups (incluso si solo es rsync de datos críticos a otro host).
Monitorea flags de subtensión y eventos de remount de sistemas de archivos.
Planifica reemplazos: trata las tarjetas SD como consumibles con ciclo de vida.

Tres micro-historias del mundo corporativo (anonimizadas, plausibles y educativas)

Micro-historia 1: El incidente causado por una suposición errónea

Un equipo desplegó una flota de Raspberry Pis como colectores de borde para sensores ambientales. El software era sólido: uso de CPU moderado, un pequeño buffer local
y cargas periódicas hacia arriba. Hicieron un piloto con cinco dispositivos y funcionó durante semanas.

El despliegue a unas pocas docenas de unidades empezó bien. Luego, a las dos semanas, unidades aleatorias empezaron a desconectarse. No todas a la vez. Una aquí, otra allá.
La rotación de on-call tuvo la divertida tarea de conducir a sitios remotos para reimaginar tarjetas SD.

La suposición errónea fue sutil: “Si el Pi arranca, la alimentación está bien.” Habían usado bricks USB commodity y cables largos dentro de las cajas.
Bajo carga normal el Pi estaba bien. Bajo ráfagas de transmisión del módem celular (y algo de comportamiento de cable en clima frío), la tensión caía lo suficiente para causar interrupciones de escritura.
el replay del journal de ext4 enmascaró parte; otras veces remontó en solo lectura.

La solución no fue exótica: PSU oficiales, cables más cortos y una comprobación básica en su script de aprovisionamiento que registraba vcgencmd get_throttled y rechazaba el estado “verde” si alguna vez marcaba.
Las tarjetas SD dejaron de “fallar”. El software dejó de ser culpado por la ingeniería eléctrica.

La lección: trata la alimentación como parte del subsistema de almacenamiento. Porque lo es.

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

Otro grupo operaba Pis como quioscos. Querían arrancar más rápido y “menos desgaste de disco”, así que alguien propuso montar root con opciones agresivas:
intervalos de commit más largos, barreras reducidas y otros ajustes sacados de un post de foro escrito con el tono confiado de quien nunca ha tenido que responder a un pager.

Los quioscos arrancaron más rápido. Eran más ágiles. El equipo declaró victoria y desplegó el cambio ampliamente.
Luego ocurrió el primer parpadeo de energía. Un paquete de quioscos arrancó con estado de aplicación inconsistente, y un puñado con sistemas de archivos sin limpiar que requirieron intervención manual.
“Pero reducimos escrituras”, dijeron. Sí. Y también redujiste la durabilidad.

El postmortem fue incómodo pero productivo. La optimización no era mala; estaba mal aplicada.
Tocar ext4 para rendimiento relajando garantías de vaciado es un trade-off. Si además tienes energía impredecible, simplemente cambiaste integridad por velocidad sin comprar la otra mitad del trato (estabilidad de alimentación).

Revertieron las opciones de montaje más riesgosas, movieron las cachés que más amplificaban escrituras a tmpfs y dedicaron tiempo a mejorar la calidad de la alimentación.
El tiempo de arranque aumentó ligeramente; la tasa de incidentes cayó drásticamente.

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

Un equipo pequeño de plataforma mantenía unos pocos Pis para automatización de laboratorio: rigs de prueba, setups hardware-in-the-loop y algunas sondas de red.
Nada glamuroso, pero la gente dependía de ellos. El equipo tenía una política que parecía casi cómicamente anticuada: cada Pi tenía una tarjeta SD “imagen dorada” conocida como buena,
y cada cambio al OS se capturaba en un paso de aprovisionamiento corto y scriptado.

Un lunes, tras un evento de mantenimiento eléctrico en el edificio, varios Pis del laboratorio no arrancaron. Comenzó el pánico habitual: “¿La actualización rompió algo?”
Pero el equipo no debatió. Cambiaron las tarjetas por las doradas, restauraron la configuración más reciente desde su script y volvieron al servicio rápidamente.

Las tarjetas corrompidas se analizaron después con calma. Resultó ser una mezcla: una tarjeta genuinamente desgastada y un par de sistemas de archivos que necesitaron reparación.
El punto clave: la recuperación fue rápida porque la instalación era repetible. No necesitaron heroísmo ni genio forense a las 9 a.m.

La práctica aburrida era simplemente: repuestos probados, aprovisionamiento scriptado y aceptar que las tarjetas SD son consumibles.
Salvó el día precisamente porque no era ingenioso.

Preguntas frecuentes

1) ¿Debo usar Raspberry Pi Imager o dd?

Usa Raspberry Pi Imager a menos que tengas una razón para no hacerlo. Maneja personalización y puede verificar escrituras.
Usa dd cuando necesites automatización y seas disciplinado con la verificación y la selección del dispositivo.

2) ¿Qué sistema de archivos usa Raspberry Pi OS, y debería cambiarlo?

Comúnmente ext4 para root, FAT32 para boot. ext4 está bien y bien probado. Cambiar el sistema de archivos no rescatará una mala alimentación o medio,
y a menudo añade complejidad sin beneficio medible en SD.

3) ¿A2 siempre es mejor que A1 para Raspberry Pi?

No siempre. Las tarjetas A2 pueden requerir funciones del host para alcanzar su mejor rendimiento, y algunas combinaciones se comportan de forma extraña con I/O mixto.
Las tarjetas A1 endurance son frecuentemente la opción “aburrida y buena”. Si te importa, haz benchmarks en tu modelo real de Pi.

4) ¿Cómo sé si mi tarjeta SD es falsificada?

Señales: reporte de capacidad inconsistente, fallos de verificación/compare tras flashear, errores de I/O tempranos en vida y rendimiento muy por debajo de lo esperado.
La mitigación más fiable es comprar en fuentes reputadas y verificar imágenes escritas con cmp.

5) ¿Por qué mi Pi remonta root repentinamente en solo lectura?

Porque el kernel vio errores que hacen arriesgado seguir escribiendo: journal ext4 abortado, errores de E/S o timeouts.
Trátalo como síntoma de fallo de medio o de alimentación inestable, no como “humor de Linux”.

6) ¿Puedo simplemente ejecutar fsck y seguir?

Puedes, a veces. Pero si la corrupción se repite, fsck está tratando la contusión mientras sigues golpeando el mismo punto.
Arregla la alimentación, reduce la carga de escritura y reemplaza la tarjeta si aparecen errores de E/S.

7) ¿Cuál es la mejor manera de evitar la corrupción en SD?

Usa alimentación estable y evita escrituras innecesarias. Si quieres una “mejora”, pasa a arranque por USB SSD en modelos de Pi soportados.
Eso cambia todo el perfil de fiabilidad.

8) ¿Debo desactivar el journaling para reducir escrituras?

No, no en sistemas que te importan. Desactivar journaling puede reducir escrituras pero aumenta el riesgo de inconsistencia catastrófica tras un fallo.
Mejor: limita logs, mueve cachés a RAM y usa media endurance.

9) ¿Cuánto espacio libre debo mantener en la tarjeta SD?

Mantén al menos 20–30% libre en root para salud y rendimiento a largo plazo. Los filesystems casi llenos se comportan mal,
y el wear leveling del flash se beneficia del espacio sobrante.

10) Mi carga es “liviana”. ¿Aún necesito tarjetas endurance?

Si “liviana” significa un sensor sin cabeza que escribe un archivo pequeño una vez por hora, probablemente no.
Si “liviana” significa “ejecuta Linux con logs, actualizaciones y una base de datos”, entonces sí, la endurance compensa.

Siguientes pasos que puedes hacer hoy

Si quieres un Raspberry Pi basado en SD que se comporte como un aparato, haz lo siguiente en orden:

Compra media sensata: microSD endurance, 64–128 GB, fuente reputada. Tu tiempo vale más que la diferencia de precio.
Graba y verifica: usa Raspberry Pi Imager con verificación, o dd + cmp. Sin excepciones.
Arregla la alimentación: PSU oficial y buen cable; confirma que vcgencmd get_throttled permanezca limpio bajo carga.
Reduce escrituras: limita journald, desactiva swap en SD si es factible, mantiene espacio libre y no ejecutes servicios ruidosos que no necesites.
Prepárate para fallos: ten una tarjeta de repuesto probada (imagen dorada) y un procedimiento de restauración que no requiera inspiración.

Haz eso y las tarjetas SD dejarán de ser misteriosas. Volverán a ser lo que siempre fueron: un componente consumible en un sistema que operas deliberadamente.