Sistemas de archivos y sincronización

Resumen breve

Un sistema de archivos es un equilibrio entre integridad, rendimiento y operaciones. La sincronización es sobre el modelo de consistencia y resolución de conflictos, no sólo «copiar archivos». Comenzamos con los requisitos (p95 latency, RPO/RTO, tipo de carga), seleccionamos FS y protocolo, configuramos el registro y los bloqueos, establecemos SLO, automatizamos los snapshots/versioning y utilizamos herramientas de sincronización correctas.

Seleccionar un sistema de archivos bajo carga

FS Linux versátil

ext4 es un «caballo de trabajo» estable. Opciones: 'noatime, nodiratime, discard (con precaución), data = ordered'. Bueno para discos VM, directorios compartidos, artefactos CI.
XFS - fuerte en archivos grandes/paralelismo (contenido de medios, registros, DWH). Opciones: 'noatime, inode64'; para los archivos grandes vale la pena configurar 'reflink = 1' (clone).
ZFS - CoW, comprobación de integridad, snapshots/réplica 'nat/recv', ARC/L2ARC, ZIL/SLOG para sync. Excelente para backups, NAS, pools básicos que requieren integridad.
Btrfs - CoW, snapshots/compresión/RAID en userspace; bien bajo dev/test y edge, más cuidado para OLTP sin afinación.

Windows/multiplataforma

NTFS - ACL, ADS, es confiable para SMB; 'DisableLastAccess' para rendimiento.
exFAT - medios extraíbles, sin derechos y sin registro (no para el mdd).

Ajustes que afectan la fiabilidad y la velocidad

Registro y barreras: 'data = ordered' (ext4 por defecto) - balance; 'data = journal' - más seguro pero más lento; asegúrese de que los barriers de escritura están habilitados (o un controlador con BBU/PLP).
fsync/sync: los flujos críticos (registros/transacciones) deben llamar explícitamente a 'fsync ()'; de lo contrario, la pérdida en el accidente es posible.
atime: 'relatime '/' noatime' reduce la presión de escritura.
xattr/ACL: habilite si necesita una ACL POSIX y etiquetas de seguridad.
Tamaño de bloque/tamaño de grabación: ZFS 'recordsize = 16K' para BD; '1M' para grandes medios.

Ejemplos de montaje:

bash ext4 for CI artifacts
UUID=... /var/lib/ci ext4 noatime,nodev,nosuid,data=ordered 0 2
XFS for Media Directories
UUID=... /srv/media xfs noatime,attr2,inode64 0 0
ZFS for backups and snapshots (creation)
zpool create tank mirror nvme0n1 nvme1n1 zfs set compression=lz4 atime=off tank/backups

Sistemas de archivos distribuidos y de red

NFS/SMB (enfoque NAS)

NFSv3/v4: simple y rápido; v4 da bloqueos y Kerberos ('sec = krb5p'). No confíe en NFS para fsync «profundo» de alta frecuencia - mejor disco local + descarga asíncrona.
SMB 3. x: multichannel, cifrado, integración con AD. Habilite la firma/cifrado en datos sensibles.

Exportación de NFS (mínimo):


/pool/projects 10. 0. 0. 0/16(rw,no_root_squash,sec=krb5p,async)

SMB (fragmento):


[reports]
path = /pool/reports read only = no vfs objects = acl_xattr, recycle smb encrypt = required

FS distribuidos

CephFS - POSIX sobre Ceph; bueno para la escala horizontal, snapshots, quouts, metadatos distribuidos.
GlusterFS: fácil de iniciar, réplica/charding, pero cuidadosamente con archivos pequeños y p99.
Lustre/IBM Spectrum Scale - PMA/archivos grandes, exigentes para la red/operaciones.
9P (Virtio-fs) - para Sharing VM, no para cargas prod con SLO rígidos.

Recomendación: para OLTP/monederos - no red FS; use volúmenes de bloques. Para contenido estático/artefactos compartidos - NFS/SMB/objeto + CDN.

Bloqueos, almacenamiento en caché y consistencia

Advisory vs mandatory locks: Linux обычно advisory; SMB soporta oplocks/leases, NFSv4 es stateful locks.
Almacenamiento en caché del cliente: los cachés agresivos aceleran la lectura, pero con múltiples clientes aumentan el riesgo de conflictos.

Coherencia:

Strong (FS locales, ZFS).
Close-to-open (NFS): los cambios son visibles cuando 'close ()/open ()'.
Eventual (algunos scripts distribuidos/de objetos).
Reloj: NTP/PTP; la deriva del tiempo rompe el conflicto-resolve y TTL.

Sincronización: modelos y herramientas

One-way (push/pull): publicación de artefactos, descarga de informes, copia de seguridad offsite.
Dos caminos (bi-dir): colaboración; se requiere una solución de conflicto y versionamiento.
Hub-and-spoke: estrella a través de un nodo/clúster central (MinIO/S3 + agentes).
Near-real-time vs batch: inotify/logs de cambios vs ventanas periódicas.

rsync es el estándar de facto de una vía; '--delete', '--partial', '--inplace' (cuidado).
rclone - S3/cloud, comprobación de hash, servidor-side copy.
Unison - true bi-directional, resolución de conflictos.
Syncthing - p2p, versioning, conveniente para carpetas de trabajo.
lsyncd es el disparador rsync por inotify; near-real-time.
ZFS nat/recv es el «azul» perfecto de los snapshots/incrementos (de forma eficiente).

rsync (one-way, publicación de un catálogo estático):

bash rsync -az --delete --numeric-ids --partial --inplace \
/srv/builds/ user@edge:/var/www/builds/

Unison (bi-dir, perfil):


root =/srv/shared root = ssh ://user @ peer//srv/shared prefer =/srv/shared # in case of conflict - local side repeat = watch # inotify ignore = Name. tmp

lsyncd (near-real-time encima de rsync):

lua settings { logfile="/var/log/lsyncd. log", statusFile="/var/run/lsyncd. status" }
sync {
default. rsync,
source="/srv/outbox",
target="user@remote:/srv/inbox",
rsync={ archive=true, compress=true, delete=true }
}

ZFS réplica (incremento):

bash zfs snapshot tank/data@now zfs send -i tank/data@prev tank/data@now      ssh backup zfs recv -F backup/data

Versificación, snapshots y «cestas»

Snapshots CoW (ZFS/Btrfs/CephFS): puntos de reversión rápidos, min.
Versificación a nivel de aplicación (Nextcloud/Syncthing/Object): fácil de usar.
Cestas/reciclados en SMB/NFS: salvan de la eliminación accidental, pero no reemplazan el respaldo.

Seguridad

ACL y xattr: POSIX ACL, SID/ACE para SMB, mapping uid/gid.
Lectura/escritura a través de gateways: SFTP/HTTPS/WebAMB - cuando no se puede abrir SMB/NFS hacia fuera.
Cifrado: LUKS/ZFS nativo; en vuelo - Kerberos (NFSv4), cifrado SMB, TLS para gateways.
PII/cumplimiento: segmentación de bolas, máscaras de derechos estrictos, auditorías de acceso, WORM donde se necesita sin cambios.

Observabilidad, SLO y alertas

Метрики ФС: p95/p99 latency (read/write/open), IOPS, qdepth, cache hit, inode usage, fill-level, errors (EIO/ENOSPC).
Métricas de red (NFS/SMB): retransmits/drops, RPC RTT, oplock breaks, queue length.

SLO (ejemplos):

Bola NFS CI: p95 'open '/' read' ≤ 3-5 ms, disponibilidad ≥ 99. 95%.
Informes SMB: p95 listado de directorio ≤ 100 ms al ≤ 10k archivos/dirs.
ZFS pool backups: p99 grabación ≤ 10 ms, éxito de snapshots 100%, RPO ≤ 15 min (incrementos).

Alertas:

Llenado de pool> 80/90/95%, crecimiento de 'EIO', trampolín, caída de hit-ratio, oplock-break frecuente.

Patrones para el producto (iGaming/Fintech)

Estática (iconos/preview/directorios de proveedores): publicación a través de rsync → CDN; almacenar la fuente original en un objeto con versionamiento.
Registros y eventos «crudos»: escribir localmente (XFS/ext4) → descargar batchevo (rclone → S3/MinIO).
Informes y PII: SMB con cifrado y ACL estrictas; offsite-exportación periódica (ZFS nat/recv) con WORM en el lado receptor.
Medios Dev y fijación de artefactos: NFS/SMB para sharing; para bases pesadas - volumen de bloque + snapshots.
Colaboración de contenido: Sincronización/Nextcloud con versionados y cuotas.

Lista de comprobación de implementación

Se han definido clases de datos (caliente/frío/PII), RPO/RTO y SLO.
FS seleccionado: ext4/XFS/ZFS con opciones correctas (noatime, barriers, recordsize).
Si NAS: NFSv4/SMB con cifrado/firmas, ACL, Kerberos/AD.
Snapshots/versioning/cestas - configuradas y verificadas por recuperación.
La herramienta xinka bajo la tarea: rsync (one-way), Unison/Syncthing (bi-dir), rclone (cloud), ZFS nat/recv (backup/DR).
Monitoreo de FS/redes/operaciones, burn-rate SLO, alertas ENOSPC/EIO/oplock.
Documentación: Runbook de conflictos, reglamento fsync, política de nombres/longitudes de rutas/codificaciones.
Pruebas: perfiles de carga (archivos pequeños/grandes), secuencias de comandos (ruptura de comunicación, conflicto de edición).

Errores

Bola de red compartida para transacciones críticas (OLTP) en lugar de un volumen de bloque local.
Barriers desactivados/no fsync en la aplicación → pérdida de datos al fallar.
El azul de dos vías sin versionar y de un solo tiempo → cambios «devorados».
Online 'discard' en la piscina caliente → cola de latencia.
Millones de archivos pequeños en un solo directorio → catastrófico listado/copia de seguridad.
Mezcla de derechos/propietarios entre SMB y NFS sin mapeo explícito.

Minibuses

One-way build → edge servers

1. Conjunto en '/srv/builds '(FS local). 2) `rsync -az --delete` на edge. 3) Discapacidad CDN.

Bi-dir directorio de trabajo de analistas

1. Syncthing/Unison, «versioning N days», el conflicto es guardar ambas versiones. 2) Cuotas por usuario. 3) Ocasional offsite-back.

Directorio de informes DR (WORM)

1. ZFS Snapshots está programado. 2) 'nat/recv' en un host aislado con Object Lock/WORM. 3) Prueba de recuperación mensual.

Resultado

Un subsistema de archivos fiable es el FS correcto + modos de registro/barreras correctos + un modelo de bloqueo comprensible, y la sincronización efectiva es la topología correcta (one-way/bi-dir), la versificación y las herramientas probadas. Capture soluciones en runbook-ah, automatice snapshots/replicación, mida SLO y pruebe scripts fallidos, de modo que los datos permanezcan intactos y los procesos operativos sean predecibles incluso bajo cargas máximas.