# SeaweedFS na Unraidu — S3-kompatibilní úložiště

Vyladěný Docker stack proti původnímu příkladu. Hlavní rozdíly a proč:

| Změna | Proč |
|---|---|
| Pin verze image `:4.32` místo `:latest` | reprodukovatelnost, žádné překvapení po `pull` |
| Master má `-mdir=/data` + namapovaný volume | **metadata masteru** (kde co leží) jinak po restartu zmizí |
| Filer má namapovaný `/data` | leveldb s metadaty souborů musí persistovat |
| `-config=config_s3.json` u s3 | bez něj je S3 **bez autentizace, otevřené komukoliv** v síti |
| `healthcheck` + `depends_on: service_healthy` | služby nestartují dřív, než je master skutečně nahoře |
| `restart: unless-stopped` | přežije restart Unraidu |
| `-ip.bind=0.0.0.0` | dostupnost z LAN, ne jen z kontejneru |
| Data pod `/mnt/user/appdata/...` | zálohovatelné, ne v anonymním volume |

## Kam se ukládají data (DŮLEŽITÉ pro Unraid)

Klíčové pravidlo Unraidu: **cache není pod paritou** → patří tam jen to, co jde
snadno obnovit. Rozhoduje tedy ne velikost, ale obnovitelnost:

| Co | Obnovitelné? | Kam | Cesta |
|---|---|---|---|
| volume (vlastní obsah) | ne (to jsou ta data) | **POLE (parita)** | `/mnt/user/seaweedfs/volume` |
| **filer metadata** | **NE** — bez nich jsou bloby slepé | **externí DB** (Mongo/PG) | `filer.toml` |
| master metadata | ano — poskládá se z heartbeatů | cache / appdata | `/mnt/user/appdata/seaweedfs/master` |
| config_s3.json | trivální | vedle compose | `./config_s3.json` |

### Proč filer metadata nesmí na cache

filer drží mapu *název souboru → které chunky na kterém volume*. Volume servery ji
**neumí zrekonstruovat** — bloby na poli přežijí, ale ztratíš informaci, co je co.
Proto je dáváme do tvé existující DB na 192.168.1.76 (viz `filer.toml`):

- **MongoDB (doporučeno)** — kolekce v DB `seaweedfs` se vytvoří sama, žádné schéma.
- **PostgreSQL** — vytvoř DB a tabulku:

  ```sql
  CREATE DATABASE seaweedfs;
  -- v DB seaweedfs:
  CREATE TABLE IF NOT EXISTS filemeta (
    dirhash   BIGINT,
    name      VARCHAR(65535),
    directory VARCHAR(65535),
    meta      BYTEA,
    PRIMARY KEY (dirhash, name)
  );
  ```

Master metadata na cache nechávám schválně — po ztrátě cache si je master poskládá
z hlášení volume serverů, takže spadají do „snadno obnovitelné".

### Nejdřív založ share na poli

Settings → Shares → Add Share:
- Název: `seaweedfs`
- **Primary storage: Array** (NE cache), Secondary: none — jinak by data tekla zpět na cache a zaplnila ji
- Allocation/split dle libosti

Tím vznikne `/mnt/user/seaweedfs`, kam míří volume vrstva. (Alternativa: napřímo na
konkrétní ZFS disk, `/mnt/diskX/seaweedfs/volume`, když chceš obejít user share.)

> Pozn.: Disk 8 (sdd) má v poli **14 223 čtecích chyb** — než tam pustíš nová data,
> mrkni na SMART / zvaž jeho vyřazení. Na takový disk bych volume dir nesměroval.

## Spuštění

```bash
cd /boot/config/plugins/compose/... # nebo kamkoliv stack uložíš
docker compose -p seaweedfs up -d
docker compose -p seaweedfs ps
```

## Endpoints (nahraď `UNRAID-IP`)

- Master UI: `http://UNRAID-IP:9333`
- Filer/web: `http://UNRAID-IP:8888`
- **S3 API:** `http://UNRAID-IP:8333`

## Před produkcí

1. **Změň klíče** v `config_s3.json` (admin i readonly). Dlouhé náhodné secret keys.
2. Soubor `config_s3.json` drž s právy `600`.
3. Zvaž reverzní proxy (SWAG/NPM) s TLS, pokud má být S3 dostupné mimo LAN.
4. `defaultReplication=000` = bez replikace (1 kopie). Pro odolnost přes víc disků/serverů zvyš (např. `001`, `010`) a přidej volume servery.

## Test

```bash
# AWS CLI
S3=http://UNRAID-IP:8333 AK=admin SK=tajne ./test_s3.sh
```

Nebo přes `s3cmd`, `rclone`, MinIO client (`mc`) — vše funguje proti `:8333`.

## Škálování později

Tohle je single-node setup (test / menší nasazení). Pro distribuovaný cluster přidej
další `volume` servery (klidně na jiných strojích) mířící na stejný master a zvyš
replikaci. Master + filer mohou zůstat, volume vrstva se škáluje horizontálně.