Almacenamiento: bloques, archivos, objetos e integridad de datos

El almacenamiento es la base de estado de casi toda infraestructura: buzones, colas, índices de búsqueda, directorios, bases de datos, máquinas virtuales y copias de seguridad constan de bytes, metadatos y una garantía sobre cuándo los cambios son visibles y duraderos. El medio por sí solo no ofrece esta garantía. La aplicación, la caché del sistema operativo, el sistema de archivos, el gestor de volúmenes, el controlador, la red, los mecanismos de redundancia y la replicación remota conforman conjuntamente la ruta de datos.

Por ello, para los administradores hay tres preguntas más importantes que la capacidad y las IOPS nominales antes de elegir un producto: ¿Qué modelo de acceso ve la aplicación? ¿Qué semántica de commit y consistencia se aplica? ¿Qué ámbitos de fallo sobrevive un cambio confirmado? Solo después pueden evaluarse de forma razonable el rendimiento, la copia de seguridad, el cifrado y los costes.

La explicación sigue una operación de escritura desde la aplicación, pasando por el sistema de archivos o la API de objetos, hasta el volumen, el controlador y el medio. Solo después se comparan la replicación, la consistencia, el rendimiento, el cifrado, la copia de seguridad y la recuperación.

El almacenamiento comienza con una solicitud de escritura de la aplicación y no termina hasta que los datos son duraderos y legibles de nuevo conforme al modelo prometido. Entre ambos puntos se encuentran la caché, el sistema de archivos o la API de objetos, la red, el controlador y el medio. El artículo sigue esta ruta de datos en lugar de limitarse a enumerar tipos de almacenamiento.

Clasificación técnica y ruta de datos

El almacenamiento se clasifica según la interfaz que recibe un consumidor:

• El almacenamiento en bloques direcciona áreas de un dispositivo lógico. El sistema de archivos o la base de datos posee la estructura superior.
• El almacenamiento de archivos expone nombres jerárquicos, directorios, atributos, permisos y operaciones como abrir, leer o renombrar.
• El almacenamiento de objetos direcciona objetos mediante espacio de nombres/bucket y clave; los datos y metadatos se administran mediante operaciones de API.

SNIA describe Block, File y Object Storage como modelos de servicio y acceso diferentes, no simplemente como tres clases de productos (SNIA – Storage Networking Primer). Por ejemplo, una puerta de enlace S3 delante de un sistema de archivos cambia el modelo externo de objetos sin que el almacenamiento interno deba estar necesariamente basado en objetos.

Una ruta de escritura síncrona puede atravesar las siguientes capas:

1. aplicación y tiempo de ejecución con su propio buffering o Write-ahead Log;
2. llamada al sistema, Virtual File System o acceso Raw-Block;
3. Page Cache, sistema de archivos y gestor de volúmenes;
4. capa de bloques del kernel y planificador de E/S;
5. controlador de dispositivo, HBA, protocolo de red o capa de almacenamiento virtual;
6. caché del controlador, capa de redundancia/Erasure Coding y medio;
7. réplicas, journal, Quorum o ubicación remota.

La capa de bloques de Linux documenta colas, solicitudes y topología de dispositivos como una capa propia del kernel (Linux Kernel – Block subsystem). Windows también abstrae por separado los soportes físicos, Storage Pools, discos virtuales, particiones, volúmenes y sistemas de archivos (Microsoft Learn – Storage overview).

Almacenamiento en bloques

El almacenamiento en bloques proporciona un espacio de direcciones lógico lineal. Un LUN SCSI, destino iSCSI, volumen Fibre Channel, espacio de nombres NVMe, disco virtual y volumen en la nube son transportes o implementaciones distintos del mismo modelo básico. El iniciador ve bloques; los nombres de archivo, directorios y, a menudo, la semántica de bloqueo surgen por encima de ellos.

iSCSI encapsula comandos SCSI sobre TCP y separa Discovery/Login, Session y Connections. RFC 7143 define la semántica del protocolo; Multipathing, autenticación, diseño de red y capacidad de clúster del sistema de archivos siguen siendo capas operativas adicionales (RFC 7143 – iSCSI). NVMe se diseñó para almacenamiento no volátil sobre PCIe y utiliza Submission/Completion Queues; NVMe over Fabrics transporta el modelo, entre otros medios, mediante RDMA o TCP (NVM Express Specifications).

Un volumen de bloques no debe montarse simultáneamente con permiso de escritura desde varios hosts utilizando sistemas de archivos locales convencionales. La operación de bloques compartidos requiere un sistema de archivos de clúster o una aplicación con coordinación distribuida propia. «La SAN presenta el LUN a ambos servidores» no constituye un bloqueo de escritura.

Sistema de archivos y VFS

Un sistema de archivos asigna áreas de bloques u otros backends a archivos, directorios y metadatos. El Virtual File System proporciona a las aplicaciones una interfaz común de llamadas al sistema; los sistemas de archivos concretos implementan operaciones, caché y durabilidad de formas distintas (Linux Kernel – Overview of the Linux Virtual File System).

El journaling registra metadatos o también datos para restaurar un estado coherente del sistema de archivos tras un fallo. No es una copia de seguridad y no evita que un cambio funcionalmente erróneo se registre correctamente en el journal. ext4 documenta modos como journal, ordered y writeback; XFS utiliza un journal de metadatos y mecanismos de recuperación propios (Linux Kernel – ext4, XFS Documentation).

Los sistemas de archivos Copy-on-write como Btrfs y OpenZFS escriben los bloques modificados en ubicaciones nuevas y actualizan las referencias. Esto permite snapshots y modelos de sumas de comprobación eficientes, pero exige espacio para nuevos bloques, metadatos y Garbage Collection (Btrfs Documentation, OpenZFS – Basic Concepts).

Archivos remotos: NFS y SMB

NFSv4.1 define un protocolo de archivos remotos con estado, con Sessions, Opens, Locks, Delegations y una operación Compound. La caché del cliente y la recuperación del servidor forman parte del protocolo; un montaje NFS no es simplemente «POSIX local sobre TCP» (RFC 8881 – NFSv4.1).

SMB 2/3 utiliza Credits, Sessions, Tree Connects, Opens y Leases/Oplocks. Microsoft publica la especificación del protocolo; funciones como Multichannel, Transparent Failover, Encryption y Persistent Handles modifican el rendimiento y la semántica de failover (Microsoft Open Specifications – MS-SMB2).

Para archivos remotos se documentan como mínimo:

• resolución de nombres, destino/VIP y puertos;
• autenticación y asignación de identidades, por ejemplo Kerberos, NTLM o UID/GID;
• versión de dialecto/protocolo, opciones de montaje y cifrado;
• comportamiento de caché, bloqueo, lease y failover;
• semántica ante desconexión de red, timeout y recuperación del servidor;
• cuotas, snapshots y responsabilidad de copia de seguridad.

Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,Encrypted,ContinuouslyAvailable
Get-SmbMapping
Test-NetConnection $env:FILESERVER -Port 445
Get-Volume | Sort-Object DriveLetter

findmnt --json | jq '.filesystems[] | select(.fstype | test("nfs|cifs"))'
nfsstat --client
smbclient --list="//$FILESERVER" --use-kerberos=required
nc -vz "$FILESERVER" 445

Get-SmbConnection y Get-SmbMapping muestran dialectos SMB y asignaciones activos; Get-Volume añade la vista de volúmenes locales. findmnt, nfsstat y smbclient comprueban montajes Unix y vistas de protocolos; jq filtra su salida JSON. Test-NetConnection y nc solo prueban la ruta TCP, no la autorización del recurso compartido ni la semántica de E/S.

Almacenamiento de objetos

El almacenamiento de objetos no utiliza manejadores de archivos abiertos en el sentido clásico. Una operación lee, escribe, enumera, copia o elimina un objeto bajo una clave. Las «carpetas» suelen ser prefijos o proyecciones de interfaz. Por ello, un cambio de nombre puede implementarse como copia en el servidor seguida de eliminación. AWS documenta la API S3 como una interfaz orientada a REST sobre buckets, objetos y operaciones (Amazon S3 API Reference).

Las operaciones de objetos tienen sus propios límites:

• Multipart Upload genera partes y un commit final; las cargas interrumpidas requieren limpieza mediante Lifecycle.
• ETag no es universalmente una suma MD5, especialmente en objetos multipartes o cifrados.
• Listing, Versioning, Delete Marker y Lifecycle son estados independientes.
• Las URL prefirmadas delegan una operación concreta hasta su vencimiento y deben tratarse como credenciales.
• Object Lock/WORM requiere un modelo de Retention, Legal Hold, claves y administración.

Amazon S3 documenta consistencia fuerte de Read-after-write y List para PUT y Delete correctos. Esta garantía de producto no se aplica automáticamente a implementaciones compatibles con S3, cachés o gateways superpuestos (Amazon S3 – Data consistency model).

aws s3api head-bucket --bucket $env:BUCKET
aws s3api get-bucket-versioning --bucket $env:BUCKET
aws s3api get-object-attributes --bucket $env:BUCKET --key $env:OBJECT_KEY `
  --object-attributes ETag,Checksum,ObjectSize,StorageClass
rclone size $env:REMOTE

aws s3api head-bucket --bucket "$BUCKET"
aws s3api get-bucket-versioning --bucket "$BUCKET"
aws s3api get-object-attributes --bucket "$BUCKET" --key "$OBJECT_KEY" \
  --object-attributes ETag,Checksum,ObjectSize,StorageClass | jq .
rclone size "$REMOTE"

aws s3api trabaja con operaciones de API S3; los subcomandos mostrados comprueban acceso al bucket, versionado y atributos del objeto. rclone size cuenta objetos y bytes a través de un backend configurado. Ambos muestran la vista de sus credenciales y su endpoint; por ello también se registran la región, la cuenta y el alias.

Ya sea bloque, archivo u objeto: una operación de escritura confirmada debe entenderse en el contexto de la caché y el flush. «Escrito correctamente» no significa el mismo punto de durabilidad física en todas las pilas.

Caché, flush y durabilidad

Una llamada write() correcta puede significar únicamente que los bytes se copiaron a una caché del sistema operativo. Los sistemas tipo POSIX utilizan fsync() o fdatasync() para transferir los datos modificados y los metadatos necesarios al dispositivo. La página de manual de Linux indica que, para un archivo creado recientemente, también puede ser necesario sincronizar el directorio contenedor para que la entrada de directorio sea duradera (fsync(2)).

Por debajo, el controlador y el medio deben implementar correctamente Flush/FUA. Una Write Cache protegida por batería o flash puede conservar escrituras confirmadas ante una pérdida de alimentación; una caché volátil sin protección puede simular rendimiento. La virtualización y el almacenamiento de red prolongan la cadena. El administrador necesita la garantía de commit de extremo a extremo, no solo una casilla activada de «Write Cache».

Las bases de datos usan Write-ahead Logging, sumas de comprobación y protocolos de recuperación porque un commit del sistema de archivos no define una transacción funcional. Un snapshot o una réplica solo es coherente con la aplicación si esta utiliza un mecanismo compatible de Freeze, Backup o posicionamiento de logs.

Consistencia en sistemas de almacenamiento distribuidos

Los sistemas distribuidos replican datos entre procesos y ámbitos de fallo. Una operación puede confirmarse en un nodo, seguir siendo invisible en otro o no poder decidirse ante particiones de red. Los modelos de consistencia describen qué secuencias de observación pueden esperar los clientes. Una visión general de Viotti y Vukolić clasifica modelos fuertes y más débiles basándose en garantías de historial (Consistency in Non-Transactional Distributed Storage Systems).

Los parámetros prácticos son:

• número y ubicación de réplicas o fragmentos de Erasure Coding;
• Quorum de escritura y lectura, así como límite de acknowledgement;
• replicación de ubicación síncrona o asíncrona;
• comportamiento ante Split Brain, pérdida de mayoría y rejoin;
• Repair, Backfill, Rebalance y Scrub;
• garantía de Staleness, Read-after-write y lecturas monotónicas;
• resolución de conflictos y soberanía de datos preferida.

Ceph describe CRUSH como colocación determinista de objetos mediante dominios de fallo jerárquicos y RADOS como base de objetos distribuida para interfaces de bloque, archivo y objeto (Ceph Architecture). La configuración concreta de pool, réplicas, Erasure Coding y Failure Domain determina qué fallos sobrevive realmente el sistema.

La consistencia describe la vista de los datos; la redundancia protege contra el fallo de componentes individuales. RAID y Erasure Coding aumentan la disponibilidad, pero no sustituyen una copia de seguridad independiente.

RAID, Erasure Coding y reconstrucción

RAID combina varios dispositivos para obtener características de disponibilidad o rendimiento. Mirroring mantiene copias completas; RAID con paridad calcula información de redundancia. El trabajo clásico de Berkeley acuñó los niveles RAID como alternativas arquitectónicas (Patterson, Gibson, Katz – A Case for Redundant Arrays of Inexpensive Disks).

Erasure Coding divide los datos en fragmentos de datos y paridad; el objeto puede reconstruirse a partir de una cantidad mínima. Ahorra capacidad frente a la replicación completa, pero aumenta los costes de codificación, red y Repair. Las escrituras aleatorias pequeñas pueden resultar especialmente costosas.

RAID y la replicación no protegen contra:

• eliminación lógica o cifrado por software autorizado;
• corrupción silenciosa que se replica correctamente;
• credenciales comprometidas de administrador o Control Plane;
• fallos fuera del Failure Domain elegido;
• estados incompatibles de software/metadatos;
• pérdida de claves de cifrado.

SNIA describe RAID como un algoritmo de protección de datos sobre varios dispositivos independientes y trata Backup como una técnica de protección separada; por tanto, RAID no implica semántica de copia de seguridad (SNIA – Data Protection Best Practices). Durante Rebuild o Backfill disminuye el margen de seguridad, y pueden aumentar la latencia y la probabilidad de fallos. El progreso, la redundancia restante y la tasa de errores deben monitorizarse.

Snapshots y clones

Un snapshot es una referencia a un estado en un momento determinado. Copy-on-write o Redirect-on-write guarda los cambios posteriores por separado; un clon puede generar una rama escribible a partir de la misma base de bloques. Los snapshots son rápidos y útiles para puntos de recuperación, pruebas y replicación.

Sin embargo, a menudo comparten hardware de almacenamiento, Control Plane, credenciales y ámbito de fallo con la fuente. La pérdida de un pool o un administrador de almacenamiento comprometido puede afectar conjuntamente a la fuente y a los snapshots. Las cadenas de snapshots consumen metadatos y capacidad; eliminar un snapshot antiguo puede desencadenar un trabajo considerable en segundo plano.

La consistencia ante fallos equivale aproximadamente a una pérdida de alimentación abrupta. La consistencia de aplicación requiere Flush, Quiesce, Filesystem Freeze, VSS o una API de Backup específica del producto. Microsoft VSS coordina Requester, Writer y Provider para Shadow Copies coherentes en Windows (Microsoft Learn – Volume Shadow Copy Service).

Sumas de comprobación, Scrub e integridad de extremo a extremo

Las sumas de comprobación solo detectan cambios si existe un valor de referencia fiable y el área comprobada está claramente definida. CRC de transporte, ECC de dispositivo, suma de comprobación del sistema de archivos, suma de comprobación de objeto y hash de aplicación protegen tramos distintos. Un ETag o la hora de un archivo no son una prueba universal de integridad.

OpenZFS almacena sumas de comprobación para datos y metadatos en punteros de bloques superiores y puede detectar y reparar una copia defectuosa si existe redundancia (OpenZFS – Checksums). Btrfs ofrece sumas de comprobación y Scrub en sus dispositivos; Scrub lee datos y metadatos, verifica y repara si existe una copia correcta (Btrfs – Scrub).

Un Scrub supone carga de E/S y requiere ventanas temporales, priorización y alertas. «Scrub completado» solo es significativo si se evalúan los errores no corregibles, los errores reparados, las áreas omitidas y los objetos afectados.

Get-FileHash -Algorithm SHA256 $env:SOURCE_FILE
Get-FileHash -Algorithm SHA256 $env:RESTORED_FILE
Get-StorageReliabilityCounter -PhysicalDisk (Get-PhysicalDisk)
Repair-Volume -DriveLetter $env:DRIVE_LETTER -Scan

sha256sum "$SOURCE_FILE" "$RESTORED_FILE"
smartctl --xall "$BLOCK_DEVICE"
zpool status -v "$ZPOOL"
btrfs scrub status "$BTRFS_MOUNT"

Get-FileHash y sha256sum comparan archivos controlados. Get-StorageReliabilityCounter y smartctl leen datos de estado de los dispositivos; Repair-Volume, zpool status y btrfs scrub muestran perspectivas del sistema de archivos/pool. Estas herramientas solo deben ejecutarse sobre destinos claramente identificados.

Thin Provisioning, Discard y capacidad

Thin Provisioning presenta más espacio lógico que espacio físico asignado. Esto aumenta la utilización, pero introduce un límite de fallo adicional: un host ve espacio libre mientras que el pool o el área de metadatos están agotados. El crecimiento, el consumo de snapshots, las reservas y Reclaim deben monitorizarse conjuntamente (Red Hat – Thinly-provisioned logical volumes).

TRIM/UNMAP/Discard comunica los bloques que ya no se necesitan a las capas inferiores. Que la información llegue hasta el array o backend en la nube depende del sistema de archivos, las opciones de montaje, el hipervisor, el protocolo y el dispositivo. Reclaim puede afectar al rendimiento y a la protección de datos; en volúmenes cifrados, Discard puede revelar patrones de ocupación.

La monitorización de capacidad incluye:

• bytes lógicos y físicos, así como overcommit;
• bloques del sistema de archivos, inodos o número de objetos;
• espacio de snapshots, journal, WAL y metadatos;
• Reserved Space, reserva de Rebuild/Backfill y cuota;
• papelera, Delete Marker, versiones antiguas y restos multipartes;
• crecimiento por clase de datos y momento hasta el agotamiento.

HDD, Flash y NVMe

Los HDD tienen tiempos de posicionamiento mecánicos; la E/S aleatoria y el rendimiento secuencial difieren mucho. Las SSD utilizan Flash Translation Layer, Garbage Collection, Over-Provisioning y Wear Leveling. La amplificación de escritura y la vida útil restante dependen de la carga de trabajo y el firmware. NVMe reduce los cuellos de botella de protocolo y colas, pero no elimina las cuestiones relativas al medio o la durabilidad.

Los valores SMART/NVMe-Health son señales específicas del fabricante, no una garantía. Las advertencias críticas, Media/Data Integrity Errors, Unsafe Shutdowns, temperatura, Spare y Percentage Used se evalúan junto con errores de aplicación y logs del controlador. El proyecto NVMe publica las especificaciones de controladores, gestión y transportes (NVM Express Specifications).

Cifrado y límites de claves

El cifrado de almacenamiento puede realizarse en el medio, el controlador, el volumen, el sistema de archivos, el objeto o la aplicación. Cada capa protege frente a un modelo de amenazas distinto:

NIST SP 800-209 exige para infraestructuras de almacenamiento, entre otros aspectos, control de acceso, administración segura, integridad de datos, cifrado, aislamiento y monitorización como un modelo de seguridad integrado (NIST SP 800-209 – Security Guidelines for Storage Infrastructure).

Key Rotation y Restore se prueban conjuntamente. Una copia de seguridad sin las claves y metadatos válidos en el momento de realizarse no se puede restaurar; una clave exportada sin contexto de IAM/Wrapping puede ser igualmente inútil.

La capacidad por sí sola dice poco sobre el comportamiento de una aplicación. Son decisivas la latencia, las IOPS, el rendimiento y las colas a lo largo de toda la ruta de datos.

Rendimiento: latencia, IOPS, rendimiento y cola

Las IOPS nominales sin tamaño de bloque, mezcla de lectura/escritura, patrón de acceso, Queue Depth, sincronía y percentiles de latencia no son comparables. El rendimiento resulta aproximadamente de IOPS por tamaño de transferencia hasta que predominan los límites de bus, red, controlador o medio. Los aciertos de caché pueden evitar por completo el medio.

Se mide como mínimo:

• latencia de extremo a extremo desde la perspectiva de la aplicación, incluidos p95/p99;
• IOPS y bytes/s separados para lectura/escritura;
• Queue Depth, utilización y tiempo de espera por dispositivo/volumen;
• latencia de escritura síncrona y tasa de Flush;
• aciertos de caché, Dirty Data y Throttling;
• lag de backend/replicación, Rebuild o Garbage Collection;
• errores, reintentos, timeouts y failover de ruta.

fio puede generar cargas de E/S controladas; su documentación advierte implícitamente mediante las flexibles opciones de escritura: un destino incorrecto destruye datos. Las pruebas se ejecutan únicamente sobre archivos de prueba dedicados o dispositivos autorizados con ruta verificada (fio Documentation). DiskSpd de Microsoft es una herramienta de almacenamiento sintética equivalente para Windows (Microsoft DiskSpd).

Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Transfer','\PhysicalDisk(*)\Disk Transfers/sec' `
  -SampleInterval 2 -MaxSamples 15
diskspd.exe -c2G -d30 -r -w30 -b8K -o4 -t2 $env:TEST_FILE
Get-PhysicalDisk | Get-StorageReliabilityCounter

iostat -x -d 2 15
fio --name=controlled-test --filename="$TEST_FILE" --size=2G \
  --rw=randrw --rwmixread=70 --bs=8k --iodepth=4 --runtime=30 --time_based
pidstat -d 2 15

Get-Counter, iostat y pidstat observan carga real. diskspd y fio generan carga sintética y nunca deben dirigirse a dispositivos de bloques en producción ni a archivos sin protección.

Multipathing y Failure Domains

Varios caminos pueden sobrevivir a fallos de controlador, HBA, switch o fabric si son realmente independientes. Multipathing detecta varias rutas hacia el mismo dispositivo lógico y realiza failover o Load Balancing. El número de rutas por sí solo no demuestra redundancia: dos sesiones a través del mismo switch y controlador siguen fallando juntas.

Asymmetric Logical Unit Access puede señalar rutas de controlador preferidas y no preferidas. Los valores de timeout deben ajustarse entre aplicación, sistema de archivos, Multipath, transporte y array; timeouts demasiado cortos provocan fallos falsos y los demasiado largos bloquean las colas.

Get-Disk | Sort-Object Number
Get-PhysicalDisk | Sort-Object FriendlyName
Get-MPIOPath
Get-IscsiSession | Format-List *

lsblk --json -o NAME,KNAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL,WWN | jq .
multipath -ll
iscsiadm -m session -P 3
nvme list -o json | jq .

Get-Disk, Get-PhysicalDisk, Get-MPIOPath y Get-IscsiSession muestran dispositivos y rutas de Windows. lsblk, multipath, iscsiadm y nvme muestran la asignación de Linux, las sesiones y los espacios de nombres. El número de serie, WWN, LUN y punto de montaje se comprueban antes de cualquier cambio.

Clases de almacenamiento en la nube y Lifecycle

El almacenamiento de objetos en la nube ofrece clases con distintos precios, retención mínima, costes de recuperación y tiempos de restauración. Archive puede rehidratarse de forma asíncrona; las Lifecycle Policies pueden mover objetos entre clases o eliminar versiones. Una cifra de capacidad barata sin precio de solicitudes, Retrieval, Egress y duración mínima está incompleta.

AWS documenta Storage Classes junto con patrones de acceso y restricciones; otros proveedores utilizan clases y garantías propias (Amazon S3 Storage Classes). Por ello, para un plan de recuperación se prueban por clase de datos el RPO, RTO, ancho de banda de restauración, tasa de solicitudes, costes de Egress y disponibilidad de claves.

La replicación mantiene más copias para disponibilidad, pero a menudo también propaga errores y eliminaciones. Backup y Archive cumplen objetivos distintos de tiempo e inmutabilidad.

Separar Backup, replicación y Archive

La replicación mantiene disponible una o varias copias de forma síncrona o diferida. Snapshot referencia un momento en el mismo contexto de almacenamiento. Backup crea una copia administrada y restaurable con retención y catálogo. Archive conserva datos a largo plazo conforme a reglas de gobernanza y acceso. Un sistema puede combinar varias funciones; las garantías siguen siendo independientes.

Un plan de protección sólido sigue Backup y recuperación ante desastres e incluye:

• quiescencia de la aplicación o semántica de Backup online específica del producto;
• datos, metadatos, ACL, propietarios, Extended Attributes y claves;
• dominio de errores y administración separado;
• modelo de Retention, Immutability, eliminación y Legal Hold;
• catálogo y dependencias de versiones de software/esquema;
• Restore periódico en un entorno de destino limpio;
• comprobación de integridad y funcional tras el Restore.

Eliminación de datos y fin de vida del medio

La eliminación de archivos u objetos suele retirar únicamente referencias de nombre o metadatos. Snapshots, versiones, réplicas, cachés, copias de seguridad, Flash Translation Layer y medios defectuosos pueden conservar copias. NIST SP 800-88 describe Clear, Purge y Destroy como procedimientos de sanitización distintos según el medio, el nivel de protección y la reutilización (NIST SP 800-88 Rev. 1 – Media Sanitization).

En almacenamiento cifrado, Crypto Erase puede inutilizar el material de claves si todos los datos están protegidos eficazmente con las claves afectadas y no existen copias en texto claro. La jerarquía de claves, Escrow, réplicas y copias de seguridad deben incluirse en la comprobación.

Historia técnica

Los primeros sistemas informáticos conectaban el almacenamiento directamente a un único ordenador. Los protocolos de bloques estandarizados, como SCSI, separaron el host y la función de dispositivo; RAID combinó dispositivos en modelos de rendimiento y redundancia. Las Storage Area Networks mediante Fibre Channel e iSCSI centralizaron volúmenes de bloques, mientras que Network Attached Storage proporcionaba recursos de archivos a través de NFS y SMB.

Los gestores de volúmenes lógicos y los sistemas de archivos Copy-on-write separaron aún más los dispositivos físicos de los volúmenes, snapshots e integridad de datos. Los sistemas de archivos distribuidos y el almacenamiento de objetos escalaron metadatos y datos entre muchos nodos. Las API en la nube convirtieron el almacenamiento en un servicio aprovisionado por solicitud, con Lifecycle, Versioning y facturación basada en el uso.

Flash y NVMe cambiaron los límites de rendimiento: las colas paralelas y las latencias de microsegundos hicieron más importantes la ruta de software, CPU, NUMA y red. Al mismo tiempo, Software-defined Storage y Container Storage Interface abstraen la ubicación física. La pregunta central del administrador no ha cambiado: ¿qué bytes confirmados sobreviven a qué fallo y cómo se repite periódicamente esta comprobación?

Lista de comprobación para administradores

Una autorización de almacenamiento solo se entiende cuando se documentan conjuntamente la confirmación de escritura, la redundancia, el comportamiento ante fallos y la restauración. La tabla resume estas cuestiones operativas independientemente del nombre del producto.

Fuentes

• Linux Kernel – FIEMAP ioctl
• SNIA – Storage Networking Primer
• Linux Kernel – Block subsystem
• Microsoft Learn – Storage overview
• RFC 7143 – iSCSI
• NVM Express Specifications
• Linux Kernel – Virtual File System
• Linux Kernel – ext4
• Linux Kernel – XFS
• Btrfs Documentation
• OpenZFS – Basic Concepts
• RFC 8881 – NFSv4.1
• Microsoft Open Specifications – MS-SMB2
• Microsoft Learn – Get-SmbConnection
• Microsoft Learn – Get-SmbMapping
• Microsoft Learn – Get-Volume
• findmnt(8)
• nfsstat(8)
• Samba – smbclient
• jq manual
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc
• Amazon S3 API Reference
• Amazon S3 – Data consistency model
• AWS CLI – s3api
• Rclone size
• fsync(2)
• Consistency in Non-Transactional Distributed Storage Systems
• Ceph Architecture
• Patterson, Gibson, Katz – A Case for RAID
• SNIA – Data Protection Best Practices
• Microsoft Learn – Volume Shadow Copy Service
• OpenZFS – Checksums
• Btrfs – Scrub
• Microsoft Learn – Get-FileHash
• GNU coreutils – SHA-2 utilities
• Microsoft Learn – Get-StorageReliabilityCounter
• smartctl(8)
• Microsoft Learn – Repair-Volume
• OpenZFS – zpool status
• Btrfs – btrfs scrub
• Red Hat – Thinly-provisioned logical volumes
• NIST SP 800-209 – Security Guidelines for Storage Infrastructure
• fio Documentation
• Microsoft DiskSpd
• Microsoft Learn – Get-Counter
• iostat(1)
• pidstat(1)
• DiskSpd command line
• Microsoft Learn – Get-Disk
• Microsoft Learn – Get-PhysicalDisk
• Microsoft Learn – Get-MPIOPath
• Microsoft Learn – Get-IscsiSession
• lsblk(8)
• multipath(8)
• iscsiadm(8)
• nvme-cli
• Amazon S3 Storage Classes
• NIST SP 800-88 Rev. 1 – Media Sanitization
• Container Storage Interface