Seafile: recuperar espacio en disco con seaf-gc (el garbage collector)

En corto

Imagen Docker oficial (Community Edition):

1

docker exec seafile /scripts/gc.sh        # para Seafile, corre el GC y lo vuelve a arrancar

Instalación en binario, o contenedor con la secuencia a mano:

1
2
3
4
5

cd /opt/seafile/seafile-server-latest
./seafile.sh stop
./seaf-gc.sh --dry-run        # cuántos bloques se irían, sin borrar nada
./seaf-gc.sh                  # borrar
./seafile.sh start

En Kubernetes, lo mismo dentro del pod: kubectl -n seafile exec -it deploy/seafile -- bash y la secuencia anterior (o /scripts/gc.sh si es la imagen oficial).

Antes de nada: System Admin → Libraries → Trash → limpiar. Una biblioteca en la papelera conserva todos sus bloques y el GC no la toca.

Por qué el disco no baja solo

Seafile guarda los archivos troceados en bloques con dirección por contenido en seafile-data/storage/ (blocks/, fs/, commits/). Borrar un archivo o una biblioteca solo escribe un commit nuevo; los bloques siguen ahí porque el historial de la biblioteca todavía los referencia, y porque otra biblioteca o una versión anterior podría usarlos. Lo único que los elimina es seaf-gc, que recorre los commits vivos y borra todo lo que ya nadie referencia.

Dos cosas deciden qué es “nadie”:

• La papelera de bibliotecas del panel de administración: una biblioteca borrada por un usuario no se elimina, se mueve ahí. Hasta que la limpies, sus bloques cuentan como vivos.
• El historial de cada biblioteca (History settings: días a conservar). El GC respeta ese período; con historial ilimitado, los bloques de versiones viejas nunca se liberan.

Requisitos

• Community Edition: Seafile parado. Los bloques que se escriben mientras el GC corre podrían ser borrados por error. El script /scripts/gc.sh de la imagen oficial lo para y lo arranca solo; a mano, seafile.sh stop antes y seafile.sh start después. Pro tiene GC en caliente.
• Ventana de mantenimiento. El tiempo crece con el tamaño del almacenamiento; en instalaciones grandes son horas.
• Respaldo o snapshot de seafile-data (si está en ZFS, un zfs snapshot es instantáneo). Es la primera vez que algo va a borrar bloques de verdad.

Opciones de seaf-gc.sh

Ejemplo de una sola biblioteca, en seco:

1

./seaf-gc.sh --dry-run 3f5a1c2e-7b9d-4e21-8c44-0a6d9e7f1b23

Procedimiento completo

1. Panel de admin → Libraries → Trash → limpiar (o Clean por biblioteca). Sin este paso, el GC informa de cero bloques y no entiendes por qué.
2. Revisa el historial de las bibliotecas grandes (History settings); si guardan todo para siempre, decide un número de días.
3. Snapshot o respaldo de seafile-data.
4. docker exec seafile /scripts/gc.sh, o la secuencia a mano con --dry-run primero. La salida termina con el resumen de bloques por biblioteca.
5. Comprueba: du -sh /opt/seafile-data/seafile/storage/blocks y df -h.

Para no repetirlo a mano, un cron semanal de madrugada con el mismo docker exec basta en CE.

Trampas

• “GC no libera nada”: papelera sin vaciar, historial ilimitado, o bloques retenidos por snapshots del sistema de archivos (en ZFS, zfs list -t snapshot y su USED).
• Nunca con Seafile arriba en CE. Si el contenedor arranca seafile-server como proceso principal, seafile.sh stop dentro puede tumbar el contenedor; con la imagen oficial usa /scripts/gc.sh, que ya lo contempla.
• --rm-fs en versiones viejas puede borrar objetos que sí se usan; solo desde CE 11.0.7.
• Nginx delante y clientes que muestran Server error al sincronizar tras el GC: suele ser client_max_body_size demasiado bajo, no el GC; ponlo a 0 en el server de Seafile.
• Bibliotecas cifradas se recolectan igual; el GC no necesita la contraseña.

Referencia: Seafile GC en el manual de administración.