S3QL guarda los datos de su sistema de archivos en un backend, que puede ser un servicio de objetos o una ruta local. La URL de almacenamiento determina el backend y forma parte de la identidad del sistema de archivos, por lo que conviene elegirla con cuidado antes de inicializarlo [1].
Esta guía resume los formatos actuales más comunes y cómo guardar las credenciales. Los nombres de bucket, endpoints y secretos de los ejemplos son ficticios: usa los valores documentados por tu proveedor.
Formatos de URL compatibles
La documentación actual de S3QL incluye estos backends [1]:
| Backend | Formato de URL | Cuándo usarlo |
|---|---|---|
| Amazon S3 | s3://<region>/<bucket>/<prefijo> | Buckets de Amazon S3. |
| S3 compatible | s3c4://<host>:<puerto>/<bucket>/<prefijo> | Servicios que exponen una API compatible con S3 y permiten indicar su endpoint. |
| Google Cloud Storage | gs://<bucket>/<prefijo> | Buckets de Google Cloud Storage; no es Google Drive. |
| OpenStack Swift | swift://<host>:<puerto>/<contenedor>/<prefijo> | Servicios basados en Swift con autenticación compatible. |
| Almacenamiento local | local:///ruta/absoluta | Un directorio local o una ruta local que ya esté disponible en el sistema. |
Los prefijos permiten guardar varios sistemas de archivos S3QL dentro de un bucket o contenedor, si el backend los admite. Respeta exactamente las barras finales: en algunos backends, prefijo y prefijo/ identifican ubicaciones distintas [2].
Servicios compatibles con S3
Para un proveedor compatible con S3, solicita en su documentación el endpoint, el bucket, la región de firma cuando corresponda y las claves de acceso. La URL s3c4:// usa firmas AWS Signature V4. La variante s3c:// usa firmas V2, que AWS ha marcado como obsoletas; utiliza s3c4:// salvo que el proveedor requiera expresamente la variante anterior [1].
Por ejemplo, una URL ficticia podría tener esta forma:
s3c4://almacenamiento.ejemplo:443/bucket-s3ql/servidor/
Servicios como Wasabi documentan endpoints por región para aplicaciones compatibles con S3; elige el endpoint que corresponde a la ubicación del bucket y consulta la documentación vigente del proveedor [3]. No reutilices un endpoint de otra región o de una nota antigua sin confirmarlo.
Guardar las credenciales en authinfo2
S3QL puede leer las credenciales del backend y la frase de cifrado desde ~/.s3ql/authinfo2 o desde el archivo indicado con --authfile [2]. Un bloque para un endpoint S3 compatible tiene esta estructura:
[s3ql-servidor]
storage-url: s3c4://almacenamiento.ejemplo:443/bucket-s3ql/servidor/
backend-login: <ACCESS_KEY_ID>
backend-password: <SECRET_ACCESS_KEY>
fs-passphrase: <FRASE_DE_CIFRADO>
Sustituye todos los valores de ejemplo y protege el archivo para que solo puedan leerlo las cuentas autorizadas. backend-login y backend-password son las credenciales del proveedor; fs-passphrase es la frase que descifra el sistema de archivos S3QL. Son datos distintos y perder la frase de cifrado impide recuperar el contenido [2].
El campo storage-url asocia la sección con una URL o prefijo. Si guardas varios sistemas de archivos en un mismo archivo de autenticación, asigna una sección única a cada uno y revisa el orden de las secciones que comparten prefijo; S3QL aplica las coincidencias en orden y usa el último valor encontrado [2].
Consideraciones para usar el backend local
El backend local:// guarda los objetos de S3QL en una ruta del sistema de archivos. Para una ruta absoluta, usa tres barras, como local:///var/lib/s3ql/servidor. S3QL también documenta el uso del backend local sobre un sistema de archivos remoto previamente montado, aunque en ese caso depende de que dicho montaje esté disponible y se comporte correctamente [1].
Si el proveedor ofrece un backend directo compatible con S3QL, suele ser más sencillo configurarlo directamente que añadir una capa de montaje. No copies ni manipules manualmente los objetos del prefijo: S3QL asume que administra en exclusiva todo lo que guarda allí y modificar esos objetos desde otra herramienta puede corromper el sistema de archivos [2].
Resumen
- Escoge una URL de backend que coincida con el servicio y consérvala para las operaciones futuras.
- En servicios S3 compatibles, confirma el endpoint y usa
s3c4://cuando el proveedor admita firmas V4 [1]. - Mantén las credenciales del proveedor y la frase de cifrado en
authinfo2, con acceso restringido [2]. - No confundas Google Cloud Storage (
gs://) con Google Drive. - Reserva en exclusiva para S3QL el bucket, contenedor o prefijo indicado en la URL [2].
📚 Fuentes consultadas
- Storage Backends — S3QL 6.3.1 User’s Guide
- Storing Backend Information and Credentials; File System Creation — S3QL User’s Guide
- Service URLs for Wasabi’s Storage Regions — Wasabi documentation