Mastodon Media Storage von Minio S3 zu SeaweedFS S3 migrieren

🇬🇧 [English]

Bisher habe ich gerne den Minio S3 Server zusammen mit meiner Mastodon Instanz metalhead.club genutzt, um dort Mediendateien abzulegen. Doch seit Sommer letzten Jahres nimmt das Minio-Projekt leider einen Verlauf, der mich dazu bewegt hat, mich nach Alternativen umzusehen: Zuerst wurde der interne Dateibrowser aus der Verwaltungsoberfläche gestrichen - kurz darauf wurde dann verkündet, dass Minio nicht mehr als Open Source Projekt weiter gepflegt würde. Außerdem wurde die Verteilung von Minio-Binaries eingestellt. Es gab also keine Updates mehr. Minio ist seitdem effektiv tot - zumindest, was die Community Version angeht.

Mit SeaweedFS habe ich allerdings eine tolle Alternative gefunden, auf die ich meine Mastodon Instanz kürzlich umgestellt habe. Hier beschreibe ich, in welche Probleme ich dabei gelaufen bin und wie ich diese gelöst habe.

SeaweedFS installieren

Die Installation gestaltet sich sehr einfach: SeaweedFS besteht nur aus einem einzelnen Binary, welches heruntergeladen und unter /usr/local/bin abgelegt wird:

curl -L https://github.com/seaweedfs/seaweedfs/releases/download/4.07/linux_amd64_full.tar.gz | tar xvz -C /usr/local/bin/

Anschließend wird ein neuer SeaweedFS Systembenutzer erstellt:

useradd --system seaweedfs

… und ein passender Systemd Service angelegt:

/etc/systemd/system/seaweedfs.ervice:

[Unit]
Description=SeaweedFS Server
After=network.target

[Service]
Type=simple
User=seaweedfs
Group=seaweedfs

ExecStart=/usr/local/bin/weed server -s3 -ip 127.0.0.1 -ip.bind=127.0.0.1 -volume.max=0 -dir /mnt/s3storage1/seaweedfs
WorkingDirectory=/usr/local/bin
SyslogIdentifier=seaweedfs

[Install]
WantedBy=multi-user.target
  • /usr/local/bin/weed server -s3 startet das SeaweedFS Binary weed - und damit die Komponenten master server, volume server, filer und das s3 Frontend.
  • -ip 127.0.0.1 -ip.bind=127.0.0.1: Interne Kommunikationsschnittstellen und auch die S3 API sollen localhost-intern bleiben, da wir SeaweedFS nicht in einem Cluster betreiben und auch die S3 Schnittstelle nur dem internen Nginx Proxy zugänglich gemacht werden soll.
  • -volume.max=0 sorgt dafür, dass die Anzahl der Storage-Volumes nicht begrenzt wird. Hier könnte man ansonsten einstellen, wie viel Speicher SeaweedFS maximal nutzen darf (default: 1 Volume = 30 GB). In meinem Fall soll der gesamte zur Verfügung stehende Speicher genutzt werden.
  • -dir /mnt/s3storage1/seaweedfs hier werden die Volumes in Form von Dateien abgelegt.

Service aktivieren und starten:

systemctl enable --now seaweedfs.service

Nach einigen Sekunden sollte SeaweedFS gestartet sein. Siehe auch:

systemctl status seaweedfs

Ein Bucket anlegen

Über die “weed shell” kann nun ein neues S3 Bucket angelegt und konfiguriert werden. In meinem Fall heißt das neue Bucket “metalheadclub-media”.

Shell öffnen:

weed shell

Bucket erstellen:

s3.bucket.create -name metalheadclub-media

Berechtigungen setzen (dynamisch, anstatt eines json config files):

s3.configure -access_key=ACCESS_KEY -secret_key=SECRET_KEY -buckets=metalheadclub-media -user=mastodon -actions=Read,Write,List -apply

Dabei wird zur Bestätigung folgendes ausgegeben:

{
    "identities":  [
    {
        "name":  "mastodon",
        "credentials":  [
        {
            "accessKey":  "ACCESS_KEY",
            "secretKey":  "SECRET_KEY",
            "status":  ""
        }
        ],
        "actions":  [
        "Read:metalheadclub-media",
        "Write:metalheadclub-media",
        "List:metalheadclub-media"
        ],
        "account":  null,
        "disabled":  false,
        "serviceAccountIds":  [],
        "policyNames":  []
    }
    ],
    "accounts":  [],
    "serviceAccounts":  []
}

Anonyme (öffentliche) User bekommen nur Lesezugriff auf die Mediendateien:

s3.configure -buckets=metalheadclub-media -user=anonymous -actions=Read -apply

Ausgabe:

{
    "identities":  [
    {
        "name":  "mastodon",
        "credentials":  [
        {
            "accessKey":  "ACCESS_KEY",
            "secretKey":  "SECRET_KEY",
            "status":  ""
        }
        ],
        "actions":  [
        "Read:metalheadclub-media",
        "Write:metalheadclub-media",
        "List:metalheadclub-media"
        ],
        "account":  null,
        "disabled":  false,
        "serviceAccountIds":  [],
        "policyNames":  []
    },
    {
        "name":  "anonymous",
        "credentials":  [],
        "actions":  [
        "Read:metalheadclub-media"
        ],
        "account":  null,
        "disabled":  false,
        "serviceAccountIds":  [],
        "policyNames":  []
    }
    ],
    "accounts":  [],
    "serviceAccounts":  []
}

Anschließend kann die Shell mit “quit” wieder verlassen werden.

Migration der Daten von Minio zu SeaweedFS

Der SeaweedFS Server ist nun aktiv, das Bucket erstellt und mit den nötigen Berechtigungen ausgestattet - Zeit für die Migration der Daten von Minio zu SeaweedFS!

Für die Migration gab es zwei Dinge zu beachten:

  • Die Migration sollte so “lautlos” wie möglich passieren und für die Nutzer meiner Mastodon Instanz keinen Einfluss haben.
  • Da ich dieselbe virtuelle Maschine mit demselben Speicher für SeaweedFS nutzen wollte und der Speicher begrenzt war, sollten die Daten von Minio zu SeaweedFS verschoben werden - nicht kopiert!

Die Strategie lautete - wie bei vorherigen Migrationen auch schon - wie folgt:

  1. Neues Backend in Betrieb nehmen
  2. Frontend-Proxy mit beiden Backends konfigurieren => Frontend fragt zuerst neues Backend an, im Fehlerfall Fallback auf altes Backend
  3. Mastodon-Instanz umkonfigurieren: Speichert neue Medien in neues Backend, während alte Medien aus dem alten Backend zugreifbar bleiben
  4. Medien werden von altem Storage im Hintergrund langsam zu neuem Storage verschoben
  5. … bis alter Storage schließlich leer ist und entfernt werden kann
  6. Fertig!

Zwei S3 Backends für einen glatten Übergang

Konfiguration für die Datenmigration habe ich hier visualisiert:

Grafik zeigt die Abhängigkeiten zwischen den Nginx Proxies und den S3 Servern. Den Start bildet ein media.metalhead.club Server, der das Frontend bildet. Dahinter führt ein Pfad direkt zu Minio - ein anderer Pfad über einen weiteren Proxy s3.650thz.de zum SeaweedFS Backend.

Grafik zeigt die Abhängigkeiten zwischen den Nginx Proxies und den S3 Servern. Den Start bildet ein media.metalhead.club Server, der das Frontend bildet. Dahinter führt ein Pfad direkt zu Minio - ein anderer Pfad über einen weiteren Proxy s3.650thz.de zum SeaweedFS Backend.

Die obere Reihe (media.metalhead.club, Minio Server) existierte schon früher - neu hinzugekommen ist das SeaweedFS Backend und der s3.650thz.de Server. Der media.metalhead.club Nginx-Proxy sollte (ähnlich wie bei der Migration von Scaleway S3 zu Minio) wieder eine besondere Rolle einnehmen und während der Migration der Daten flexibel zwischen den beiden S3 Backends umschalten. Primär sollte das neue SeaweedFS Backend Anfragen beantworten. Für den Fall, dass das neue Backend die Daten nicht liefern konnte, wurde ein Fallback implementiert, dass dafür sorgte, dass die Anfrage dann vom alten Minio-Backend beantwortet werden konnte.

Der Schlüssel liegt in diesen Zeilen:

# During data migration: Forward request to @minio if @seaweedfs returns 404 or 403 (access denied)
proxy_intercept_errors on;
recursive_error_pages on;
error_page 404 403 = @minio;

Virtual Host style addressing für SeaweedFS S3

Ein wichtiger Unterschied in der Behandlung des SeaweedFS Backend im Vergleich zu Minio ist, dass SeaweedFS kein Virtual Host Addressing von S3-Buckets unterstützt! Mit Minio lässt sich ein Bucket auf zwei Arten adressieren:

  • bucket.s3server.tld oder
  • s3server.tld/bucket

Ersteres ist bei SeaweedFS also nicht möglich. Stattdessen schlägt das SeaweedFS Wiki vor, Adressen so in letztere Form umzuschreiben:

...
    server_name ~^(?:(?<bucket>[^.]+)\.)?s3\.yourdomain\.com;
    ...
    # If bucket subdomain is not empty,
	# rewrite request to backend.
	if ($bucket != "") {
		rewrite (.*) /$bucket$1 last;
	}
...

Diese Art der Konfiguration konnte ich in meinem media.metalhead.club VirtualHost allerdings nicht umsetzen, weil das zum einem Fehler führte:

[error] 1388933#1388933: *5700433 rewrite or internal redirection cycle while redirect to named location "@seaweedfs", client: xxx, server: media.metalhead.club, request: "GET /cache/custom_emojis/images/xxx.png HTTP/2.0", host: "media.metalhead.club"

Also habe ich diesen Mechanismus kurzerhand in einen weiteren vHost “s3.650thz.de” ausgelagert:

upstream seaweedfs {
    hash $arg_uploadId consistent;
    server 127.0.0.1:8333 fail_timeout=0;
    keepalive 20;
}

server {
   listen 80;
   listen [::]:80;
   listen 443 ssl;
   listen [::]:443 ssl;

   # Enable http2
   http2 on;

   server_name ~^(?<bucket>[^.]+)\.s3\.650thz\.de s3.650thz.de;

   ssl_certificate /etc/acme.sh/s3.650thz.de/fullchain.pem;
   ssl_certificate_key /etc/acme.sh/s3.650thz.de/privkey.pem;

   ignore_invalid_headers off;
   client_max_body_size 0;
   proxy_buffering off;
   proxy_request_buffering off;

   location / {
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      proxy_http_version 1.1;
      proxy_set_header Connection "";
      chunked_transfer_encoding off;

      if ($bucket != "") {
          rewrite ^/(.*)$ /$bucket/$1 break;
      }

      proxy_pass http://seaweedfs; # This uses the upstream directive definition to load balance
   }
}

Letztendlich dient der vHost also nur der Umwandlung von einem “virtual host style addressing” in das herkömmliche “path style addressing”.

(Das “vHost style addressing” im media.metalhead.club vHost für die proxy_pass Direktiven benötigt, da hier keine Pfade a la proxy_pass http://seaweedfs/bucket angegeben werden können.)

Meine media.metalhead.club für die Migrationsphase sieht nun so aus:

upstream minio {
        server 127.0.0.1:9000;
        keepalive 2;
}

server {
   listen 80;
   listen [::]:80;
   listen 443 ssl;
   listen [::]:443 ssl;

   server_name  media.metalhead.club;

   # Enable http2
   http2 on;

   # SSL
   ssl_certificate /etc/acme.sh/media.metalhead.club/fullchain.pem;
   ssl_certificate_key /etc/acme.sh/media.metalhead.club/privkey.pem;

   client_max_body_size 100M;

   root /var/www/media.metalhead.club;

   location / {
      access_log off;
      try_files $uri @seaweedfs;
   }

   # Display index.html if user is browsing https://media.metalhead.club
   location = / {
        alias /var/www/media.metalhead.club/;
   }


   # 
   # Own SeaweedFS S3 server (new)
   #

   location @seaweedfs {
        # Set headers
        proxy_set_header Host 'metalheadclub-media.s3.650thz.de';
        proxy_set_header Connection '';
        proxy_set_header Authorization '';

        # Hide headers
        proxy_hide_header Set-Cookie;
        proxy_hide_header 'Access-Control-Allow-Origin';
        proxy_hide_header 'Access-Control-Allow-Methods';
        proxy_hide_header 'Access-Control-Allow-Headers';
        # Hide amazon S3 headers, which are sent by Minio for compatibility
        proxy_hide_header x-amz-id-2;
        proxy_hide_header x-amz-request-id;
        proxy_hide_header x-amz-meta-server-side-encryption;
        proxy_hide_header x-amz-server-side-encryption;
        proxy_hide_header x-amz-bucket-region;
        proxy_hide_header x-amzn-requestid;
        proxy_hide_header x-amz-meta-mtime;

        # ignore headers
        proxy_ignore_headers Set-Cookie;

        # Pass headers
        proxy_pass_header  Date;
        proxy_pass_header  Last-Modified;
        proxy_pass_header  ETag;
        proxy_pass_header  Cache-Control;
        proxy_pass_header  Expires;

        # Connection to backend server  
        proxy_pass http://[::1];
        proxy_connect_timeout 1s;
        proxy_send_timeout 30s;
        proxy_read_timeout 30s;

        # Buffer settings
        proxy_request_buffering off;
        proxy_buffering on;
        proxy_buffers 16 64k;
        proxy_busy_buffers_size 128k;
        proxy_buffer_size 32k;

        # Migration Workaround: Forward request to @minio if @seaweedfs returns 404 or 403 (access denied)
        proxy_intercept_errors on;
        recursive_error_pages on;
        error_page 404 403 = @minio;

        add_header 'Access-Control-Allow-Origin' '*';
        add_header X-Cache-Status $upstream_cache_status;
        add_header Content-Security-Policy "default-src 'none'; form-action 'none'";
        add_header X-Served-By "s3.650thz.de SeaweedFS";
   }

   #
   # Own Minio S3 server (old)
   #
   location @minio {
        limit_except GET {
                deny all;
        }

        # Set headers
        proxy_set_header Host 'metalheadclub-media.s3.650thz.de';
        proxy_set_header Connection '';
        proxy_set_header Authorization '';

        # Hide headers
        proxy_hide_header Set-Cookie;
        proxy_hide_header 'Access-Control-Allow-Origin';
        proxy_hide_header 'Access-Control-Allow-Methods';
        proxy_hide_header 'Access-Control-Allow-Headers';
        # Hide amazon S3 headers, which are sent by Minio for compatibility
        proxy_hide_header x-amz-id-2;
        proxy_hide_header x-amz-request-id;
        proxy_hide_header x-amz-meta-server-side-encryption;
        proxy_hide_header x-amz-server-side-encryption;
        proxy_hide_header x-amz-bucket-region;
        proxy_hide_header x-amzn-requestid;
        proxy_hide_header x-amz-meta-mtime;

        # ignore headers
        proxy_ignore_headers Set-Cookie;

        # Pass headers
        proxy_pass_header  Date;
        proxy_pass_header  Last-Modified;
        proxy_pass_header  ETag;
        proxy_pass_header  Cache-Control;
        proxy_pass_header  Expires;

        # Connection to backend server  
        proxy_pass http://minio;
        proxy_connect_timeout 1s;
        proxy_send_timeout 30s;
        proxy_read_timeout 30s;

        # Buffer settings
        proxy_request_buffering off;
        proxy_buffering on;
        proxy_buffers 16 64k;
        proxy_busy_buffers_size 128k;
        proxy_buffer_size 32k;

        add_header 'Access-Control-Allow-Origin' '*';
        add_header X-Cache-Status $upstream_cache_status;
        add_header Content-Security-Policy "default-src 'none'; form-action 'none'";
        add_header X-Served-By "s3.650thz.de Minio";
    }
}

Über add_header X-Served-By "s3.650thz.de ..." lasse ich mir zudem in die HTTP-header schreiben, ob eine Datei von Minio oder von SeaweedFS ausgeliefert wurde. So kann ich später prüfen, ob die Datenmigration wie erhofft funktioniert hat.

Umstellung der Mastodon Instanz

Damit Mastodon die neuen Mediendateien in SeaweedFS ablegte, mussten noch die korrekten Parameter in der .env.production Konfiguration gesetzt werden:

S3_ENABLED=true
S3_BUCKET=metalheadclub-media
AWS_ACCESS_KEY_ID=ACCESS_KEY
AWS_SECRET_ACCESS_KEY=SECRET_KEY
S3_ALIAS_HOST=media.metalhead.club
S3_REGION=hyper2
S3_PROTOCOL=https
S3_HOSTNAME=media.metalhead.club
S3_ENDPOINT=https://s3.650thz.de
S3_SIGNATURE_VERSION=v4

Nach einem Neustart aller Mastodon Services war die Änderung aktiv:

cd /etc/systemd/system
systemctl restart mastodon*

Ob meine Änderung erfolgreich war, konnte ich einfach prüfen: Ich wartete in der globalen Mastodon Timeline neue Posts mit Bildern ab und öffnete die Grafik in einem neuen Tab. Über die Firefox Entwicklertools lassen sich dann auch die HTTP-Header zur Datei anzeigen. Wie erhofft, war der X-Served-By Header auf “SeaweedFS” gesetzt. :)

… und auch die alten Grafiken ließen sich nach wie vor abrufen. Sie wurden mit X-Served-By “Minio” ausgeliefert.

Datentransfer

Prima! Dann konnte es ja jetzt an die eigentliche Datenmigration gehen. Weg von Minio - hin zu SeaweedFS.

Eigentlich ist eine solche Migration keine hohe Kunst. Ich habe rclone mit beiden S3 Buckets konfiguriert:

[minio]
type = s3
provider = Minio
env_auth = false
access_key_id = ACCESS_KEY
secret_access_key = SECRET_KEY
region = hyper2
endpoint = http://127.0.0.1:9000
location_constraint = hyper2
acl = public-read

[seaweedfs]
type = s3
provider = SeaweedFS
access_key_id = ACCESS_KEY
secret_access_key = SECRET_KEY
endpoint = http://127.0.0.1:8333
acl = public-read

Den Zugriff auf beide Buckets habe ich mit einer einfachen Dateiauflistung getestet:

rclone lsd seaweedfs:metalheadclub-media
rclone lsd minio:metalheadclub-media

Daraufhin habe ich begonnen, testweise zunächst nur kleinere Verzeichnisse wie z.B. site_uploads von Minio zu SeaweedFS zu kopieren (statt zu verschieben!):

rclone sync minio:metalheadclub-media/site_uploads/ seaweedfs:metalheadclub-media/site_uploads/

Wieder habe ich über die Browser-Tools getestet, wie die betroffenen Grafiken (z.B. Banner-Grafik unter https://metalhead.club/about) ausgeliefert wurden. Während sie erst von Minio ausgeliefert wurden, wurden sie nach dem rclone sync von SeaweedFS ausgeliefert.

Nachdem auch dieser Test erfolgreich war, migrierte ich die Mastodon Mediendaten Stück für Stück zu SeaweedFS (diesmal durch verschieben mit move statt mit sync zu kopieren!)

Liste der zu verschiebenden Verzeichnisse:

root@s3 /root # rclone lsd minio:metalheadclub-media/  
           0 2026-01-16 14:01:17        -1 accounts
           0 2026-01-16 14:01:17        -1 backups
           0 2026-01-16 14:01:17        -1 cache
           0 2026-01-16 14:01:17        -1 custom_emojis
           0 2026-01-16 14:01:17        -1 imports
           0 2026-01-16 14:01:17        -1 media_attachments
           0 2026-01-16 14:01:17        -1 site_uploads

Meine Kommandos zu verschieben:

rclone move --delete-empty-src-dirs minio:metalheadclub-media/accounts seaweedfs:metalheadclub-media/accounts
rclone move --delete-empty-src-dirs minio:metalheadclub-media/backups seaweedfs:metalheadclub-media/backups
rclone move --delete-empty-src-dirs minio:metalheadclub-media/custom_emojis seaweedfs:metalheadclub-media/custom_emojis
rclone move --delete-empty-src-dirs minio:metalheadclub-media/imports seaweedfs:metalheadclub-media/imports
rclone move --delete-empty-src-dirs minio:metalheadclub-media/media_attachments seaweedfs:metalheadclub-media/media_attachments
rclone move --delete-empty-src-dirs minio:metalheadclub-media/site_uploads seaweedfs:metalheadclub-media/site_uploads

Wer gut aufpasst, wird bemerken, dass ich ein Verzeichnis ausgelassen habe: Das Mediencacheverzeichnis /cache! Dieses ist mit Abstand das Größte und bekommt eine Sonderbehandlung …

Ärger mit dem großen /cache Verzeichnis

Dieses Verzeichnis enthält alle Dateien, die nicht vom eigenen Mastodon-Server stammen. Also zwischengespeicherte Remote-Mediendaten und Vorschaubildchen. Je nach Cache-Vorhaltezeit kann das Verzeichnis sehr groß werden. Im Fall von metalhead.club hatte ich es hier mit etwa 700 GB und ca 3 Millionen kleinen Dateien zu tun. Tatsächlich ist nicht die Gesamtgröße das Problem, sondern die Anzahl der Dateien.

Natürlich habe ich auch versucht, dieses Verzeichnis auf den neuen Storage zu bewegen:

rclone move --delete-empty-src-dirs minio:metalheadclub-media/cache seaweedfs:metalheadclub-media/cache

… doch das scheitere nach wenigen Minuten an zu wenig RAM. Ich gab mehr RAM (ca 16 GB), doch erneut war das rclone Tool so RAM-hungrig, dass es vom OOM-Killer beendet wurde.

Also gut. Wenn ich schon nicht alle Daten aus dem Cache Verzeichnis verschieben konnte, konnte ich sie doch einfach im alten Minio Bucket liegen lassen, bis sie aufgelaufen waren! Denn im /cache Verzeichnis befinden sich ausschließlich Dateien, die für den Betrieb nicht sehr wichtig sind, und die normalerweise von Mastodon nach einer festgelegten Dauer sowieso aufgeräumt werden (Bei metalhead.club: Cache Retention 15 Tage).

“Einfach liegen lassen und warten” klingt nach einer verlockenden Strategie, aber so einfach ist es nicht. Denn durch die Umstellung der Mastodon-Software auf das neue Bucket funktionieren Mastodon-interne Löschroutinen nicht mehr. Das Bucket bleibt so voll, wie es zuletzt war. Und neue Dateien drängen auf das System. Das Ergebnis: Der Speicherverbrauch steigt.

Wer sehr viel freien Speicher hat, kann möglicherweise tatsächlich einfach warten, bis 15 Tage um sind, und kann das Bucket dann als gesamtes einfach löschen. Ich hatte allerdings nur ca 170 GB freien Speicher. Der würde durch neu hinzukommende Medien im neuen Bucket schon deutlich vor 15 Tagen aufgebraucht sein. Abwarten war also keine Option. Die alten Medien mussten unbedingt nach und nach gelöscht werden.

Zunächst habe ich es über rclone Kommandos versucht. Dieses Kommando löscht alle Dateien, die älter als 15 Tage sind:

rclone -v --min-age 15d delete --rmdirs minio:metalheadclub-media/cache

… - eigentlich. Erneut waren die Anforderungen an den RAM zu hoch (z.T. 15 GB Verbrauch nur durch rclone!)

Mit einigen Optimierungen kann man den Verbrauch deutlich drücken:

GOGC=20 rclone --list-cutoff 100000 --min-age 15d delete --rmdirs minio:metalheadclub-media/cache

Siehe auch: https://rclone.org/faq/#rclone-is-using-too-much-memory-or-appears-to-have-a-memory-leak

Als ich gerade glaubte, das Problem gelöst zu haben, kam nun ein anderer Fehler um die Ecke:

ERROR : Attempt 1/3 failed with 1 errors and: operation error S3: ListObjectsV2, exceeded maximum number of attempts, 10, https response error StatusCode: 0, RequestID: , HostID: , request send failed, Get "http://127.0.0.1:9000/metalheadclub-media?delimiter=&encoding-type=url&list-type=2&max-keys=1000&prefix=cache%2F": net/http: timeout awaiting response headers

Offenbar dauerte das Auflisten der Dateien so lange, dass der S3 Server selbst in ein Timeout lief (nach ca. 10 Minuten). Wie sollte ich das lösen? In dem Bucket waren einfach zu viele Dateien.

Auch mit dem Minio-eigenen Tool mc hatte ich kein Glück:

./mc rm --recursive --force --older-than 15d minio/metalheadclub-media/cache
mc: <ERROR> Failed to remove `minio/metalheadclub-media/cache` recursively. Get "http://localhost:9000/metalheadclub-media/?delimiter=&encoding-type=url&fetch-owner=true&list-type=2&prefix=cache": read tcp [::1]:53662->[::1]:9000: i/o timeout

Wie konnte ich 3 Mio. kleine Dateien loswerden? Wie sich herausstellte: Eigentlich sehr einfach …

Dateien löschen über S3 Lifecycle Rules

… denn ich hatte einen praktischen S3 Mechanismus total vergessen: Lifecycle Rules. Mit diesen Regeln lässt sich für Dateien festlegen, was mit ihnen während oder nach ihrem Lebenszyklus passieren soll. Ein Use Case ist: Automatisches Löschen. Genau, was ich brauchte! Und das beste daran: Diese Löschung findet Backend-intern statt und muss nicht durch Tools von außen gesteuert werden. Mein Timeout-Problem bei der Dateiauflistung konnte ich so geschickt umgehen.

Ich habe also das mc Tool genutzt, um alle Dateien in /cache nach 15 Tagen ablaufen zu lassen:

mc ilm add minio/metalheadclub-media/cache --expire-days 15

Fertig!

Der aktuelle Status lässt sich mit

mc admin scanner status minio/

einsehen. Damit der Minio-interne Dateiscanner schneller arbeitet und Dateien somit schneller löscht, wenn sie ihr Haltbarkeitsdatum überschritten haben, kann der Vorgang noch etwas beschleunigt werden:

mc admin config set minio/ scanner speed=fastest

Abschluss

Nach 15 Tagen waren alle alten Dateien gelöscht und ich konnte das Minio-Bucket löschen, Minio entfernen und das alte Bucket auch aus meinen Nginx-Konfigurationen entfernen. Die Zeilen

# Migration Workaround ...
proxy_intercept_errors on;
recursive_error_pages on;
error_page 404 403 = @minio;

und

location @minio {
    ...
}

wurden entfernt und Nginx neu geladen. Metalhead.club war nun vollständig zu SeaweedFS migriert.

Ein Dank geht übrigens an Stefano Marinelli (@stefano@bsd.cafe) für den SeaweedFS Artikel unter FreeBSD. Dieser hat mich letztendlich dazu bewegt, SeaweedFS eine Chance zu geben und die Umstellung anzupacken.