RustFS en Linux: instalación por binario y Docker

Necesitar una API compatible con S3 no significa necesitar alojar los datos en AWS. El RustFS es un servidor de almacenamiento de objetos escrito en Rust: recibe solicitudes de aplicaciones y clientes S3, guarda objetos en discos bajo su control y ofrece consola de administración. En esta guía, vamos a instalar mediante binario con systemd o Docker con Compose, proteger las credenciales y validar el camino completo: crear bucket, enviar, descargar y verificar un archivo.

Referencia de la revisión: 7 de octubre de 2026. Los ejemplos fijan RustFS 1.0.1, release estable publicada en 3 de octubre de 2026. Esto no es promesa de “última versión” permanente. Consulte las notas de la release antes de instalar o actualizar.

Qué es RustFS — y qué no es

A pesar del nombre, no es un sistema de archivos para formatear una partición y montar en lugar de ext4 o XFS. La interfaz principal de este artículo es una API de objetos: cada objeto tiene contenido, clave y metadatos y pertenece a un bucket. Un nombre como backups/servidor1/arquivo.tar es una clave con prefijos; no crea, por sí sola, las mismas operaciones y garantías de un directorio POSIX.

Es útil para aplicaciones que ya hablan S3, entornos de desarrollo, repositorios de artefactos, almacenamiento de datos analíticos y destinos de copia de seguridad compatibles. No sustituyas una carpeta compartida o el disco de una base de datos por un bucket sin verificar el modelo de acceso exigido por la aplicación.

El código del servidor utiliza la licencia Apache 2.0. El self-hosting implica que la capacidad, las actualizaciones, el acceso, la monitorización y la recuperación quedan bajo responsabilidad del operador. El lenguaje Rust es una característica de la implementación, no una garantía de invulnerabilidad ni de rendimiento en tu hardware.

Compatibilidad S3: prueba la aplicación, no solo el logotipo

“Compatible con S3” no equivale a reproducir todos los servicios y comportamientos de AWS. Consulta la matriz de compatibilidad y valida las operaciones que tu aplicación realmente utiliza: multipart upload, URLs firmadas, metadatos, checksums, versionado, políticas y borrado.

El repositorio presenta funciones como versionado, Object Lock, lifecycle, replicación, IAM y cifrado. La disponibilidad de una función no configura por sí sola una política segura: cada una necesita alcance, credenciales y prueba de fallo. Las funcionalidades marcadas como preview no deben tratarse como contrato de producción. Consulta la tabla de funciones del proyecto.

Atención a MinIO: compatibilidad de API y compatibilidad del formato en disco son asuntos distintos. El README consultado sigue clasificando la interoperabilidad on-disk como preview, condicionada a la feature rio-v2, fuera del build por defecto, e informa de limitaciones con objetos cifrados por MinIO. No apuntes RustFS a los únicos discos de producción de MinIO como si solo bastara con cambiar el ejecutable.

Arquitectura: API, consola y persistencia

En los ejemplos, la API S3 atiende en 127.0.0.1:9000 y la consola en 127.0.0.1:9001. Las aplicaciones usan la API; los administradores usan la consola. El almacenamiento debe sobrevivir a la sustitución del ejecutable o del contenedor. La copia de seguridad debe estar en otro dominio de fallo, no en otra carpeta del mismo disco.

Este tutorial se aloja en SNSD. Crear varias carpetas en el mismo disco no genera redundancia física. El proyecto también advierte que SNSD no se amplía directamente a un pool multidisco: planifica otra implementación y migración mediante la API S3. Consulta la selección de topología y el aviso de expansión.

Antes de instalar

• Usa un host de prueba Ubuntu o Debian con systemd, sudo, Bash y arquitectura x86_64 o ARM64.
• Reserva almacenamiento persistente y espacio para objetos, versiones antiguas, cargas incompletas y registros.
• Verifica la sincronización del reloj: la autenticación firmada depende de una hora correcta.
• Mantén el firewall activo. En esta primera etapa, no abras 9000/9001 a internet.
• Elige un de las rutas. No ejecutes el binario y Docker en los mismos puertos ni con el mismo directorio de datos.

La guía oficial recomienda XFS y discos presentados individualmente al sistema para sus implementaciones de almacenamiento; NFS no se indica como backend. La carpeta local utilizada aquí simplifica el laboratorio, no representa un diseño de producción. No hay ningún comando de formateo en este artículo: identificar mal el disco puede destruir datos. Para hardware y clúster, sigue los requisitos previos oficiales.

uname -m
timedatectl status
df -hT
sudo ss -lntp | grep -E ':(9000|9001)\b' || true
sudo apt update
sudo apt install -y ca-certificates curl unzip openssl

Opción A: instalar mediante el binario oficial

1. Descargar una versión fija y validar el SHA-256

El siguiente bloque selecciona el paquete musl de la release 1.0.1 para x86_64 o ARM64. Los SHA-256 se han verificado en los artefactos oficiales de esta release. Al cambiar la versión, actualice también el nombre, la URL y el hash; no elimine la validación.

Ejecute el bloque entero en Bash. Trabaja en una carpeta temporal exclusiva e instala el binario versionado solo si el checksum coincide.

(
set -euo pipefail
VERSION=1.0.1
case "$(uname -m)" in
  x86_64)
    ARCH=x86_64
    SHA256=a834096dafa1f1a55825a2cdaf49d006a193978d344f2d508c2be475133738a3
    ;;
  aarch64|arm64)
    ARCH=aarch64
    SHA256=d2533e293204597416cb8d30790ea35df14cb4521633fa3574c64333141bafdf
    ;;
  *) echo "Arquitetura não coberta por esta receita"; exit 1 ;;
esac
WORK=$(mktemp -d)
trap 'rm -rf -- "$WORK"' EXIT
cd "$WORK"
FILE="rustfs-linux-${ARCH}-musl-v${VERSION}.zip"
curl --fail --location --retry 3 --output "$FILE" \
  "https://github.com/rustfs/rustfs/releases/download/${VERSION}/${FILE}"
printf '%s  %s\n' "$SHA256" "$FILE" | sha256sum --check -
unzip -q "$FILE" -d unpack
BIN=$(find unpack -type f -name rustfs -print)
test -n "$BIN" && test -f "$BIN"
sudo install -d -m 0755 /usr/local/lib/rustfs
sudo install -o root -g root -m 0755 "$BIN" \
  "/usr/local/lib/rustfs/rustfs-${VERSION}"
sudo ln -sfn "/usr/local/lib/rustfs/rustfs-${VERSION}" /usr/local/bin/rustfs
/usr/local/bin/rustfs --version
)

Si la descarga, el checksum o la ubicación del ejecutable fallan, el bloque se detiene. No calcule un nuevo hash del archivo descargado para “corregir” la divergencia. Verifique la arquitectura, la release y el origen. El ejecutable permanece bajo el control de root; quien escribe objetos no necesita poder reemplazarlo.

2. Crear usuario y directorios

En un host nuevo, cree una cuenta dedicada. Si ya existe, inspeccione la instalación previa en lugar de repetir la receta a ciegas.

sudo adduser --system --group --home /var/lib/rustfs \
  --shell /usr/sbin/nologin rustfs
sudo install -d -o rustfs -g rustfs -m 0750 /var/lib/rustfs
sudo install -d -o rustfs -g rustfs -m 0750 /var/lib/rustfs/data
sudo install -d -o rustfs -g rustfs -m 0750 /var/log/rustfs

Si los datos están en un volumen dedicado, móntelo antes de crear el directorio final, compruébelo con findmnt y añada a la unidad una dependencia del punto de montaje. De lo contrario, el servicio podría escribir en el disco raíz cuando el montaje falle. No ejecute chown -R sobre un árbol que contenga datos de otros servicios.

3. Generar credenciales sin contraseña por defecto

Los nombres documentados son RUSTFS_ACCESS_KEY e RUSTFS_SECRET_KEY. No lo confunda con una cuenta IAM de AWS: esas credenciales pertenecen a su RustFS. El valor por defecto público rustfsadmin no debe usarse. La access key de abajo usa hexadecimal en mayúsculas; no contiene la barra que rompería el ámbito de la firma SigV4. Referencia de credenciales.

Este comando falla si el archivo ya existe, para no sobrescribir silenciosamente las claves de una instalación anterior:

sudo bash -euo pipefail <<'ROOT'
test ! -e /etc/default/rustfs
umask 077
{
  printf 'RUSTFS_ACCESS_KEY=%s\n' "$(openssl rand -hex 10 | tr 'a-f' 'A-F')"
  printf 'RUSTFS_SECRET_KEY=%s\n' "$(openssl rand -hex 32)"
  cat <<'ENV'
RUSTFS_ADDRESS=127.0.0.1:9000
RUSTFS_CONSOLE_ADDRESS=127.0.0.1:9001
RUSTFS_CONSOLE_ENABLE=true
RUSTFS_OBS_LOGGER_LEVEL=info
RUSTFS_OBS_LOG_DIRECTORY=/var/log/rustfs
ENV
} > /etc/default/rustfs
chmod 600 /etc/default/rustfs
ROOT

Abra con sudoedit /etc/default/rustfs y guarde las credenciales en el almacén del equipo. No publique el archivo ni copie su salida a tickets. En esta unidad, systemd lee el archivo protegido y entrega el entorno al proceso; el usuario del servicio no necesita leer directamente un archivo root-only.

4. Crear el servicio systemd

La unidad siguiente es una adaptación para nodo único, usuario no root y directorios explícitos. Type=simple indica el inicio del proceso, no la disponibilidad de la API; la disponibilidad se comprobará por separado. Para una introducción a las unidades y los registros, consulte nuestra guía de systemd.

sudo tee /etc/systemd/system/rustfs.service > /dev/null <<'EOF'
[Unit]
Description=RustFS Object Storage
Documentation=https://docs.rustfs.com/en/
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=rustfs
Group=rustfs
WorkingDirectory=/var/lib/rustfs
EnvironmentFile=/etc/default/rustfs
ExecStart=/usr/local/bin/rustfs /var/lib/rustfs/data
Restart=on-failure
RestartSec=5
TimeoutStopSec=120
LimitNOFILE=1048576
UMask=0027
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=full
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF
sudo systemd-analyze verify /etc/systemd/system/rustfs.service
sudo systemctl daemon-reload
sudo systemctl enable --now rustfs
sudo systemctl status rustfs --no-pager
sudo journalctl -u rustfs -n 80 --no-pager

Además del journal, la configuración dirige los registros de la aplicación a /var/log/rustfs; incluya esa ruta en la política de retención de registros. Si la unidad se reinicia repetidamente, deténgala y corrija el error: el reinicio automático no soluciona un permiso denegado, un puerto ocupado o un volumen ausente.

Opción B: instalar con Docker y Compose

Esta es una vía alternativa, no una continuación de la opción A. Utilice Docker Engine actualizado y el plugin Compose. Confirme docker version e docker compose version; si faltan, siga la instalación oficial. El usuario necesita acceso al daemon, privilegio que debe tratarse como administrativo.

El ejemplo fija la etiqueta rustfs/rustfs:1.0.1, persiste datos y registros en volúmenes con nombre y solo publica en loopback. Dentro del contenedor, el proceso debe escuchar en la interfaz interna, no en 127.0.0.1: quien restringe el acceso en el host es el mapeo de los puertos.

1. Crear el proyecto y el archivo de credenciales

umask 077
PROJECT=$(mktemp -d "$HOME/rustfs-lab.XXXXXX")
cd "$PROJECT"
printf '%s\n' "Projeto criado em: $PROJECT"
{
  printf 'RUSTFS_ACCESS_KEY=%s\n' "$(openssl rand -hex 10 | tr 'a-f' 'A-F')"
  printf 'RUSTFS_SECRET_KEY=%s\n' "$(openssl rand -hex 32)"
} > rustfs.env
chmod 600 rustfs.env
printf '%s\n' 'rustfs.env' '.env' > .gitignore

Guarda esta ruta: los comandos de Compose deben ejecutarse en ella. Ábrela rustfs.env localmente para registrar las credenciales en la bóveda. Un archivo de entorno no es cifrado: los usuarios con acceso al daemon pueden inspeccionar el entorno del contenedor. En una operación más sensible, evalúa la inyección mediante archivos RUSTFS_ACCESS_KEY_FILE e RUSTFS_SECRET_KEY_FILE, con los permisos adecuados.

2. Guardar el Compose

Cree el archivo compose.yaml con este contenido:

name: linuxpro-rustfs-lab
services:
  rustfs:
    image: rustfs/rustfs:1.0.1
    restart: unless-stopped
    env_file:
      - ./rustfs.env
    environment:
      RUSTFS_ADDRESS: ":9000"
      RUSTFS_CONSOLE_ADDRESS: ":9001"
      RUSTFS_CONSOLE_ENABLE: "true"
      RUSTFS_OBS_LOGGER_LEVEL: "info"
      RUSTFS_OBS_LOG_DIRECTORY: "/logs"
    command: ["/data"]
    ports:
      - "127.0.0.1:9000:9000"
      - "127.0.0.1:9001:9001"
    volumes:
      - rustfs-data:/data
      - rustfs-logs:/logs
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    stop_grace_period: 2m
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://127.0.0.1:9000/health/ready"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 60s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
volumes:
  rustfs-data:
  rustfs-logs:

Los intervalos, el límite de registros de Docker y el tiempo de parada son decisiones de este laboratorio, no garantías de dimensionamiento. La rotación anterior limita stdout/stderr de Docker; no limita automáticamente los archivos escritos en /logs. Asigna otro nombre al proyecto si linuxpro-rustfs-lab ya existe, para no reutilizar volúmenes por accidente.

3. Levantar y comprobar la imagen

docker compose config --quiet
docker compose pull
docker image inspect rustfs/rustfs:1.0.1 --format '{{index .RepoDigests 0}}'
docker compose up -d
docker compose ps
docker compose logs --tail=80 rustfs

Utilice config --quiet para validar sin imprimir credenciales resueltas. Registra el digest y, si necesitas reproducir exactamente la implementación, sustituye la referencia de imagen por el digest homologado. Un healthcheck unhealthy no hace que Docker reinicie automáticamente un proceso que sigue ejecutándose: hace falta monitorización y una acción definida.

O Dockerfile de la versión usa UID/GID 10001, crea los directorios e incluye curl. Los volúmenes con nombre nuevos heredan la preparación de la imagen; si prefieres bind mounts, prepara únicamente los directorios dedicados:

sudo install -d -o 10001 -g 10001 -m 0750 /srv/rustfs-lab/data
sudo install -d -o 10001 -g 10001 -m 0750 /srv/rustfs-lab/logs

En ese caso, sustituye los orígenes de los volúmenes en el Compose por esas rutas. No mezcles ambos modelos en una instalación con datos sin un plan de migración. En Docker rootless, espacios de nombres de usuario o SELinux, la correspondencia de UID y etiquetas requiere adaptación; no lo resuelvas con chmod 777. Referencia: RustFS con Docker.

Validar la API, la consola y el acceso remoto

Desde el propio host, usa los endpoints documentados:

curl --fail --silent --show-error http://127.0.0.1:9000/health/live
curl --fail --silent --show-error http://127.0.0.1:9000/health/ready
curl --fail --silent --show-error http://127.0.0.1:9001/rustfs/console/health
sudo ss -lntp | grep -E ':(9000|9001)\b'

Liveness verifica el proceso; readiness verifica las dependencias necesarias y puede devolver 503. Ninguno de los dos comprueba que tu usuario pueda escribir un objeto. Abre http://127.0.0.1:9001/rustfs/console/ y entra con las credenciales generadas. La API S3 utiliza 9000; enviar un cliente S3 a 9001 es un error de endpoint. Referencia de puertos y health checks.

Si el servidor es remoto, mantén los puertos cerrados y abre un túnel desde tu ordenador, sustituyendo usuario y host. Los puertos locales tienen que estar libres:

ssh -N -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:9000:127.0.0.1:9000 \
  -L 127.0.0.1:9001:127.0.0.1:9001 usuario@servidor

Con el túnel abierto, el navegador y el cliente S3 en tu ordenador usan las mismas direcciones locales. Esto es adecuado para la administración y la homologación, no sustituye al endpoint HTTPS que las aplicaciones remotas necesitarán usar. Para Docker, consulta también docker compose ps y los mapeos publicados: no todo modo de red aparece como un proceso escuchando en ss.

Prueba S3: crear bucket, subir y comprobar la descarga

Instala la AWS CLI v2 mediante el procedimiento oficial y comprueba aws --version. Usarla como cliente de RustFS no requiere crear una cuenta AWS. Para no mezclar credenciales con perfiles existentes, abre un terminal nuevo y utiliza archivos de configuración aislados:

umask 077
CLIENT_DIR=$(mktemp -d "$HOME/rustfs-client.XXXXXX")
export AWS_CONFIG_FILE="$CLIENT_DIR/config"
export AWS_SHARED_CREDENTIALS_FILE="$CLIENT_DIR/credentials"
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE
unset AWS_DEFAULT_PROFILE AWS_ENDPOINT_URL AWS_ENDPOINT_URL_S3
unset AWS_ROLE_ARN AWS_WEB_IDENTITY_TOKEN_FILE
aws configure --profile rustfs-lab
aws configure set s3.addressing_style path --profile rustfs-lab

Introduce la access key y secret key de RustFS en los prompts, región us-east-1 y formato json. El endpoint explícito a continuación apunta a RustFS local, no a AWS. Usa la credencial administrativa solo en este bootstrap controlado; para la aplicación real, crea una identidad limitada según la siguiente sección. Archivos y perfiles de la AWS CLI.

cd "$CLIENT_DIR"
export AWS_PAGER=""
ENDPOINT=http://127.0.0.1:9000
BUCKET="linuxpro-lab-$(date +%s)"
printf 'Teste RustFS LinuxPro\n' > original.txt

aws --profile rustfs-lab --endpoint-url "$ENDPOINT" s3api create-bucket \
  --bucket "$BUCKET"
aws --profile rustfs-lab --endpoint-url "$ENDPOINT" s3api put-object \
  --bucket "$BUCKET" --key teste/original.txt --body original.txt
aws --profile rustfs-lab --endpoint-url "$ENDPOINT" s3api get-object \
  --bucket "$BUCKET" --key teste/original.txt recebido.txt
sha256sum original.txt recebido.txt
cmp original.txt recebido.txt && echo "Conteúdo idêntico"

El resultado esperado es el mensaje Conteúdo idêntico y hashes iguales. Esto demuestra el contenido de ese objeto en el flujo probado, no la compatibilidad completa del servidor. No uses ETag como sinónimo universal de MD5: multipart y cifrado pueden cambiar su interpretación. Referencias: create-bucket, put-object e get-object.

Reinicie solo la instalación elegida: sudo systemctl restart rustfs o, en la carpeta del proyecto, docker compose restart rustfs. Espere al readiness y repita el GET y el cmp. Para validar la persistencia del contenedor, ejecute después una recreación controlada con docker compose up -d --force-recreate, preservando los volúmenes, y repita la lectura.

Cuando termine, elimine únicamente el objeto y el bucket de esta prueba, que no tenía habilitado el versionado:

aws --profile rustfs-lab --endpoint-url "$ENDPOINT" s3api delete-object \
  --bucket "$BUCKET" --key teste/original.txt
aws --profile rustfs-lab --endpoint-url "$ENDPOINT" s3api delete-bucket \
  --bucket "$BUCKET"

Cierre la terminal de prueba para descartar las variables. Los archivos de credenciales permanecen en el directorio impreso/creado; elimínelos de forma deliberada cuando ya no sean necesarios y revoque las credenciales de prueba. Nunca haga una limpieza recursiva de un bucket real para reproducir el ejemplo.

No uses la credencial root en la aplicación

En la consola, cree un usuario dedicado, una política y, cuando proceda, una service account. La política de ejemplo siguiente permite listar y manipular objetos únicamente en el bucket linuxpro-app. Cree ese bucket administrativamente antes. El nombre del recurso es ilustrativo y debe coincidir con el bucket real.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": ["arn:aws:s3:::linuxpro-app"]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::linuxpro-app/*"]
    }
  ]
}

Es un punto de partida para operaciones simples, no una política universal: multipart, versionado u otras funcionalidades pueden requerir acciones adicionales. Retire la eliminación si la aplicación no la necesita. Adjunte la política al usuario apropiado y pruebe también una operación prohibida, como leer otro bucket. Las políticas de service accounts restringen la identidad padre; no conceden automáticamente privilegios que el padre no tiene. IAM e políticas de RustFS.

TLS antes de abrir la API a la red

HTTP en loopback es válido para el laboratorio; las aplicaciones remotas deben usar HTTPS. RustFS documenta TLS nativo con RUSTFS_TLS_PATH y dos archivos PEM llamados rustfs_cert.pem e rustfs_key.pem. El certificado debe ser válido para el DNS utilizado por los clientes, con una cadena de confianza. No uses --no-verify-ssl como solución permanente. Configuración TLS oficial.

Para el binario, obtenga primero el certificado conforme a la política de la organización. Cópielo a un directorio dedicado, con la clave legible por el servicio y no por todos los usuarios:

sudo install -d -o root -g rustfs -m 0750 /etc/rustfs/tls
sudo install -o root -g rustfs -m 0640 /CAMINHO/fullchain.pem \
  /etc/rustfs/tls/rustfs_cert.pem
sudo install -o root -g rustfs -m 0640 /CAMINHO/privkey.pem \
  /etc/rustfs/tls/rustfs_key.pem
sudoedit /etc/default/rustfs

Sustituye /CAMINHO por los archivos reales. Añada RUSTFS_TLS_PATH=/etc/rustfs/tls. Si se necesitan clientes remotos, cambie el bind de la API a la IP de la interfaz privada elegida y libere ese puerto solo para las redes autorizadas. El console puede permanecer en loopback. Reinicie y pruebe HTTPS con el hostname del certificado. La renovación debe actualizar los archivos copiados e incluir un reinicio controlado; renovar el certificado original no actualiza automáticamente esa copia.

En Docker, monte el directorio de certificados como solo lectura y configure RUSTFS_TLS_PATH a la ruta interna. Garantice lectura al UID/GID 10001 sin hacer pública la clave. El TLS nativo afecta a ambos listeners: cambie también las URLs de los clientes y el healthcheck a HTTPS, usando un hostname compatible con el certificado y la CA correcta. No mantenga el healthcheck HTTP mostrado en el laboratorio después de habilitar TLS.

Si prefieres un proxy inverso, usa un nombre de host dedicado a la API y conserva el Host, la ruta y los parámetros firmados. No añadas un prefijo arbitrario como /s3/: esto puede invalidar firmas. Los límites de subida, los tiempos de espera y el streaming deben homologarse con objetos reales, incluido multipart. La consola y la API tienen políticas de exposición distintas.

Versionado, retención y copia de seguridad son capas diferentes

• Versionado: ayuda a recuperar versiones anteriores, pero aumenta el consumo y exige una política para versiones antiguas.
• Ciclo de vida: automatiza la expiración o la transición; una regla equivocada también automatiza una eliminación no deseada.
• Bloqueo de objetos: añade restricciones de retención; planifica cuidadosamente antes de aplicarlo a datos que posteriormente tendrán que ser eliminados.
• Replicación: puede copiar también errores lógicos, dependiendo de la configuración. No la trates automáticamente como una copia de seguridad independiente.
• Copia de seguridad: necesita un destino separado, credenciales protegidas y una restauración ensayada, incluyendo las configuraciones y claves necesarias para la lectura.

No copie solo archivos visibles del directorio interno con el servicio en ejecución y asuma que eso forma una instantánea consistente. Para portabilidad, use herramientas S3 y verifique lo que preservan: versiones, marcadores de eliminación, políticas, retención y metadatos no acompañan necesariamente a una simple copia de objetos.

O guía de rclone ayuda en la planificación. Haga primero un inventario y copia no destructiva; sync puede borrar lo que solo existe en el destino. Para migración, mantenga el origen intacto hasta validar la aplicación, el recuento, el contenido y el procedimiento de retorno.

Operación: salud, capacidad y actualización

Monitorice el almacenamiento como un servicio de datos: espacio libre, crecimiento, errores de E/S, latencia y errores de la API, fallos de autenticación, subidas incompletas y validez del certificado. En clúster, añada quórum, discos no disponibles, healing y replicación. La salud del proceso no es sinónimo de capacidad de escritura. El cliente oficial rc complementa la consola y las APIs para inspección administrativa.

Para telemetría centralizada, consulte OpenObserve: logs, métricas y traces. Si el objetivo es usar RustFS como almacenamiento de OpenObserve, consulte la guía del servidor dedicado. Son roles diferentes: RustFS guarda objetos; OpenObserve interpreta y consulta telemetría.

Antes de actualizar, lea la release, registre versión y digest, haga copia de seguridad y pruebe la restauración. En la opción binario, instale el ejecutable nuevo junto al anterior, pare el servicio, cambie el enlace y valide readiness y una prueba S3. En la opción Docker, cambie la imagen en el Compose, haga pull y recree preservando volúmenes. Un nodo único tendrá interrupción de servicio.

Rollback no es solo guardar el ejecutable anterior. Si la actualización cambia el estado persistido, volver al binario puede no ser compatible. Confirme la compatibilidad en las notas y mantenga una ruta de restauración. No improvise actualizaciones rolling en un clúster sin entender el quórum y sin esperar a que cada nodo vuelva listo. Procedimientos oficiales de actualización.

Problemas comunes y cómo investigar

Si hay un error de integridad, deje de hacer cambios exploratorios en los discos y conserve logs y copias de recuperación. Borrar metadatos internos para “forzar el arranque” puede empeorar el problema.

Detener el laboratorio sin destruir los objetos

En la opción binario, sudo systemctl stop rustfs el proceso y conserva datos y configuración. En la opción Docker, entre en la carpeta del proyecto y ejecute:

docker compose down

Sin -v, los volúmenes con nombre permanecen. No use docker compose down -v, docker volume prune o exclusión del directorio como rutina de actualización. Estas operaciones pueden destruir la persistencia. La limpieza de datos solo debe ocurrir tras revisar el entorno y decidir explícitamente que es descartable.

Checklist antes de pensar en producción

• Versión y checksum/digest registrados; proceso sin root.
• Credenciales predeterminadas eliminadas e identidad de aplicación restringida.
• API y consola con exposición deliberada; TLS validado sin bypass.
• Discos y volúmenes persistentes identificados y monitorizados.
• Subida, descarga, checksum y lectura tras reinicio aprobados.
• Backup independiente y restauración ensayada.
• Retención, versiones antiguas, multipart y capacidad contabilizados.
• Límites de compatibilidad probados con la aplicación real.
• Topología compatible con los requisitos de disponibilidad.

El mejor comienzo es pequeño, pero verificable: una versión fija, un bucket, un objeto comprobado y una recuperación que funciona. Después amplíe la carga y la arquitectura con evidencias — no porque “S3-compatible” o “escrito en Rust” sustituya a la planificación.

Fuentes oficiales

• RustFS: proyecto y propuesta
• Código, recursos y límites conocidos
• Documentación e instalación
• Release 1.0.1
• Instalación SNSD
• Docker
• Estado y comprobaciones de salud
• TLS
• Actualizaciones